Interrupt handling and SoEMT

It seems that the interrupt handling mechanism for the Mill could be easily extended to support Switch-on-Event-MultiThreading (and extending such to support a low-overhead form of remote procedure call might not be entirely unreasonable). An interrupt handler saves state and loads state (some of it dynamic — a similarity to a remote procedure call) and is triggered by an event, much as SoEMT would. (The MultiThreading Application Specific Extension for MIPS uses Shadow Register Sets (which are used to accelerate interrupts by avoiding saving, loading context, and restoring) for thread contexts.)

It could be further noted that interrupts traditionally have priorities, a property that naturally fits with multithreading, and mechanisms are often provided to bind certain interrupts to specific cores or groups of cores, a facility which could also be useful for multithreading. (Using thread priorities could be a natural, in terms of interface description, way to disable interrupts; by running at high priority a thread would prevent interrupts (threadlets) with a lower priority from being handled by a core until the priority was reduced. Thread priorities might also be used for a power-saving interface.)

This seems like a natural orthogonal approach, but it may not fit with the design goals for the Mill. Even if such would not be implemented in first or second generation Mill implementations, considering the concept now might avoid some unnecessary reworking later (or might just waste limited resources).

(By the way, I like the pushing of interrupt contexts to the core. I had considered a vaguely similar feature using cache for traditional architectures (where an I/O device would push data to the cache of the controlling processor) and supporting hardware-provided arguments for system calls (for architectures that use a single handler for system calls and other interrupts, cause information could be passed in a general purpose register.)