lab 5
play

Lab 5 CSE141L Announcements New lab due date policy Assigned - PowerPoint PPT Presentation

Nov 11, 2022 •47 likes •187 views

Lab 5 CSE141L Announcements New lab due date policy Assigned Friday Due the next Friday or Due Sunday night for 10% off. Applies to current Lab 4, and the Lab 5. ClarificaHon About Memories Fetch unit Back end Fifo

  1. Lab 5 CSE141L

  2. Announcements • New lab due date policy – Assigned Friday – Due the next Friday or – Due Sunday night for 10% off. • Applies to current Lab 4, and the Lab 5.

  3. ClarificaHon About Memories Fetch unit Back end Fifo … Instruction memory in fetch unit: Data memory in back end: 17 bits wide 34 bits wide Accessible via special load/ Accessible via normal load/ store instructions store instructions • This is a Harvard Architecture – Easier for the lab, not how real machines work.

  4. Lab 5 • Assembler • Simulator

  5. Assembler 1/2 • Manually wriHng machine code – Time consuming – Error prone – Monotonous – Hard to maintain – ….(bad bad bad) Why not Automate?

  6. Assembler 2/2 • Inputs – A program source wriVen in your own assembly language – InstrucHon start address (entry point) – Data start address • Outputs – $name_i.coe ‐‐ instrucHons – $name_d.coe – data

  7. *.coe • Why coe? – IniHalize vector format in Xilinx CoreGen – Your RAM modules will be iniHalized as specified in a *.coe file

  8. not_fib.s The assembly process .text not_fibinacci: la $1, table0 The assembler should fill in these constants. lw $2, $1 lw $3, table0 lw $4, 3(table0 lw $5, 1($4) Assembler sw $5, 1($1) asm –stub stub.s -src not_fib.s -data_addr li $6, 0xC0FFEE .data table0: .word 0x002C0FFEE .word table1 table1: .word 0x0DEADBEEF .word 0x4DEADBEEF, 0x42 .fill 10 0x0 stub.s not_fib_i.coe not_fib_d.coe stack: .fill 1024 0x0 MEMORY_INITIALIZATION… Execution starts here MEMORY_INITIALIZATION… .text @ 0x0 stub: li stack mov sp // really r1 in my ISA li table0 mov gp // really r2 in my ISA li 4 mov r4 // first arg by convention in my ISA call not_fibinacci out rv, 0 // rv is the “return value” in my ISA // tell us the function result

  9. TesHng the Assembler • Simple test cases – Check output by hand. • Lots of asserts() and error checking • The simulator will help

  10. Simulator • Why? – verify your ISA – debug your applicaHons – improve your ISA by spoeng performance boVlenecks in benchmark programs – Collect data about how your processor performs ‐‐ what actually is the common case? • Inputs – $name_i.coe – $name_d.coe • Your simulator will have a command line interface for easy debugging

  11. Simulator Commands

  12. Simulator Algorithm Allocate and iniHalize architectural state While (1) { Setup; Read InstrucHon; Decode InstrucHon; Execute InstrucHon; Do command line interacHon; }

  13. Things to consider • Both your assembler and simulator need to understand your ISA – Best pracHce: Use a single representaHon for the ISA, so the assembler and simulator cannot get out of sync. • There are many sources of error in your system: – Conceptual errors in the ISA – Bugs in your implementaHon of your ISA – Bugs in the simulator – Bugs in the assembler – Bugs and conceptual errors in your assembly program – Debug carefully, and do lot of error checking!!!! Detect errors early. – E.g. Make sure all unused bits are zero. – E.g. Fill all of memory a recognizable value or non‐executable instrucHon

  14. Notes • You can use any language you like (even different ones for the assembler and simulator, if you like; ‐‐ Can you sHll use a single representaHon of your ISA)? • You can share code for bit (un)packing and 34‐ bit/17‐bit stuff, but nothing else. You must credit your source. – We have provided some java code for this purpose.

Recommend

More recommend