The 8080 interrupt system is one of the most simple and straightforward. Instead of having sophisticated built-in mechanics, reacting to interrupts, the 8080 just accepts a single instruction from an external source, marking this cycle with
INTA. This opens up many more possibilities for external interaction than fixed handling.
RSTx instructions are just the most simple way, as they are implied subroutine calls encoded in a single byte, thus requiring the least external effort to inject an encapsulated software response.
Using multi-byte instructions (like a call) works as well, but needs a bit more decoding hardware (for call all included within the 8228 system controller (*1)).
What are examples of providing non-RST instructions for 8080 interrupts?
One example (with extended decoding) would be inserting a
CALL issuing any possible routine as a response.
But maybe more important is single-byte instruction for tightly coupled interrupt response. For example, an
INC instruction could be used to fire a wait loop.
Imagine the main program waiting for an external input in a tight loop like:
This might seem strange at first, as when it runs into LP, it becomes an infinite loop. But now let an interrupting device insert an
INR B (04h), and suddenly the CPU will drop out of the loop. The remarkable part here is that its latency is always shorter than 15 clocks (5 for ICR and 10 for JZ) while an
RST will take whatever the actual instruction is (at least 4) plus 11 cycles for the
RST. In addition, no
RET or stack adjustment at the end is needed (*2). For tight reactions, this is close to the optimal way (*3) on an 8080.
In addition, the use of
DCR forms a counter catching additional activations during its run time and serializes processing (*4).
Constructions like that are hard to make with other CPUs (*5).
Where there any systems that actually used an opcode other than RST n when handling interrupts?
Yes, using such constructions was almost standard on any embedded system past the most simple applications.
What was the reason for doing so?
Speed, flexibility, speed, integration and ... well ... speed.
Think of a real-time data acquisition system. Here every microsecond may count. At the same time, the data recorded is usually rather simple. Often just bits or a single byte. With the right combination of interrupts and injected code the 8080 can be turned into a multi-channel DMA unit while still running some data management application in the foreground. And so on.
*1 - System Controller is a bit of pompous name for the 8228, as it's basically a data bus buffer and a status latch. In addition, it can also either offer a single
RST7 interrupt response, as well as handling an inserted
CALL instruction the right way.
When configured for simple
RST7 insertion (by pulling the
INTA output to +12 (!) Volt) the 8080's interrupt input will work like almost all other manufacturers' interrupt inputs, jumping to 56h.
Otherwise, it can detect an inserted
CALL and keep
INTA asserted over the next two fetches. Too bad they didn't make it work with any multi-byte instruction, so doing this will still require additional circuitry.
*2 - Not to mention that an RST routine usually has to do some PUSHing and POPping
*3 - There are possible tweaks improving thereon, but they not as simple and beyond the scope here.
*4 - This can also be used with multiple registers and more complex structures for extremely tight-coded reactions.
*5 - Using the 6502's
SO input can be used in a somewhat similar fashion, but way less flexible.