MMIX User Trips and Signals

Author: Martin Ruckert

Situation:

With MMIX , these callbacks are difficult to implement from the operating system side, since user space and operating system space are asymmetric, and therefore also the call and return instructions TRAP and RESUME are highly asymmetric.

Proposal:

Allow additional trips, similar to the arithmetic trips that get despatched to addresses #90 to #F0. The register rA holds enough space to accommodate the respective enable bits, since a delay mechanism is desirable, also the respective event bits could find their place in rA, triggering a trip, as soon as the enable bit is set to 1, clearing automatically the respective event bit.

There is a mechanism in place to set ordinary event bits in a RESUME 1 instruction using the rXX register together with ropcode=2. This mechanism would needed to be extended to other ropcodes (at least ropcode=#80) with respect to the extra user trips. Setting such a user event bit would result in an immediate trip after the resume, in case the corresponding enable bit is set. Otherwise, the trip is delayed until the respective enable bit is set. Setting the enable bit would cause an immediate trip after the PUT rA instruction, to the lowest possible trip location, clearing the event bit. During the Trip, we need to disable further trips, reenabling them with the RESUME 0. So a similar mechanism to saving (and hopefully restoring rK) is needed. Again rA has enough space to shift the enable bits left in a TRIP and right in an RESUME.

There is some unaccounted nowhere-land between address #90 and #100. For some reason, the main program typically starts at #100, the trip vector goes up to #8F, and at #90,  there might be a hint for NNIX to initialize a library. #A0 through #FF are unused.

The space from #90 to #F0 would accommodate for 7 events. The eight event bit could be used to trigger a regular trip to #00. The last thing, except for a possible delay using the enable bits, could also be accomplished by inserting a trip instruction using ropcode 0. The delay mechanism is, however, important since the application might want do declare interrupt free, atomic regions. It can do this by clearing and resetting the enable bits.

With rQ we have a special mechanism in place to guard against loosing events that occur between a GET and a successive PUT. A similar mechanism is required here unless we declare the event bits read-only for the user program, which is probably too much a restriction.

The space in register rA is used in one other instruction: the SAVE/UNSAVE instruction use the high order Byte of rA to store there rG. So we can not use this byte for other purposes.

Rearranging bits in rA

Currently, the 8 low bits are used for arithmetic events, the next 8 bits for the corresponding enable bits. Bit 0 dispatches a trip to #10 and bit 7 to #80. the address #00 is used to dispatch the TRIP instruction.

Bit 16 and bit 17 are used to hold the rounding mode.

I propose the following new layout:

Bit 0 to 15: event bits, bits 0 to 7 remain unchanged for arithmetic events.

Bit 16 to 31: enable bits, bit 16 to 23 take the role of the previous enable bits 8 to 15.

Bit 32 to 47: saved copy of the enable bits during a TRIP, these are used to restore the enable bits in a resume.

Bit 48 to 49: store the rounding mode (previously bit 16 and 17)

Bit 50 to 55: zero

Bit 56 to 63: zero, used to store rG in an SAVE/UNSAVE instruction.

More conservative layout:

We keep the current bits where they are. Then have only seven additional event and seven additional enable bits. Saving/restoring of the 15 enable bit uses the 15 lowest bits of the high order tetra in rA.

Discussion