mjhjmtu

The Z80 has the surprising feature of a second set of registers. I suppose these were intended to be used for rapid task switching or interrupt handling,

Indeed they were intended for fast interrupt reaction. In a simple, general way, this saved the time to push the main process' registers onto the stack and restore them again. they spend single byte opcodes to do so to get the absolute minimum execution time - like the Z80 Technical Manual states on p.26:

OP code 08H allows the programmer to switch between the two pairs of 
accumulator flag registers while D9H allows the programmer to switch between 
the duplicate set of six general purpose registers. These OP codes are only one 
byte in length to absolutely minimize the time necessary to perform the 
exchange so that the duplicate banks can be used to effect very fast interrupt 
response times.

EX and EXX only take 4 T-cycles, while even just pushing a simple 16-bit register would take 11 cycles plus another 15 to load it again. 8 T-cycles instead of 25 or more cycles is a considerably faster reaction, isn't it?

That's also why there are two EX* instruction, as very simple routines may only (use and) need to preserve the flags and A. This leaves the whole second set (except AF) for other purposes. Like being used in normal software, or for even more speedup in I/O.

After all, the second set can not only be used for some kind of fast 'stack' but also be prepared for a certain I/O operation. Think maybe of a serial interface receiving at high speed. Loading things like the memory pointer where received data is to be placed, the number of bytes to receive and so on, does take quite some time (16 T-Cycles for a 16 Bit pointer, 13 for a byte value) - and they need to be stored later on as well.

If these values are placed in the second register set before the high speed interrupt driven routine gets active, no loads and stores are to be executed. Interrupt service time gets reduced to the absolute minimum, not only causing less interruption of the main process but also working up to higher speeds.

After all, the Z80 design was mainly focused on a more flexible, configurable and faster interrupt handling.

though I think if I were programming a Z80 retro computer, I would be more likely to use them for fast access to global variables.

I can't see much gain here. Sure, 6 additional bytes or 3 pointers, but at the same time, you can't access the other ones. So there are not many cases where the secondary register set is helpful - besides interrupts and 'dead end' subroutines.

Such small snippets of Z80 code as I have seen, do not use them, but then, that's not surprising; they are something that would be expected to be only used in large programs.

Well, it's exactly the region where they are useful - to speed up small functions.

Back in the day, I was on 6502 machines, so I never had occasion to write anything non-trivial on the Z80.

Did both, and while they need different approaches, the result is usually quite similar.

Did anyone ever use that second register bank, either for its intended purpose, or just to get more registers within a single task?

It was quite common to use them either for interrupt (mostly in embedded systems) or 'dead end' routines.

For my Aquarius Micro-Expander I used the alternate register set to speed up text display.

The Mattel Aquarius has a character based screen that is physically 40 characters by 25 lines, but to stay out of the overscan area it only uses 38 characters by 24 lines. With such odd dimensions calculating the cursor address takes a lot of code, and combined with other overhead makes printing to the screen quite slow. I wanted to reduce the overhead as much as possible, and also have more flexible line width and positioning.

Here's my core code for putting a character on screen. HL' holds the current screen address and D' holds the cursor position on the line. Higher level routines test and manipulate these registers to wrap at line ends and scroll text in windows.

WinPrtChr:
 EXX
 LD (HL),A ; poke char into screen memory
 INC HL ; HL' = next screen address
 INC D ; D' = next screen x
 EXX
 RET

BackSpace:
 EXX
 LD (HL)," " ; poke SPACE into screen memory
 DEC HL ; HL' = previous screen address
 DEC D ; D' = previous screen x
 EXX
 RET 

Using alternate registers was much faster than storing the variables in RAM, and kept the normal registers free for other uses. The result was fewer memory accesses and faster operation in general. My code prints text into windows of arbitrary size about 20 times faster than the system routines.

Unfortunately the Aquarius system ROM also uses alternate registers when scanning the keyboard, so I had to wrap the keyboard routines with a pair of EXX's (to get back to the normal register set) and save the affected registers on the stack when getting keyboard input. However I didn't have to worry about interrupts (where the alternate register set is often used for fast context saving) because the Aquarius doesn't have any!

A specific example is the chess program Sargon (written in 1978 or a bit earlier), which used them in a couple of leaf subroutines.

Search the assembler listing at http://smecers.appspot.com/govs/Oldies/Sargon.htm for the EXX instruction. (It's in routines XCHNG and NEXTAD)

