# Uses for the halt instruction?

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?

• Modern CPUs still have a HLT instruction ;-). – Stephen Kitt Jun 16 '18 at 8:40
• @Stephen - I think modern CPUs no longer have the closely related HCF Instruction - or do they? – davidbak Jun 16 '18 at 23:09
• @davidbak A combination of masking all interrupts and then HALT (or whatever your corresponding instruction is), does exactly what HCF did. – tofro Jun 17 '18 at 15:44

The HALT condition does (at least on retro CPUs) not 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 until execution goes on).

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
• Are you eventually mixing up the HALT instruction and /BUSREQ signal? Halt doe not put the CPU into tristateing the data/address/controll lines. In fact it will continue active operation on the Bus as a series of M1 cycles with a memory (refresh) cycle on T3/T4 (AFAIR even the instruction fetch on T1/T2 continues, just its result is dumped). You might want torecheck the Z80 manuals, not just commodores special ciruitry. – Raffzahn Jun 16 '18 at 9:37
• @Raffzahn you did read the part about refresh? And the part where the HALT line can be used to do the bus isolation? – tofro Jun 16 '18 at 10:26
• You describe it as the Halt state of the Z80 puts the CPU into tristate, which it does not. Tristate is only available during /BUSACK. It might be helpful to clarify that yo uare not refering to what the OP asked, but some random additional hardware. – Raffzahn Jun 16 '18 at 10:36
• Of course the question of whether or not any particular use was intended when the instruction set was designed isn't particularly relevant for the Z80, which copied most of its instruction set (including HALT) from the Intel 8080. The behaviour of the 8080 with regards to whether or not the processor is disconnected from the bus may be more relevant. The 8080 datasheet explicitly acknowledges this use of the halt instruction: "The HOLD signal requests the CPU to enter the HOLD state. The HOLD state allows an external device... – Jules Jun 17 '18 at 3:55
• ... to gain control of the address and data bus as soon as the 8080A has completed its use of these busses for the current machine cycle. It is recognized under the following conditions: • the CPU is in the HALT state. • the CPU is in the T2 or TW state and the READY signal is active. As a result of entering the HOLD state the CPU ADDRESS BUS (A15-AO) and DATA BUS (D7-00) will be in their high impedance state. The CPU acknowledges its state with the HOLD ACKNOWLEDGE (HLDA) pin". HOLD and HLDA are the 8080 equivalent pins to BUSRQ and BUSACK on the Z80. – Jules Jun 17 '18 at 4:00

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.

• It would be fairly easy for a program to cut the interrupt uncertainty from 23 cycles down to ten by getting into a "jump back to same instruction" loop which is stored in RAM; when the interrupt fires, it could patch the jump to proceed to the next instruction. On the other hand, ten cycles is still a lot more than four. – supercat Jun 18 '18 at 14:48
• BTW, I wonder on the 8085 or Z80 if it would have been more advantageous to have the halt instruction put the Z80 into a special state, or simply have it decrement the PC before fetching the next instruction? In most cases the behavior would be equivalent, but a memory-mapped I/O device with a location that yields $76 until a condition is "ready" and$C9 [ret] after [taking care to synchronize the change so it doesn't happen right when the instruction is being fetched] could allow a faster response to a stimulus than would be possible using an interrupt. Of course, memory-mapped I/O... – supercat Jun 18 '18 at 14:56
• ...wasn't very common on the Z80, but if one had a spare address-range decode were available and a latch/synchronizer with true and complement outputs, one could easily add such functionality to a system if needed. – supercat Jun 18 '18 at 15:04

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 ...

• On the Amstrad CPC, too, HALT was used both in the operating system and assembly programs to synchronize programs with video output, allowing various video effects not possible otherwise. After syncing the CPU once per frame, cycle-accurate assembly programming allowed a treasure trove of possibilities: more color displayed at once, mix video modes, multiple simultaneous hardware scrolling, showing same RAM area multiple times while modifying it or the color palette, etc. One extreme example: 3D meets the aging bits by Logon System :: pouët.net – Stéphane Gourichon Jun 17 '18 at 5:51
• @StéphaneGourichon see Z8410 DMA chip as GPU? especially the MultiTech examples in the DATA GEAR link at the beginning ... I usually used halt for doubling the screen y-resolution (without DMA) – Spektre Jun 17 '18 at 6:34
• yes I've seen it when you posted it. – Stéphane Gourichon Jun 17 '18 at 17:19

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 verify1, that the CPU consumes less power when HALTed. Since switching is typically what consumes power in a chip2, when the CPU is mostly idle it should draw significantly less power3.

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

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

• Internal power savings are neglectable as the register file is static and memory cycles are still done for refresh. Similar DRAM (if present) will still have a next to ordinary activity pattern as a refresh access is comming allong with each interation. – Raffzahn Jun 16 '18 at 8:36
• @Raftzahn Yea, that's the impression I get from the docs. The vast majority of power is going to DRAM refresh. Methinks there's a reason all the documentation lists only maximum current... – Alex Hajnal Jun 16 '18 at 9:03
• Jup. But also that, at least with early (and NMOS) microprocessors the differences wheren't much noticepble. in fact, production variations coud have a much greater effect on over all consumption. – Raffzahn Jun 16 '18 at 10:38
• @Raffzahn Power usage is surprisingly good though, 5V ~200 mA max @ 2.5 MHz according to one of my sources. – Alex Hajnal Jun 16 '18 at 11:11
• @Raffzahn That's for the Z-80. Another one states each 2k×8 2716 EPROM is 75 mA and each 1k×4 2114L RAM is 50 mA. – Alex Hajnal Jun 16 '18 at 11:19

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.

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.

• Halt is more efficient than a no-op loop. When an interrupt happens, the next instruction to be executed is the one right after the halt. With a no-op, your logic needs to test and branch. Yeah, it is only a few cycles but a few cycles is more than near-zero. – bjb Jun 19 '18 at 16:50
• You can also preload all registers for immediate action after the interrupt - In a loop, you couldn't, because you need some for the loop itself. – tofro Jun 19 '18 at 16:52

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.

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.

• to my knowledge halt has nothing to do with power saving modes. For that are usually some control registers used instead. The debug process you describe was not used commonly. First time I saw it on some DOSBOX debugging QAs on SE/SO (only recently). User programs are supposed to return to parrent code by ret instruction instead. The inspection of registers where done by monitors (IIRC DEVASACE on ZX etc) and or IDE – Spektre Jun 16 '18 at 10:27
• Of course it was not commonly used, only when debugging low-level code like bootstraps or whatever. And on very early minicomputers some programs really would spit out their output and then halt the CPU. – OmarL Jun 16 '18 at 11:06
• In CMOS Z80, HALT still has something to do with power save mode. By stopping clock during the specific clock cycle of the instruction, Z80 is entered low-power mode (that's according to datasheet). – lvd Jun 18 '18 at 10:16