How the Z80's registers are implemented

http://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html

by zdw • 12 years ago

142 24 12 years ago

A little comment regarding the Z80 vs 6502 register count: I always consider the 6502 to have 256 registers (zero page) and an accumulator and two index registers. Never a shortage if you use it like that...

derefr• 12 years ago

It'd certainly be interesting to write a C compiler codegen target for the 6502 that treated the zero-page as registers (and a lot easier to map modern compiler intrinsics to than the tiny base register set.)

sklogic2• 12 years ago

It was discussed recently in LLVM mailing list: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074530....

Chances are, someone is already working on an implementation.

kps2• 12 years ago

Some years ago I worked on a C compiler for a processor, which, like the 6502, had no general-purpose registers and a ‘fast page’, and we did exactly that.

pdq2• 12 years ago

I would think of the zero page as a rudimentary L1 cache, because the access times to the zero page requires a lookup cycle, whereas registers do not.

TheLoneWolfling3• 12 years ago

On a related note: I wish that more CPUs had an explicit cache. So data has to be explicitly loaded into cache, etc.

Modern CPUs are NUMA. Don't treat memory as RAM any more, because that's not true.

Biggest problem with this is that not all CPUs have the same amount of cache. But you can get around this by treating the cache as the low area of RAM, with instructions to get the amount of cache available. Especially if cache is also paged.

Other issue with this is context switches, but this is conceptually no different than paging RAM to disk when required.

muyuu• 12 years ago

In comparison with the Z80 it's roughly equivalent. It took about the same time to load/store indirectly in/from zero-page as it took the Z80 to load/store directly from registers. The 6502 ran roughly in 2 cycles per instruction (average) while the Z80 took about 3 average M-cycles (3~6 T-cycles per M-cycle) per instruction. The 6510 (6502-compatible but with some extra I/O) in the Commodore 64 could out-pace the Z80 in the Spectrum 48 which ran at more than triple the clock speed except maybe in some carefully crafted proof of concept.

Conversions to C64 from Spectrum were routinely done by hand, routine by routine, as the C64 could "emulate" the Speccy this way. For instance games like The Great Escape ( http://www.crashonline.org.uk/35/greatescape.htm ) was converted this way, as were other games (it was a bit disappointing when this happened, as it basically meant not using the C64 graphic sprites and its tricks.

VLM• 12 years ago

If you think swapping via register renaming is creative, you'd really like barrel shifters.

http://en.wikipedia.org/wiki/Barrel_shifter

The easiest way to shift bits isn't "adder like" with carry propagation across data lines (sorta), although that could be done. The easiest way is just to phase distort the bus (sorta) so what you called bit X is now bit X-4 for all bits on the bus, and use a 2x1 mux to select which, and cascade rollers in binary (you don't need a roller for all integer numbers if you can cascade them 16, 8, 2, 1 position only activating some rolls). If you can rotate, you can shift by adding one more stage at the end that does bit oriented ops to clear MSBs or LSBs. Also if your roller is capable of rolling all bits on the bus, you don't need two rollers one in each direction. Latency does add up of course, all those cascaded ops.

Also I saw in the notes the Rodney Zaks z80 book being referenced. I learned assembly from that book, back when it was new. I enjoyed that book. I also looked at the PDF scan of someone's beat up copy... remember when textbooks were only $10.95 each?

kator• 12 years ago

I still have my original copy of Zaks' book in my collection. I obtained it in 1981 from a friend. I did so much z80 assembly on the TRS-80 that I could "see" instructions in a hex dump before asking zbug to disassemble them.

The z80 was quite the chip for its time and I enjoy reading these articles has they look back into the deeper inner workings of the chip.

One could master the z80, I'm not sure many modern processors could be mastered at that level by a single programmer. They seem to have gotten so complicated that they're beyond comprehension in a single person's mind. I could be wrong but that's the general feeling I get. Sure you can be really good at them and maybe an expert in many applications of a modern complex processor but I doubt many people have a singular understanding of everything each chip has to offer.

Or maybe I'm just getting old.. :-)

userbinator2• 12 years ago

The 8086, which is based on the Z80, is not that much more complicated (even the opcode structure is similar, being an octal format), and same goes for the 80186. Things started becoming a bit more complex with the '286 and its protected mode, and then the '386+ with 32-bit and its various protected-mode enhancements really made it harder for a single person to master fully, but I think it was still mostly possible; the really hairy stuff started with 64-bit mode and all the extensions (e.g. virtualisation) that have been made to that since.

On the non-x86 side, modern ARM SoCs like the ones used in smartphones are not all that much simpler despite a less complex CPU core - they're still thousands of pages of documentation in total.

teh_klev• 12 years ago

Blimey, I'd forgotten all about Rodney Zaks. I had a copy of his "Programming the 6502" book back in the early and mid 80's when I used to hack out BBC Micro sideways ROM odds and sods. What a blast from the past.

TheLoneWolfling3• 12 years ago

Meh, at least it's sublinear latency with the number of bits. (I'm assuming, based on the description. Unless there's something I'm missing, you've got log2(d) stages of O(1) latency.)

The nasty operations are the ones that are linear (or worse!).

rwmj• 12 years ago

Interesting that the flags are stored like the other registers. I had always assumed that the flag bits would be "spread out" across parts of the ALU, and only combined with the accumulator into a virtual register when you read the AF register. In fact they are stored in the register file and copied to and from the ALU on every(?) operation.

Animats• 12 years ago

It's cool seeing register renaming in an early microprocessor. Doubling up all the registers takes a lot of silicon, and is unusual for that era.

userbinator2• 12 years ago

I don't know if the term "register renaming" was even around at the time since the other instructions (e.g. MOVs) don't "rename" registers, but they certainly had the right idea - "why move the data around when you can just change the register selection bits?" It's also how I expected the exchange instructions to work when I first saw the instruction set and the timings, so it's probably a rather natural and obvious way of doing it.

I did it the same way when I designed a Z80-compatible CPU in a (graphical) logic simulator, although I used a dual-ported register file.

agoetz• 12 years ago

agumonkey• 12 years ago

The renaming trick makes me feel a cpu is just a fixed size activation frame/scope under reduce/fold.

How the Z80's registers are implemented

Related Stories