Dispatching Dynamic and Forced MMIX Traps

Author: Martin Ruckert

Dynamic Traps

Situation:

Dynamic traps are dispatched to the address stored in rTT; forced traps are dispatched to rT.

I have worked on several schemas to handle dynamic traps; in the end, I always returned to dispatching dynamic traps based on rQ. It would be very simple and convenient to incorporate the dispatching based on the lowest order 1-bit of rQ&rK into the dynamic trap.

Proposal:

If i is the number of the lowest order 1-bit that is present in rQ and rK, a dynamic trap should jump to rTT+i*4. This is not quite consistent with the dispatch of trip interrupts, but for any reasonable trip handler four instructions are not enough, so typically an implementation will have a table of JMP instructions at rTT.The added flexibility of the present schema can be recovered by using a JMP Instruction to a common Handler routine. Without an automatic dispatch, any dynamic trap needs a PUSHJ first jto free registers just to do the dispatch. Especially for small interrupt handlers (incrementing a counter setting a flag, ignoring the interrupt) the automatic dispatch would also be a faster solution. But the major advantage of the dispatch would be the added flexibility.

Forced Traps

Situation:

The situation with forced traps is similar but slightly more complicated.

A typical handler for forced trap will first check on the ropcode (the high order byte of rXX). The normal case is a ropcode of #80 and the low order tetra of rXX containing a TRAP instruction (opcode #00). Cases for ropcode different from #80 need special treatment; normal cases typically originate from TRAP XYZ instructions. Here Z is typically used as an immediate (or using rZZ, a register) Argument. Y is an immediate Function Code. X is so far zero, but might be used as a function code in larger operating systems, in which case Y can also take the form of a register Argument (in rYY). Again the typical operating system will dispatch on X and on Y.

Proposal:

To make things not too complicated and reduce space requirements for the required jump table, I argue for a Dispatch on 0Y, then on X and on ROP. therefore we have the following cases:

The dispatch table fits into one 2kByte page. Most of the Table can be filled with a JMP instruction to a common error handler. If my proposal to restore rK as part of a RESUME 1 operation (see Restoring rK after TRAP) is accepted, a simple RESUME 1 operation could also be used to fill unused entries in the Table.

Further Considerations

The jump table for forced traps can be followed/preceded by the dispatch Table for dynamic traps,; in this case only one special register rT or rTT is needed to indicate the loaction. Operating systems might however use jump tables for forced traps on a process by process basis while sharing one jump table for dynamic traps. This could be (a weak) argument to keep two special registers.

Once automatic dispatch on dynamic traps is available, there is the temptation to do some work without PUSHJ or SAVE. This can be done by saving and restoring extra registers like $254 and $253 into rYY and rZZ which are not used by dynamic traps.

For most forced traps, rZZ is not used too, but instead the low byte of rXX is used as an immediate Z value. So the trap handler can free a register by PUTing it into rZZ and GETing it from rZZ before returning.

Discussion