Uses for the halt instruction?

Question

What was the halt instruction in early CPUs such as the Z80 and 8080 used for?

Here's a description of the Z80 instruction:

The HALT instruction suspends CPU operation until a interrupt or reset is received. While in the halted state, the processor will execute NOP's to maintain memory refresh logic.

What use is it to enter a state that can only be exited via an interrupt or reset? Does a NOP loop use less power? Did operating systems (CP/M, Acorn MOS) or Basic variants make use of it? Did people writing assembly programs for the CPUs make use of it?

Aside: How would an interrupt cause an exit of the halt state? After executing the interrupt service routine, would the CPU not return to its previous instruction - the NOP loop?

Answer 1

The HALT condition does not (at least on retro CPUs) consume considerably less power than normal execution does.

One very obvious use case is synchronizing program flow with external (hardware) events. The main use case of the HALT instruction is thus "wait for an interrupt".

A prominent example outside embedded systems is synchronizing video output with the beam flyback phase on a CRT to prevent flicker. Before actually writing new information to the frame buffer, the CPU is put into the halt state. A vertical blank interrupt triggers the CPU to go on writing (leave HALT), making sure the write occurs in a phase where no screen output takes place.

Other uses might be waiting for interrupts from other I/O like, for example, disk controllers. The Sinclair microdrive system used HALT to wait for the next sector on the drive come by.

Other uses of HALT can be multiprocessor systems, or communication with a second CPU: Send off a command to your second processor, put the first one in HALT to wait until the second CPU sends an answer and signals this with an interrupt. Then put the other one to a HALT state. The Commodore C128 used this with its Z80 co-processor. For this to work properly, another important trait of the HALT (or the-like) instruction is that it signals i don't need the bus at the moment other than for refresh - The HALT signal can, be (and is, in many architectures) used to isolate the CPU completely from the bus, if needed during that state.

On Motorola CPUs, the HALT instruction was called STOP and took an argument: A value written to the status register (which holds, among others, the Interrupt mask) - So you could specify for which interrupt to wait (Or, rather, the minimum IPL (Interrupt Priority Level) that has to occur before execution resumes).

As you can see from the above examples, HALT is, even if it is rarely used in application programs, an important instruction for OS writers. The exact program flow may differ a bit between CPUs, but the main flow would be:

1. Initiate some external process going on (like sending a command to the disk controller)
2. Put the CPU in HALT state, also releasing the bus.
3. Hardware outside the CPU can access the bus, use memory,...
4. Once done, the external hardware triggers an interrupt
5. CPU leaves HALT state
6. CPU executes the ISR (if any)
7. CPU continues with the next instruction after the HALT and can access the external hardware for the results

Answer 2

What was the halt instruction in early CPUs such as the Z80 and 8080 used for?

Stopping the system in a known state to allow a clean restart/react to external sources.

It's a very useful feature for embedded systems that react to external sources, but also as idle state for a more conventional kind of multitasking environment.

What use is it to enter a state that can only be exited via an interrupt or reset?

Several:

• Interrupt response is guaranteed to be the shortest possible.
• Interrupt response time will be within exact (short) boundaries.
• No need for complex schedulers.
• Easy chaining of (interruptable) cleanup and management tasks.
• Enabling special power saving (or otherwise idle) states.

Beside all the benefits for system design, in embedded the first two might be the most important. A Z80 interrupt response (until the first instruction of the interrupt routine is executed) takes 11, 13 or 19 cycles depending on the interrupt mode - plus the execution time of the instruction already in process. That adds anywhere up to 23 cycles. When waiting on a HALT it will always be a maximum of 4, thus making interrupt response faster and more predictable.

Does a NOP loop use less power?

Not really, at least not within the Z80 itself. Maybe a bit due to a reduced load on RAM and other perhipherals, but again, it's rather negligible. This may differ on other CPUs. Especially complex ones can save quite a lot using similar instructions.

But the CPU also outputs a /HALT signal to tell when waiting (*1,2). This can be used to disable other components, ROMs for example, as it's guaranteed that no access will be done while active.

Did operating systems (CP/M, Acorn MOS) or Basic variants make use of it?

Not the common ones and not as part of some regular OS handling. Then again it was used in 'drivers' like (IIRC) within the ZX80 video handling to wait for a screen to start. Similar other home computers (MSX?) did/could use it to synchronize animation with frame rate (VBL Interrupt) and/or screen manipulation with line or timer interrupts (*3).

Many embedded environments did use HALT as core function within the scheduler.

Did people writing assembly programs for the CPUs make use of it?

Yes, quite a lot - at least when it came to control/embedded applications.

Aside: How would an interrupt cause an exit of the halt state? After executing the interrupt service routine, would the CPU not return to its previous instruction - the NOP loop?

Nop (SCNR) - When returning from the interrupt, the CPU continues with the next instruction. Keep in mind, it's not executing NOPs, it's just like executing NOPs. HALT is a single instruction, and the PC will already have advanced to the next instruction after it has been read in M1. Thus an accepted interrupt will push the address of the next instruction and when POPed, execution continues there.

This is very handy for a real time/multi tasking system to seperate housekeeping from handling external requests.

