CPS 104 (Ramm) Fall Semester 1995 Homework Assignments #9 and #10 Simulator Project (An Interpreter for the DEC Alpha Machine Language) This project is to write a DEC Alpha machine language simulator using a C (or C++) compiler on the Sparc 5 workstations. The fi- nal version of this project, assignment #10, is due Monday, Dec. 4. However, there is a due date for an intermediate state on Friday, Nov. 17. This intermediate state, which should meet the specifications given below, is designated as assignment #9. This project can easily be divided into several logical parts. You will need to use an absolute loader to load the machine language test program that your simulator is to run. However, in early stages (assignment #9), you can improvise by inserting small test programs directly into your simulated memory by using C initialization statements. The other major functions to this project are called from the main simulator loop. These are a FETCH function, an EXECUTE function, and a TRACE function. You will also probably want to use a DUMP function, at least during program development. Phase 1. Overall Design. Put together high-level flowcharts or some kind of design block diagrams for the whole project. Also develop rather detailed plans for the TRACE function. Carefully plan and document your data structures. This includes a description of how you will represent the Alpha registers, the Alpha memory, etc. While your grade will include an evaluation of this phase of the project, you will be free to make design changes as you find it necessary. However, it might be best to make a copy of flowcharts and docu- mentation that you feel will not change, since you will be re- quired to turn in a complete set of documentation with your com- pleted project. Phase 2. Implementation of the TRACE function. Using your detailed flowcharts, implement the TRACE function. Show that this is working in a program that includes the main simulator loop and dummy functions for FETCH and EXECUTE (dummy functions must produce some kind of message each time they are called). If you have it working, this should begin with a call to your loader. Since the FETCH and EXECUTE functions are not yet working, the output of TRACE, while in hexadecimal and of the correct format, need not have any logical meaning. Normally each line of trace output will be exactly like the previous line, since the functions that are supposed to produce the changes aren't working yet. - 2 - Put some effort into designing a reasonable user interface. Remember that at the end, you may be asking your program to step through the execution of hundreds or even thousands of steps. The main simulator loop, interacting with TRACE and other por- tions of the program, should allow the user to single step or to execute a number of statements in quick succession as controlled by the input. Make sure that your test output can exhibit evi- dence of looping (of the main simulator loop). The output from TRACE should show the state of the Alpha regis- ters after each statement has been executed, just as xspim does. An execution count, the current instruction (in hex) and its mnemonic should also be included. The execution count is just a number that you increment for each instruction executed. The ex- act format is up to you. (You may assume that the mnemonic is actually determined by the fetch function. Use a dummy mnemonic here to establish the format.) Assignment #9: Turn in Phases 1 and 2. Due Friday, Nov. 17 Phase 3. Implementation of the FETCH function. Make detailed flowcharts for and implement the FETCH function. It should also do most of the addressing for the Alpha. Run this program, together with the other major functions, but use a dummy EXECUTE function. The TRACE output should now be partially correct. However, since branches are not executed, it should run straight through the test program. Only the PC should change in your trace output of the registers. Phase 4. Completion of the simulator. Finish your detailed documentation for the whole project and im- plement the EXECUTE function. Note that this, in turn, should consist of many functions, probably one for each instruction be- ing simulated. Assignment #10. Turn in Phases 3 and 4. Due Monday, Dec. 4 Include a complete set of documentation. Start with a cover statement -- a brief summary that states the special features (if any) of your project, as well as admitting to any shortcomings and limitations of your programs. It is better that you point out any problem to us (possibly with fixes that you would have put in if you had had enough time) rather than that we stumble on them by accident. This would lead us to believe that you did not know enough about what was going on to realize the problems. Notes: You will be given a test program further on into the pro- ject. It will let you know what instructions to implement. For now, plan to implement at least representative instructions. For - 3 - the early stages of implementation, you can use random instruc- tions to test things out. While you may only have to implement a subset of the Alpha instructions, there should be nothing in the structure of your design that prevents you from implementing all of the standard instructions. The absolute loader referred to earlier, is nothing more than putting some kind of input routine into a function that reads a file into your simulated memory, starting at location 0 (of the simulated memory). I some ways the input will be similar to that done for assignment #8. Important: It is crucial that a separate Assignment #9 be turned in using dummy functions as described. If you turn in a func- tioning #10 with the argument that this implies that you did #9, you will receive only partial credit for #9. November 2, 1995