Assignment #1

Read Chapter 1 I. Written exercises (not graded) For the following: Add (in hexadecimal) 62FA E00D Assuming the above numbers represent 16 bit 2's complement integers, convert them to their decimal equivalents and add. Compare the results with (a). Explain. Express 11, -21, -7 in 2's complement for a machine which uses sign-plus-5 bits of information for representation of integers. Add the sign-plus-5 representations 111011, 110011, 000001, 110111 together assuming the representation is 2's complement (verify your work by converting each to decimal and also doing the decimal addition)

II. Programming exercise: Due by noon on Friday, September 15, 2006 Consider the SIC program given on page 45 and assembled on page 47. Construct a small data file named <student-id>-1.in with the contents: <your-name> COP 3601, assignment 1 data September 13, 2006 Change the START location of the source program from 1000 to 3A0. Adjust the data input device in the source program to be DEVF2 instead of DEVF1 (the loader program used with the SIC simulator employs DEVF1 as the input device for your SIC program object code, so it isn't available for data). In the RDREC source subroutine, change the program statement "COMP ZERO" to be a test for 10 (or hex '0A') instead of for 0. [Notes: this statement is referencing the storage definition   ZERO   WORD   0 and provides the exit criteria for the subroutine; i.e., exit if the COMP statement determines that the input character read into the rightmost byte of register A is X'00'. Since Unix text editors mark "end-of-line" by X'0A' rather than X'00' (Null), the test needs to be a test for ten (X'00000A') rather than a test for zero. The replacement needs to be the equivalent of          COMP   TEN where TEN identifies a storage area added to the program:   TEN    WORD   10 Without this change, the program will not work successfully with your input file (an alternative would be to come up with means to insert Null characters into the file - you could write a program to do this, but it's easier to change the SIC code!).] Hand assemble your modified source program for "simple" SIC to produce new object code similar to that in the object code column of the program on page 47. [Notes: the SIC/XE assembler sicasm will assemble any SIC/XE op code prefixed with "*" as "simple" SIC so long as the op code is one common to both SIC and SIC/XE. Hence, you can check your work by using sicasm. This entails entering your modified source code in a text file, with the additional modification of prefixing each op code with "*". Keep in mind that START, BYTE, WORD, RESW, RESB, END are directives, not op codes, so you don't prefix them. If your text file is named HW1chk, then sicasm HW1chk will produce two files HW1chk.lst showing the assembler report in a form analogous to the listing on page 47 and HW1chk.obj holding object code formatted for the SIC loader program] Install your SIC object code in a text file named <student-id>-1.obj. Add in the requirements for the SIC "loader" as described in the on-line SIC/XE reference. The requirement is that you must "bracket" each object module in your object file with "control" lines as follows: <memory-address> <memory-address> . . . object module . . . ! <-- control 1: object module load point <-- control 2: post-load execute <-- your SIC or SIC/XE code for the module <-- control 3: the object module delimiter   Important: The memory address for "post-load execute" specifies the memory address of the instruction to execute after SIC has finished loading this object module. If you have more object modules following this one then the post-load execute address should be "000000", which is the execute address for the loader (i.e., you want the loader to run again to bring in your next object module). On the other hand, if this is your last module to be loaded, then the post-load execute address needs to be the starting address for your program (so that your program, now fully loaded, will execute). For the program of page 47, the natural decomposition is two object modules (one for the code preceding the BUFFER, and one for the code following the BUFFER). Execute the program using the SIC simulator (sicsim). If you run sicsim directly, you must use the "assign files" capability of the simulator to assign the object code file (<student-id>-1.obj) to the DEVF1 slot and assign the data file you constructed (<student-id>-1.obj) to the DEVF2 slot. The class directory /usr/public/cop3601/cwinton/sicstuff contains a shell script sicsimrun for automatically assigning files (warning, it overwrites existing DEVFn files). To use this script, you must first copy it to your own directory. The command line sicsimrun <student-id>-1.obj <student-id>-1.in will launch the SIC simulator, properly assign the files, and initiate the bootstrap load. After launch, run the simulator as follows: Specify a break-point of 3A0 and dump memory starting from 3A0 when the break-point is reached. Locate your input program on the dump. Specify at least one other break-point (say 3C7) and dump registers and memory 3A0-3F0. Locate your input data on the dump. Do a trace. Set a break point at the main routine's RSUB (2F7); execution is complete when this break point is reached (manually exit the simulator to terminate). You should experiment with different breakpoints, count settings (use 1 to single step), and observation via dumps as to what the program is doing from both the step-by-step and "in the large" points of view. Note that the file (DEV05) output by the program is different from the one input (why? - you must explain this in the Testing and/or the Assessment sections of your general write-up). When you are confident of the process, remove the sic.log file and do a final run with the above specs, then move the resulting sic.log file to <student-id>-1.sic.log Construct Word documentation as specified on the assignments page (remember that the naming convention calls for you to name your documentation file <student-id>-1.doc). You may "crib" off the example given on the assignments page, but do not plagiarize it. Your documentation file needs to include an appendix derived from each of your object file (<student-id>-1.obj) input file (<student-id>-1.in) output file (<student-id>-1.DEV05) log file (<student-id>-1.sic.log) You will need to produce a commented listing of source/object corresponding to your object file, in particular. All appendices should include appropriate annotations. Be sure to add comments to each line of your source file comment your log file, explaining (in italics) what is in the dumps (registers and memory); a small amount of highlighting can be used to minimize the commenting that would otherwise be needed. In general, computer generated listings included as appendices may be edited. Just be sure to italicize any text that you add to the listing to distinguish it from what the computer has produced and use the Courier font for all computer generated text. Use the submit shell script (which you should have already copied from /usr/public/cop3601/cwinton) to "shar" your documentation (<student-id>-1.doc) object code file (<student-id>-1.obj) data file (<student-id>-1.in) output file (<student-id>-1.DEV05) log file (<student-id>-1.sic.log). and "turnin" by noon on Friday, September 15 to cnw.3601.1. Late submissions can be submitted until the due date for the next assignment via submit to cnw.3601.1L (late points assessed as stipulated on the assignments page).