The code is well documented, if anyone wants to explore the cost of alternative coding techniques.

Apart from Sargon, I'm pretty sure they were used in the code examples in some "how to write interrupt routines" books of the period, as a "quick" way to save all the registers, but I don't have any references or that.

The question asks if the alternate register set was "ever" used ... this answer is about a modern use of it.

The z88dk C compiler, sccz80[1] uses a calling convention where the registers B', C', D', E', H' and L' are used to hold the first 48-bit floating point argument to a function, or a floating point return value. Benchmark results suggest that this is a very good strategy, as the results are similar in performance to the 32-bit floating point used by most other Z80 C compilers.

[1] - actually, one of the two C compilers that are part of the z88dk toolchain, the other being a patched version of sdcc that uses 32-bit floats with a different calling convention

As usual, the Z80 Oral History provides some insight into the motivation behind the alternate registers and exchange instructions:

[Faggin]

So I wanted to
have a couple of index registers, more 16-bit operations, a better
interrupt structure. The whole idea of doubling the number of
registers. And I could exchange the register with an exchange
instruction, the whole register set. That was an idea that I had used
already on the Intel 4040. So that one could serve it up very fast if
that was a necessity. And on and on.

[Shima]

Thirdly, in order to support the highspeed
task switching, in the beginning I asked to complete two sets of register files including the program
counter. But it was too complicated for customer. Then we gave up on [the idea] of the two sets of
general purpose registers.

...

And two instruction codes were used for the exchange, the set of
general purpose register, and exchanging the set of accumulator and
flags. Also those support the high-speed task switching.

(And while it may be obvious, it's worth pointing out that in the silicon implementation, the exchange instructions merely modify the state of the register file addressing logic.)

Did anyone ever use that second register bank, either for its intended purpose, or just to get more registers within a single task?

This being one occasion when a personal experience answer will do, EXX is ideal for the very specific task of multiplying a 16-bit 2d vector by a scalar, which makes it helpful for 2d vector graphics, and the projection part of 3d vector graphics.

Specifically:

• use A for the multiplier — rotate right from it into carry;


• use BC and BC' for the working copy of the multiplicands; these will need shifting left on each iteration;


• use HL and HL' to accumulate the result; perform ADD HL, BC if carry is set after the RRA.

So the specific convenient observations are:

• you're juggling four 16-bit quantities, but they interact only in pairs;


• and using EXX lets you use the 16-bit arithmetic that's right there on the main instruction page.

Following the spirit of personal examples, here's one from when I was in high school: I, like everyone else, used a Ti 84 calculator for my Math classes. Said calculator used a Z80.

Out of a mixture of boredom and curiosity, I wrote a program that printed "WOZ IS ALWAYS THE ANSWER" any time the user hit the enter key. The program didn't need to be running for this to happen, and it could happen anywhere in the menu system.

To do that, I used the chip's interrupts to check the input every 1/140th second. The thing is, each time I checked, I had to corrupt the A register. The input methods simply couldn't get around that. So, if I had just used A, the A register would be switching values for every other program run. That wouldn't work.

Instead, I switched into the shadow registers, did the input checking, switched back, and waited for the next call. It worked out pretty well, and did the job!

Back in the early 90s I used the alternate registers in 3 different ways:

1. For task switching in a dual task "operating system".


2. In a RAM-less control application, temperature sensors and relay control. (208 bits in total was enough).


3. In a floating point library. The latter was also done by several others (and better than my attempt), see for example http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html
   

Sorry to rain on any parades but, while it's been a long time since I did any serious Z-80 programming, I distinctly remember the alternate registers being one of the major broken features of the Z-80.

You see, they could be used to either:

• Speed up interrupt handling.


• Store alternate data in your main code.

The thing was you could not do both.

So if I was writing a device driver with an interrupt service routine, I could not use the alternate registers to save pushing and popping the main registers. I of course would need to avoid doing this in case the application programmer was using those registers.

And if I was writing application code, I could not use the alternate registers because an ISR could trample all over my data.

The overall result was that most programmers stayed away from the alternate register sets so that there code would run on more machines without crashing and burning. Any savings was swamped by the risk of shipping non-working code.

Safe code may be slower, but broken code does not run at all.

Of course if you have the luxury of controlling all aspects of the system and its coding, you were free to do as you please. I never had that luxury.