DCPU 1.4 spec interrupt comments

comments.txt

Hi Notch,

EXECUTIVE SUMMARY:
Please add interrupt *masking* rather than just enable/ignore options, as this means
we can have critical sections without losing interrupts (random clock drift bad).

LONG-WINDED VERSION:

Losing interrupts makes me sad :(
(And will be confusing and hard to debug)

I think the architecture could use a couple more instructions to improve the interrupt
handling (and more like real-world architectures). Those instructions are a dedicated
"return from interrupt", and one to set the interrupt masking state (masked/unmasked).

Interrupt masking is the big one. At the moment if you set IA=0 on entry to interrupt
service routine, you will miss any interrupt that fires during that ISR. Having to
design hardware to re-send interrupts later if they are missed is a kludge, the right
way to do it is MASK interrupts so that if one arrives, it fires immediately when
interrupts are unmasked. Then it is not missed and hardware doesn't have to retry.

This means for example you don't miss a timer interrupt if you were handling another
piece of hardware, so you can keep good time instead of randomly losing ticks.

Another big thing that interrupt masking gives you is critical sections, which I'm
sure you know all about so I won't teach you to suck eggs. IA=0 for critical sections
kind-of works but suffers from lost interrupts.

One more nice thing would be an atomic RFI return from interrupt instruction which
would pop PC and enable interrupts in one shot. This is to avoid lots of interrupts
nesting and blowing the stack. It's a corner case under heavy load but makes
everything more deterministic.

I also think interrupts should by default start with interrupts masked: This makes
things more straightforward, safer and less surprising by default for those new to
interrupts. Unmasking interrupts inside an ISR should be an advanced option.

But the main thing is: Interrupt masking for deferred arrival please! Not just
enable/ignore!

Thanks! Excited about the game :)

P.S. IMPLEMENTATION FOOTNOTE:

I suppose this would be implemented with something like a queue for interrupt
requests. Then come issues of maximum queue depth and what to do if overflowing the
queue.
You could have an instruction to read a system register that reports and zeros the
maximum queue depth seen, so overflow could be detected..
But maybe that's getting carried away for "just a game"?

Sorted in 1.5. IAQ heals (almost) all ills. Go Notch!

We could also benefit from an atomic exchange or swap instruction.

Maybe but I think Notch is trying to keep things fairly simple and was getting pretty sick of interrupt problems, don't want him to throw it all out :) IAQ gives us mutual exclusion - good enough.