CSC 225 - Spring 2011 Revision #1 Laboratory Project Final Professor Grimes Due Friday, June 3, 2011 Points: 100 (In order to receive 100 points, the following deliverables must be completed.) Deliverable # 1, Due Monday, May 23, 2011, See note in Design Section. Demonstrate in the Lab on this date and submit product by midnight on this date. Deliverable # 2, Due Wednesday, May 25, 2011, See note in Design Section. Demonstrate in the Lab on this date and submit product by midnight on this date. Deliverable # 3, Due Friday, May 27, 2011, See note in Design Section. Demonstrate in the Lab on this date and submit product by midnight on this date. Objectives Become more proficient at assembly programming, including 1. Subroutines 2. Structures 3. Dynamic memory Know the actions of the assembler and be able to implement them in assembly language Notes You must work with your partner on this assignment. The LC-3 solution submitted must work on the Linux version of the simulator. Overview In this program you will implement a 2-pass assembler (We have discussed this and the book has additional information.). Input to your program will be LC-3 assembly. Output from your program is the actual machine language that corresponds to the LC-3 input. This will be stored directly into memory starting at the.orig address specified in the input. You are to implement this assembler in LC-3 assembly. You will not be required to do everything because code is provided to get you started. Supplied Code Start with the fp.asm file found on the course website. You should become familiar with these subroutines and be able to use them. The comments before each subroutine give more detail about what they do. Look closely at the comments for PARSER INIT, PARSER NEXT, and PARSER FINI. The PARSEFILE subroutine shows how to use these three functions to parse the input assembly a line at a time. PARSER NEXT returns a data structure with the following information for each assembly non comment assembly line: Offset Description +0 Address of a string that contains the LABEL. NULL if no label +1 Address of a string that contains the OPCODE. +2 Address of a string that contains OPERAND1. NULL if no operand. +3 Address of a string that contains OPERAND2. NULL if no operand. +4 Address of a string that contains OPERAND3. NULL if no operand. +5 Address of the instruction description structure for this OPCODE.
All strings are NULL-terminated character arrays. The parser code takes care of skipping the comments, locating and extracting the labels, opcodes, operands. It also provides an instruction description" structure that you can use to simplify the second pass of your assembler (code generation). The instruction description" structure is: Offset Description +0 Address of next structure in the linked list. You do not need to use this value. +1 Integer number of operands for this OPCODE. +2 Enumerated type indicating the addressing mode of the instruction. See the comments in fp.asm for the full list of values. +3 Base machine language bit pattern for this OPCODE. All bits that are determined by operands are zero. +4 0 if the last operand is a register. Non-zero if the last operand is an immediate. Note { In LC-3 all other operands are registers. +5 Description of operand 1. Only valid when the instruction has at least 1 operand. If OP1 is a register, the number of bits to shift the 3-bit register number before ORing it into the machine instruction. If OP1 is an +6 Description of operand 2. Only valid when the instruction has at least 2 operands. If OP2 is a register, the number of bits to shift the 3-bit register number before ORing it into the machine instruction. If OP2 is an +7 Description of operand 3. Only valid when the instruction has at least 3 operands. If OP3 is a register, the number of bits to shift the 3-bit register number before ORing it into the machine instruction. If OP3 is an +8 - +10 Unused. +11 Address of immediate form for the equivalent 3-register opcode. Ignore this field. +12 First character of a NULL-terminated string containing the nemonic string for this OPCODE. This structure provides enough information for data-driven machine code generation. Using the opcode and operand descriptions in this table, you can implement a single subroutine that can handle all machine code generation without any special cases for handling LC-3 instructions. The complete table is stored starting at label OPCODE TABLE in fp.asm if you want to read it. You will still need special cases to handle pseudo-operations (like.orig and.fill). The design section of this project description has information to help you with this. You should also review the LC-3++" supplemental manual found on the Blackboard website under this assignment. This document details all the changes that have been made to the simulator. Pay particular attention to the new traps that have been added (near the end of the document). The new traps are for common string operations, common math (SUB, MULT) and logic (OR) operations, and allocating dynamic memory Design Write and test this program in phases. There is no way you can write it all and then begin testing it. The following is deign guidance that will facilitate your work on this program. You must follow it. The following are the steps to be taken to complete the implementation: 1. Pass 1 - Implement a pass-1 subroutine. Pass the address of the file to assemble into this subroutine. Create a stub subroutine based on the PARSEFILE subroutine. Change this routine slightly to process the.orig directive (use the enumerated type in the instruction description to determine it is.orig and STRTOL on the operand to determine the actual origin address). Modify pass-1 to track the Location Counter (LC), starting with the.orig value you previously determined. Initially assume every instruction requires 1 address. Write another subroutine that determines the actual number of addresses used by the instruction. This will vary as a result of.blkw,.stringz, and.end pseudo-ops. Remember, use the enumerated type to determine the opcode (not the string).
Use your function to correctly track the LC for each instruction. Deliverable #1: Complete everything to here. Demonstrate each of above modules with test separately. Every time there is a label, print out the label and the value for the LC at the time. This should be the symbol output for the program you are assembling. Verify the LC values in your output are correct by comparing the with the values that lc3as determines for the same code. Implement an ADD SYMBOL subroutine that inserts the symbol information you were printing in the previous part into a symbol table. Use a linked list for the symbol table. Add the new node at the end of the list, to keep it sorted in LC order. Use the MALLOC trap to allocate memory for the node. Update pass-1 to call the ADD SYMBOL subroutine instead of printing out the symbol information. Return the starting address of the symbol table from the pass-1 subroutine. Deliverable #2: Complete everything to here. Demonstrate each of above modules after last deliverable with test separately. 2. Write a master ASSEMBLE subroutine that calls pass-1. 3. Write a print-symbol-table subroutine that walks through the entire symbol table and prints it out in the format required for this lab. 4. Modify ASSEMBLE so it takes the symbol table from pass-1 and passes it to your print subroutine. 5. Test your code. 6. Create a skeleton pass-2 subroutine based on your pass-1 code. pass-2 needs to do many of the same things, including tracking of the LC during the pass. It shouldn't add any symbols to the table. Modify ASSEMBLE to call pass-2 after it has printed the symbol table. 7. Test your code. 8. Starting implementing machine language generation: Your pass-2 code should call a function (based on the enumerated type of the instruction) that actually generates the machine language encoding for the instruction. I suggest using a jump table for this. A jump table is an array of labels (in our case an array is just consecutive memory locations). Place the label for the subroutine that handles opcodes with no operands (enumerated type '0') at index 0. Do a similar thing for all 14 enumerated types. In your pass-2 code, load the starting address of the table, add the enumerated type to it, and then load that value into a register. Use JSRR to call the actual subroutine. There is no need for conditionals to do this. Also, ensure all subroutines accept the same parameters and return the same results. Implement a stub generator function that displays a warning about needing to implement a real generator. Use this stub for all opcodes. Pick an easy opcode (say, enumerated type 0" which has no operands) and write the generator function. Deliverable #3: Complete everything to here. Demonstrate each of above modules after last deliverable with test separately. Repeat (also consider writing a single, generic piece of code based on the data structure discussed above). Base the order you implement your functions on the order points are assigned for this program. You will need separate logic for.fill,.stringz, and.blkw. Some instructions will require symbol table lookups (resolve a label) and the computation of a PCrelative immediate. Put this logic in separate subroutines. Some instructions will require you to parse the register syntax (e.g., R4") and convert it into a 3-bit number. Write a subroutine that does this. You can also have the routine shift it according to the instruction description. Remember, after you have generated the instruction, store it in the correct location in memory. 9. Have your ASSEMBLE function return the.orig address. 10. Have your main code call ASSEMBLE and then JMP to the address that gets returned. The program
should run! Test with some of your old labs! Example Output The complete set of examples is available on the course website. Here is the output snippet that covers the text not produced automatically by the simulator. There may be additional output depending on what the assembled program does. This example is taken from fp ex0: --- halting the LC-3 --- (lc3sim) Will not use stdin for LC-3 console input during script execution. Loaded "fp_ex0.obj" and set LC (PC)to x8000 WARNING: No symbols are available. Loaded "fp.obj" and set LC (PC)to x7000 Symbol table contents: ---------------------- L1: x3000 L2: x3001 L3: x3002 L4: x3011 L5: x3028 **** Starting program **** --- halting the LC-3 --- This demonstrates the required standard output from the assembler (the symbol table and the Starting program" line). Everything else will depend on the actual program being assembled. Testing Testing this program is a little more involved. You can not directly load.asm files into the simulator. Instead, there is a program on Blackboard, txt2lc3, which converts any ASCII text file into an LC-3.obj file. Use this program on the test.asm files. Load the resulting.obj into the simulator like normal. The file will load starting at address x8000. In addition, the program printfile.asm on the course website demonstrates how to loop through the ASCII file loaded at x8000 and print it out one character at a time. Using printfile you can convince yourself that the ASCII file was imported into the simulator correctly. You will need to import the source ASM file and the.obj for your assembler each time you rerun the simulator. Eleven test cases, fp ex[0-10], have been provided for you on the course website. The input is designed to be used with the lc3wrapper.sh script found in bellardo/bin. You should redirect the script's output to a file and diff that against the provided output. The following shows how to do this for the fp ex0" test case. Your program must be assembled before running these commands: bellardo@vogon:~/csc225 $ ~bellardo/bin/lc3wrapper.sh < fp_ex0.in > fp_ex0.myout bellardo@vogon:~/csc225 $ diff fp_ex0.out fp_ex0.myout bellardo@vogon:~/csc225 $ Requirements Your output must match the example output exactly, character for character.
Submittal This uses the command line lc3 simulator found on vogon. There may be slight differences between the Window's simulator and the version used by lc3wrapper. You should test your program with diff as described here before submitting it. Submit all deliverables via Blackboard before midnight on the due date. The following is a complete list of deliverables: 1. Deliverable steps For each step the product must be demonstrated in Lab on the due date. All modules must be zip d and submitted by midnight on the due date. 2. Final Deliverable a. team.txt" file - The team.txt" file informs us who you and your partner are. This enables you to submit a single copy of the program, and both you and your partner will receive the same score. You MUST submit a team.txt file. Create the file team.txt" with your favorite text editor In the first line, put your CSL username. My CSL username is jgrimes". This MUST be your CSL username (on the off chance your portal username is different). All letters in your username MUST be lowercase. This is NOT an email address, do not include @calpoly.edu" or @gmail.com" or any other additional information in this file. NONE. Add the statement I did not cheat. In the second line of the file, put your partner's CSL username. Assuming I am working with Brian Wihl, our team.txt file would look like: jgrimes I did not cheat. bwihl I did not cheat. b. fp.asm