Lab 2b: Assembler and Simulator

CSE 141L, Spring 2007, Donghwan Jeon

Due 5/14 (M) before the beginning of the class

You should work on this lab with your team from lab 2a.

Overview

Although you have already designed an ISA, you need to validate and revise the ISA before expending the extensive effort required to sign and implement it. In lab 2b, you will implement two essential components for architectural validation and verification- assembler and simulator. An assembler translates your program written in your ISA into binary code; a simulator performs a simulation upon a provided binary code. Collectively, they form essential infrastructure for your processor design. For the implementation of the assembler and the simulator, you are free to choose any high level language (including scripting languages).

Assembler

It is difficult and error-prone to manually write machine code. To address this problem, people usually use an assembler, which automatically generates a machine code from an assembly file. Moreover, many C compilers first generate assembly files and then simply feed it to an assembler to get the executable machine code. For these reasons, you should write an assembler for your ISA. Your assembler reads a program written in an assembly language, then translates it into binary code and generates two output files containing executable machine code. You will use the generated output files for both the simulator and the actual hardware you will implement.

Required Features

First, examine the following sample assembly code. 
.text
        la  $1, table0    // load the address of a label table0 (pseudo instruction)
        lw  $2, $1        // $2 <= 0x000C0FFEE 
        lw  $3, table0    // load the value at label table0 (pseudo instruction), $3 <= 0x000C0FFEE
        lw  $4, 3(table0) // $4 <= table1
        lw  $5, 1($4)     // $5 <= 0x1DEADBEEF
        sw  $5, 1($1)     // 0x001COFFEE is overwritten to 0x1DEADBEEF 
        li  $6, 0xC0FFEE  // load immediate (pseudo instruction), $6 <= 0xC0FFEE
        
.data
   table0:
        .word 0x000C0FFEE
        .word 0x001C0FFEE
        .word 0x002C0FFEE
        .word table1
   table1:
        .word 0x0DEADBEEF
        .word 0x1DEADBEEF
        .word 0x2DEADBEEF
        .word 0x3DEADBEEF
        .word 0x4DEADBEEF, 0x5DEADBEEF, 0x6DEADBEEF
        .fill 10 0x0
Your assembler must support the following keywords and reserved words used in the example code above. The following list is the minimal required set; you may extend it with other keywords.

In addition to the keywords listed above, the assembler must support at least four pseudo instructions equivalent to the following MIPS pseudo instructions appeared in the previous example code.

These pseudo instructions will make programmers' life easier by allowing programmers not to concern absolute addresses; instead, they can describe most addresses with label and offset. Note that pseudo instructions might be equivalent to multiple instructions in your ISA. Also note that the addresses used in pseudo instructions can be either an instruction memory address or a data memory address depending on the location of the label. You may change pseudo instruction names if needed, but the semantics of instructions should be the same.

Code Stub

To execute a benchmark in your simulator, you will need to create a small code stub that sets up the environment, including:

When all the environmental settings are properly done, the code stub should call a benchmark function. Since code stub should be the first code executed upon power-on, the text section of the code stub should be placed at 0x0 of the instruction memory in the output file of the assembler. (Assume that your processor starts by fetching an instruction from 0x0 upon reset.) Before you implement a general program loader, you have to use code stub; in lab 2b, always assemble with a code stub.

Input and Output Requirements


Simulator

Now that you have an easy way to generate machine code, it is time to implement a simulator. With a simulator, you can 1) easily verify your ISA without actually implementing hardware, 2) debug your application without having actual hardware, and 3) improve your ISA by spotting performance bottlenecks in benchmark programs. Your simulator operates instruction by instruction; you must be able to execute instructions one by one and watch all the programmer visible states (eg. register, memory, ...) at a certain time when the execution of an instruction is completed. Assume that your simulator starts executing at address 0x0 upon power-on.

Simulator Commands

You may add whichever commands you find useful. However, your simulator must support the following commands:

How to Test

  • in and out

    • Among provided benchmarks, SuperGarbage uses in and out instructions. To make these instructions work, you should use put_channel and dump_channel commands which emulate actual I/O operations of hardware. If an out instruction blocks due to the lack of buffer space, you should use clear_channel command to make space so that out instructions could succeed. You can set the buffer space for each channel by using set_buf_size command before starting a simulation.

  • Validation

    • After executing a benchmark program, you should check whether your program behaved as you expected. You can easily validate the simulation result by examining register and memory values. In specific, the return register should have an appropriate value when a Fibonacci simulation ends. Similarly, memory values should be properly updated when Program Loader or SuperGarbage are executed.

    Deliverables

    Your team needs to submit the following items:

    Lab Interviews

    We have a 15 minute interview session for each team in this lab. Please go to team website to sign up for an interview slot.Each team is responsible for the following items:

    Hints