cse141L Lab 5: Assembler and Simulator


Changelog

February 22

Here's the current schedule for the interview. If you requested a slot and it's not on here, let Prof. Swanson know. If you don't currently have an appointment, let him know.

14:00 Stephanie and Eric
14:15 Darren Ngo and Frank Congson
14:30 Alan Green and Angela Wang
14:45 ka cheung
15:00 vuong tang
15:15 Scott Hogan and Kristen Campbell
15:30 ka cheung
17:15 Paul Baumgart
17:30 Stephanie Mattingly and Lisa McCutcheon
17:45 Brad and Stacie
18:00 Cory Rivera and Morgane Botella
18:15 Josh Gramm and Denard Agsalon
18:30 Aaron and Matthew
18:45 Brian and Maria
19:00 christopher kha
19:15 Nicole and Jeff
19:30 Sarang Ratanjee and Michael Barrett
19:45 mike and jimmy
20:00
20:15
February 13

You can use your own names for the command line options, so long as they are reasonably clear.

February 9

Changed interview date to Tuesday to avoid President's Day.

February 22

For future classes: Changed default channel buffer size from 16 to 32; there was much confusion between the buffer size (defaulting to 16) and channel count (fixed at 16).


Due: 2pm, February 15

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 5, you will implement two essential components for architectural validation and verification- assembler and simulator. An assembler translates your program written in your assembly language 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 5, 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.

The source for the simulator for our toy ISA is here

Simulator Commands

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

How to Test

Hints

Deliverable

Your team needs to submit the following items:

  • Hardcopy
    • Assembly files (*.s) for three benchmarks
    • Code stub files (*.s) for three benchmarks
  • E-mail to TA (zipped, titled "[CSE141L] Lab 5, team name - member_name1, member_name2")
    • Updated ISA Manual
    • Full source code of the assembler and the simulator
    • *.s files (benchmarks, code stubs) for three benchmarks
    • *.coe files for three benchmarks (total six coe files)

Lab Interviews

We have a 12 minute interview session for each team in this lab. Interviews will be between 2 and 3:45 and 6-7 on February 19th in the lab. Each team is responsible for the following items:

  • Prepare your demonstration by the interview time. You might use either your laptop or a basement lab computer.
  • In the lab interview, you have to show that all the benchmarks are working correctly with your assembler and simulator. Please thoroughly test benchmarks with different inputs before the interview.
  • Sample questions:
    • What are main design decisions you made for your ISA?
    • How does your ISA pass arguments at a function call?
    • How does your ISA load big constants?
    • What is the number of dynamic instructions to complete a specific benchmark?

Due: 2pm, February 15