8-Bit Instruction Set Architecture
Total Page：16
File Type：pdf, Size：1020Kb
CSE 141L – SU07 – Cynthia Lee Lab 1: 8-Bit Instruction Set Architecture Due Monday August 13 2007, 11:59pm PDT This term you will design a specialized processor which will be targeted at only one tasks. In Lab1A you will design the instruction set for a processor. In Lab 1B, you will double check your design by writing an emulator to read in assembly code (in your ISA), output the machine code, and execute the instructions. You will then be well prepared to design the hardware for the processor in subsequent labs. This will be an 8-bit Single Cycle Processor that you will optimize to run the program described below. You will design the instruction set architecture (ISA) and instruction formats, and code these programs to run on your instruction set. Given the limited instruction bits, the needs of the target program should be considered carefully. The best design will probably come from an iterative process of designing the ISA, then coding the program, then redesigning the ISA and so on. Your goal is, of course, to design an ISA that can be implemented to run the program as fast as possible. You can work in groups of 1 to 2 people, but no larger. Once you form a group, you cannot change groups, so be sure you can work with your lab partner. All members of a group receive the same grade on the labs. Part A: Submit electronically (in Word, PDF, or nicely formatted .txt): A single page describing all the instructions of your ISA (we suggest a table with at least instruction name, opcode, and description). You may also want a short introduction explaining any overall theme. For each program, a graph (think Excel, or graph paper) showing the memory layout of a sample input and then the corresponding output. For each program, pseudocode of a solution, and the implementation of at least ONE program in your ISA (looks like an assembly language file). Part B: Assembler/emulator for your instruction set architecture (this small investment of time will pay huge rewards by helping you find bugs in your assembly code before your ISA is finalized, and help you test your hardware later on by providing the binary code for your programs). DETAILS ISA Design Your instruction set architecture should feature fixed-length instructions 8 bits wide. You need to make sure that all of your opcode encodings are unique. This means that when the processor encodes an instruction it should be unambiguous which instruction should be executed. From the opcode, the processor may determine the format of the rest of the instruction. In order to fit this all in 8 bits, the memory demands of this program will have to be small. For example, you will have to be clever to have a conventional main memory even as big as 256 bytes. For the program you run, you may not need all of that. You should consider how much data and instruction space you will need for the required 2 programs before you finalize your instruction format. You can assume that instructions are stored in different memory than data memory, so that your data addresses need only to be big enough to access that data. You should also notice that this program probably won't need procedure calls and stack pointers, but the design is up to you. This will be an 8-bit machine for every aspect. Memory is byte-addressable, and registers and important data types are also 8 bits. Also you need to assume single-ported memory (a maximum of one read or one write per cycle, not both). You will also assume a register file (or whatever internal storage you support) that can only write one register per cycle (only 8 bit written per cycle). The only exception to this rule is that you can have a single 1-bit condition register (e.g., carry out, or shift out, sign result) that can be written at the same time as an 8-bit register, if you want. You can, of course, read more than one register per cycle. Please restrict register file size to no more than 16 registers. Also, manual loop unrolling is not allowed. To simplify the ISA design process, you need only optimize for the following two goals: 1. Minimize dynamic instruction count (i.e., the number of instructions executed during the running of a particular program). 2. Simplify your processor hardware design. You are welcome to also optimize for other things (e.g., cycle time, ease of pipelining), but if you do so, we will expect you to discuss that optimization intelligently, and these two goals should still take highest priority. You will be rewarded, in particular, for doing a good job with goal 1. The Target Program Array “Treasure Hunt”: In a treasure hunt, you have an initial clue that tells you where you the next clue is hidden, and so on, until you finally find the treasure. In this version, you are given an array where each element of the array contains the index of another element in the array. Start the “treasure hunt” at Array[0], which is the index (unsigned) of the next position in the array you should examine, and so on, until you find the treasure (the number 255), or you visit 30 positions in the array, whichever comes first. Record (in memory location 0) the index where you found 255 (write 255 there if you ended before finding 255). Record (in memory location 1) the number of positions you visited. Record in memory location 2 the number of elements you examine that are greater than what's in Array[0] (including 255, if you find it). The array starts at memory location 3, and will be at most 120 elements. Misc. Fixed data ordering in memory: little or big endian, you choose. No other operation (compares, etc) can occur in the same cycle as a load or a store. Your ISA should NOT include an explicit multiply instruction. Your ISA should include a Halt instruction (always the last instruction of the program, it tells your CPU to stop loading instructions from instruction memory. The contents of memory in locations other than those that are given as input is unknown. Do not assume that uninitialized memory contains zeros. Writeup Please answer the following as briefly as possible, while still being complete. 1. What instruction formats are supported and what do they look like? Give an example of each instruction type in assembly language, then translate it into machine code. Show the breakdown of the 8 bits into opcode, arguments, etc. (* This may be up to a page, possibly with a table or other graphical representation if that helps you clearly and briefly explain it.) 2. What instructions are supported and what are their opcodes? 3. How many registers are supported? Anything special about the registers? 4. What addressing modes are supported? How are addresses calculated? Give an example. 5. How large is the main memory? In what way did you optimize for dynamic instruction count? 6. How did you optimize for ease of design? 7. If you optimized for anything else, what and how? (It's OK if you didn't). 8. What do you think will be the bottleneck in your design (i.e., what resource will you run out of the most quickly for bigger, more complex programs)? 9. Can you classify your machine in any of the classical ways (e.g., stack machine, accumulator, register, load-store)? If so, which? If not, give a name for your class of machine. Emulator and Dynamic Instruction Count For Part B you will have the chance to test the correctness of your implementations of the programs in your ISA by writing an emulator (in Java or whatever you prefer) to: 1. Read in assembly code (from a file) of your programs (one program per file) 2. Translate (assemble) each assembly instruction into binary (into an output file) 3. Emulate the action of the program. The emulator should input a file representing memory when the program starts, and output a file that matches the memory output at the end of executing the program. 4. Output the dynamic number of instructions executed to complete the program. If, as you design the emulator and test your target program, you discover “issues” with your ISA, or ways it could be more efficient, now is the time to implement those changes (update your documents from Part A). Note that discovering issues/bugs is quite likely—that's the whole reason you will be writing the emulator. THIS WILL BE THE LAST TIME YOU CAN CHANGE YOUR ISA EXCEPT FOR CATASTROPHIC FAILURE REASONS..