Assignment 12 comments

I hope jury duty is an exciting experience for you.

My vocabulary is being expanded with technical terms of a field I never expected to learn. I'm learning that when multiple well intentioned and good people observe the same event, they sometimes tell remarkably different stories. To say the least, it's interesting.

In question 1a, how about this?

 
; rasing an exception
        LIL     R1,PCONERR
        LOAD    R2,R2,CONERR    ; AR = constraint_error.exar
        LOAD    R1,R1,EXHAND
        JUMPS   R1              ; PC = constraint_error.exhand

The second instruction above loads R2 with a field of the current activation record. That can't be right, because at the time the constraint error handler was installed, you didn't know what activation record would raise the exception.

The definition in the text said "the second word of any activation record for a routine with an active exception handler points to the entry point of that handler." That means you have to change R2 first (to be the AR for the handler), then go to that AR to get its second word (the word right after the return address).

In question 1a, do we even need to worry about saving and restoring the old handlers? Or should I only be writing the code to throw the exception?

I was only suggesting that you look at the code to throw the exception first. If that's obviously broken, it has strong consequences for the rest of the code. First, figure out how to throw it in a way that can work. Then worry about saving and restoring.

In question 1, one students suggested he needed to append the handler AR to the current AR.

This must be wrong! You never append an AR to anything. ARs get pushed and popped on the stack. Does this wording represent a problem with the difference between the AR and the pointer to the AR?

In question 1b, how about: The universal model can handle nesting try/catch blocks. This model seems to only be able to handle sequential try/catch blocks since the handler AR is stored on the stack.

The AR is always on the stack -- that's where all ARs are, so the above must be a wrong answer.

In question 2, How can we determine an opcode is undefined?

Appendix B lists all the instructions. One list of instructions lists them in reverse numerical order (the other lists are alphabetic by opcode). Look through this list, checking for opcodes that don't have any meaning.

In question 4: I am not sure how to answer this question. Based on the figure in the notes, since L1 is upstream, I am not sure the CPU would want the MMU turning off the L1 cache.

Your thinking is logical. You are thinking about what is easy to do, and that makes sense, but an answer to part B might be helpful in directing your thinking about part A. What is easy may not be enough.