Interrupts accepted with PSR bit 14=0

[owenkaser]

A student program enabled interrupts in the KBSR, set the interrupt vector....and got interrupts, even though the user-mode code is running with PSR = 800x not C00x. Since the user-mode code does some traps, I thought maybe that interrupts were being enabled in the trap handler and happening there... but the supervisor stack has x3010 and x8001 at its top when a breakpoint is put at the start of the interrupt handler. Can share the students code privately if you cannot replicate.

[chiragsakhuja]

Looking at Appendix A.1 of the textbook, PSR[14] is a reserved bit and shouldn't affect interrupt handling. PSR[10:8] indicates the priority level that the program is running at. If KBSR[14] is a 1 and the current running program is at a lower priority level, then the interrupt will be taken.

By the way, I'll get to your other issues some time later this month. I've been busy with a paper deadline and haven't had any time to commit to these issues yet.

[owenkaser]

Interesting: I see that Appendix A.1 matches what you said. However, textbook section 9.5.2 contradicts this, stating "PSR[14] is the interrupt enable bit for all interrupts associated with this program". Figure 9.22 shows globally enabling and disabling interrupts by twiddling this bit.

[chiragsakhuja]

I've been talking with Yale and apparently he's thought about this inconsistency before. Despite having the code in 9.5.2, he's not sure if it's the best approach or if there may be a different option, such as changing priority to disable interrupts. Until he commits to one approach, I'll leave the simulator unchanged. I'm in favor of having a global interrupt disable bit, like section 9.5.2 shows, and I've conveyed that to Yale.