CSE141L Lab 3, Part 2: Creating an Assembler

Lab Overview:

Lab Description:

Assembler Requirements:

.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:

• Stack Pointer:
  Make sure that the stack pointer is properly set so that the tested function (benchmark) can use the stack.
• Global Pointer:
  A program often accesses global data and/or constants by using the global pointer ($gp in MIPS), which is also set by the code stub. Like the stack pointer, a code stub should properly set the global pointer before the execution of a tested function.
• Input Data:
  Many of the benchmark programs require a few arguments. To test these benchmarks, a code stub must properly set registers and/or the stack memory depending on the way your ISA passes function arguments. You should modify your code stub when you want to test a benchmark with different arguments.
  
  In addition to function arguments, VirtualMachine benchmark needs test data. We provide a simple data input for VirtualMachine to save your time for making a test bench; you have to include the provided test data in your code stub for VirtualMachine using previously mentioned .word keyword.

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 this lab, always assemble with a code stub.

Inputs and Outputs of the Assembler:

Your assembler have two outputs: $name_i.coe and $name_d.coe. $name_i.coe corresponds to a 17-bit instruction memory while $name_d.coe corresponds to a 34-bit data memory. They must have the following forms:

• $name_i.coe - 17 bit word size

  	MEMORY_INITIALIZATION_RADIX=16;
  	MEMORY_INITIALIZATION_VECTOR=
  	00000,
  	00001,
  	00002,
  	00003,
  	00004,
  	00005,
  	.....,
  	1DEAD
  	EOF
  

• $name_d.coe - 34 bit word size

  	MEMORY_INITIALIZATION_RADIX=16;
  	MEMORY_INITIALIZATION_VECTOR=
  	000000000,
  	000000001,
  	000000002,
  	000000003,
  	000000004,
  	000000005,
  	.........,
  	3DEADBEEF
  	EOF
  

The first line in each output file specifies the numerical format used in the file. We use hexadecimal notation. Note that each entry of the 'MEMORY_INITIALIZATION_VECTOR' is data for each word, starting from address 0x0. Thus an entry of the instruction memory is 17-bit, while that of the data memory is 34-bit. These output files will be used as inputs to your simulator as well as coregen utility which generates SRAM modules in Xilinx ISE.

Since a *.coe file always start out at 0x0, you must fill out unused memory area from 0x0 to -text_addr or -data_addr with arbitrary values (typically 0x0). However, for other unused memory locations, you do not need to specify values; unspecified memory locations will have arbitrary values.

Assembler example usages:

1. prompt> asm -stub start.s -src test.s -data_addr 0x200

   The assembler will generate two files - test_i.coe and test_d.coe. Since -stub option is used, the text section will be loaded at 0x0 of the instruction memory, while the data section will be located at 0x200 of the data memory. The test section starts with instructions in the code stub start.s, then it calls the benchmark function in test.s which is located after start.s in the instruction memory .

2. prompt> asm -src garbage.s -text_addr 0x100 -data_addr 0x200

   The assembler will generate two files - garbage_i.coe and garbage_d.coe, which will be loaded at 0x100 of the instruction memory and 0x200 of the data memory, respectively. Since no code stub is used, the function in garbage.s will be directly located at 0x100 of the instruction memory and 0x200 of the instruction memory, respectively.