---

*1 - On a 8080 D3 is signaling a halt state during status word output in T1 of M1.

*2 - On a 8085 S0/S1=0/0 signal a halt condition. Unlike 8080 and Z80 the 8085 also tristates all data, address and bus control signals.

*3 - While the 6502 did not feature a halt instruction (not until the 65C02), Atari's TIA for the VCS did implement hardware to make the CPU go into a forced halt state when accessing certain addresses much like a 'Wait for Line'-Halt instruction.

Answer 3

Appart tofro's answer there where also another usages of halt.

On ZX (Z80) halt was very often used to synchronize with time. It would halt until the 50 Hz screen refresh interrupt occurs (from ULA). This way the code was synchronized with the screen and can do things like overscan, border effects, multiply resolution or multitech color techniques etc ...

Another reason for synchronizing was to avoid contention, stabilizing FPS with screen refresh, provide timing control, etc ...

Answer 4

The NOP loop is implicit, not explicit. When an interrupt is received, the processor wakes, runs the ISR, then continues with the instruction after the HALT. I presume, but can't verify¹, that the CPU consumes less power when HALTed. Since switching is typically what consumes power in a chip², when the CPU is mostly idle it should draw significantly less power³.

The obvious use-case for this instruction is embedded systems though at the time low-power design wasn't typically a priority.

¹ All the references I have list only maximum power requirements
² Unless you're dealing with e.g. ECL
³ On the Z-80 though, the amount of DRAM and ROM in the system seems to be the main determinant of power consumption

Answer 5

PDP-11 had a 'halt' instruction which terminated execution until someone pressed a key on the front panel, and a 'wait' instruction which stopped execution until the next interrupt. In the context of this question, we're obviously talking about the semantics of 'wait'.

Think about a system architecture where there's one bus used for memory and I/O devices (the Unibus, in the case of the PDP-11), and without cache, so that memory accesses are actually memory accesses.

The point of 'wait' is to get the CPU off the system bus so it's not competing with I/O devices for bus use. The OS executes 'wait' in its idle loop, i.e., when there's no useful computation to be done. Absent wait, you'd need a tight loop. This would access the bus repeatedly to fetch the branch instruction over and over, and those fetches are needlessly using some of the bus bandwidth.

Answer 6

The question asks specifically about microcomputers, but this answer addresses minicomputers, showing how halt was used in one minicomputer, and speculating that the nearly ubiquitous presence of halt in computers could have made its inclusion desirable in the microprocessor if for no other reason than to make the chip easier to sell.

---

The Z80 and 8080 are not early CPU's. They are early microprocessors, however. The halt instruction was used in many CPUs previous to the advent of the microcomputer. This is relevant because one one could argue that an early microprocessor had better have a halt instruction in order to not surprise the buyer. The early microprocessors were being sold to a generation of engineers and programmers who had usually had a halt instruction. If you can easily include a halt instruction, then it would be beneficial when selling the chip to not surprise the buyer by not having one.

One such earlier computer which had a halt instruction was the Modcomp series of minicomputers. These were popular through the 70's for industrial control, scientific computing, and instrumentation. Like many minicomputers, the Modcomp had a front panel with switches and lights.

The lights could indicate the address the computer was executing, the contents of various registers, and so-on. This made the halt instruction perfect for handling an unrecoverable situation (what we might now call a "kernel panic"). This is when the operating system encounters an unrecoverable error so severe that it cannot even print an error message on the system console (perhaps the error is in the console driver itself). In that case, the operating system can load (for example) an error code into a register and then HALT. When the CPU halts, all the lights stop blinking, so it is pretty obvious to the machine's operator that something happened. The operator can then read out the address of the halt, or the contents of the register holding the error code. These would be looked up in a manual which would explain that (to make up an example), code 1234H corresponded to "console driver stall."

The halt instruction was also used in diagnostic programs. The Modcomp series came with extensive diagnostic programs to self-check the CPU, memory, I/O subsystems... everything. These programs used the console (a TTY type device) to display their status and report errors, but sometimes the console could not be written to. For example, the CPU diagnostic may find an error at a basic level that makes writing to the console doubtful. In that case, it would halt, and again the operator would look up the code in a manual to find out what went wrong.

Answer 7

It's a holdover from earlier systems, which turned out to still be useful in some cases.

When a program has finished, to stop the processor is a reasonable thing to do, isn't it? Then you can examine memory and registers, to confirm your program did the right thing, or to check the results etc. The computer should be doing nothing at that time, but should still be on. This kind of practise was described in user manuals of early computers with front panels, such as the PDP-8 or Altair 8080.

Later, in handhelds like the Game boy, similar instructions really stop something or turn something off, until the CPU resumes operation with an interrupt on the following frame for example. That's designed to be good for battery life.

Answer 8

Did operating systems (CP/M, Acorn MOS) or Basic variants make use of it?

The Sinclair Spectrum used the halt instruction in its "event loop". After initialisation, it would execute a halt instruction that would be interrupted on every screen refresh until the user decided to run something. I've no idea why it used halt rather than a no-op loop, maybe they saved a few bytes, or it kept the bus free for other devices.