What are examples of providing non-RST instructions for 8080 interrupts?

Question

When a peripheral in an 8080 system generates an interrupt request and the 8080 acknowledges the interrupt, the peripheral is expected to put an instruction opcode on the data bus which the 8080 will execute.

Typically this is an RST n instruction, which cases the PC to be pushed on to the stack and 8*n to be loaded into the PC, running whatever subroutine is located there.

But, as mentioned specifically on page 60 of the Intel 8080 Assembly Language Programming Manual:

Any device may supply an RST instruction (and indeed may supply any 8080 instruction).

Were there any systems that actually used an opcode other than RST n when handling interrupts? (I'm looking for examples of real systems here, ideally, rather than just "here's how you would do it if you wanted to.") What was the reason for doing so?

Answer 1

Preface:

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:

  MVI B,1
WAIT:
  DCR B
LP:
  JZ  LP
  [...]
  [Interrupt Reaction]
  [...]
  JMP WAIT

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 INR/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're 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 - The 6502's SO input can be used in a somewhat similar fashion, but way less flexible.

Answer 2

An obvious answer is that any system including i8259 interrupt controller does generate CALL ADDR sequence for interrupt acknowledge.

See, for example, here: https://pdos.csail.mit.edu/6.828/2005/readings/hardware/8259A.pdf

Answer 3

Register or register pair increment or decrement commands (INR, INX, DCR or DCX) could be used for "transparent counting" of interrupt events while running something else. The code obviously needed to assume that the certain register or register pair is reserved for this counting and can change the value at any time, unless the interrupts are disabled.

This was described in some article but I do not know if was actually used on any system in mass production.