One reason the Mill architecture looks so interesting is that all of the state that needs to be saved is done asynchronously, in parallel with program execution. In fact, the same mechanism is used for function calls, system calls, and interrupts, which all just look like atomic ops. That should make interrupts and irets much faster.
Another interesting aspect of the Mill architecture is that protection and translation are separate. The cache uses virtual addresses, and the TLB sits between cache and main RAM. The TLB is much bigger and slightly slower, so simply doesn't fault nearly so often.
Can you guys say anything yet about how the Unix fork syscall is implemented on that architecture? The requirement for copy-on-write pages seems to conflict with a single virtual address space.
Afraid its still Not Filed Yet (NFY). You knew I was going to say that. But the slide deck is all ready for when we've filed.
The next talk will be about configuration, which is another cool topic, and that'll be in a couple of weeks. Get on the mailing list to get details as they become available: http://millcomputing.com/mailing-list/
IIRC SPARC register windows do something like this - a call and a return do not need to save or restore anything but a pointer to what is the first register available to your function.
I think it's at least partially a problem of not being better enough than "good enough". Not to mention Itanium (and maybe Sparc, I don't know enough about it to say) had plenty of its own problems, including with interrupt handling.
