Machine Problem 6, due at the end of Dec 9

Background: The Hawk opcode 1111xxxx 0001xxxx₂ is an unimplemented member of the memory reference format instructions listed in Appendix B.1.2 of the Hawk manual. Some Hawk users have complained that the Hawk has no instruction for loading non-aligned words, that is, words occupying 4 consecutive bytes without the constraint that they begin at addresses divisible by 4.

Those users have proposed that the following instruction be added to the Hawk architecture:

The macro to assemble this instruction (in the context of the support macros in the hawk.h) is straightforward:

MACRO LOADNA =dst,=x,=const
  qNZREGq dst
  qMEMREFq #F010,dst,x,const
ENDMAC

Before taking the time to develop a hardware implementation of this instruction, it has been decided to do a virtual implementation of it, using the undefined instruction trap to handle it.

The Assignment: Write a trap handler for undefined instructions (INSTRTRAP) that gives the usual output for undefined instructions except when the opcode is the one for the proposed LOADNA instruction. In that case, your trap handler should emulate the new non-aligned load instruction and then return from trap.

Your code will begin something like this:

        TITLE   "mp6.a by Your Name Here
        USE     "hawk.h"
        USE     "stdio.h"

        COMMON  MP6SAVEAREA,... your code here ...

        ... your code here ...

LC      =       .       ; save the relocatable location counter
.       =       #20     ; code for the instruction trap vector

        CPUSET  R2,TSV          ; partially save R2
        LIL     R2,MP6SAVEAREA  ; get the save area pointer
        STORE   R1,R2,SVR1      ; save R1
        LIL     R1,MP6HANDLER
        JUMPS   R1              ; go finish work in relocatable code

.       =       LC      ; back to relocatable code

MP6HANDLER:
        ... your code here ...

        END

Obviously, where it says Your Name Here put your name, and where it says ... your code here ... put SMAL Hawk code to solve the problem.

Details: You must write a subroutine main program to test the new instruction, but don't turn that in. You must link your code for mp5.o with your main program. Neither one will have INT or EXT directives referencing the other, because your code gets control via the trap vector.

In deciding how much space to allocate in your save area, you may need to know how the total stack space required by some of the monitor routines, including the space required by routines they call:

• PUTCHAR needs 3 words of stack space.
• PUTSTR needs 3 words of stack space.
• PUTS needs 4 words of stack space.
• PUTHEX needs 4 words of stack space.

You are entirely responsible for testing your code to prove that it works, but the only code you submit should be the code for your trap handler. This puts you in exactly the same situation as any commercial software vendor — the vendor does all the testing they can, and then passes their work to customers, where the vendor has no idea of how the customer will use the code.

Grading: 5 points. Correct output is worth 2.5 points. The remaining credit will be offered only for those who have at least partially correct output.

Code that does not assemble will not earn any credit.

Stylistically clean code is important; that is why half the credit is reserved for style, but only if the code works. Bad indenting will be penalized up to 1 point from the 2.5 style points. Excessive or inadequate white space within and between lines will be penalized, again, up to 1 point. Excessive or inadequate comments will be judged similarly.

Note: Comments should not repeat the assignment. Assume that the reader of your code has read the assignment. Assume that the reader knows how to program, so commenting ADDSI R1,1 with R1=R1+1 would be stupid. Comments should help the reader when the code is hard to follow.

Before you submit: Assuming your code is in a file named mp6.a, please use the command

   [HawkID@fastx?? ~]$ ~dwjones/format mp6.a

This will gripe about over-length lines, strange mixing of tabs and spaces, and other file-format issues that will make your code hard to read when printed out for grading but might not be obvious when you have the file open for editing.

Submission: To submit your work, it must be in a file named mp6.a in your current directory on the CLAS Linux system, and you must know your section number. Aside from the change from mp5 to mp6, the instructions are the same as for previous submissions.