How the Z80’s 4-bit ALU works (2013) | Hacker News Reader

How the Z80’s 4-bit ALU works (2013)

righto.com

97 pointsandars41 comments

I seem to remember that the 68000 does something similar, using a 16-bit ALU to implement an ISA with 32-bit registers; part of the performance gain upgrading to the 68020 was shaving off the extra cycle from a bunch of instructions thanks to an actual 32-bit ALU.

Good point about the 68000. It has three 16-bit processing sections: low address, high address, and data. So it can compute a 32 bit address at once, but takes two steps for a 32 bit ALU operation.

I seem to remember Intel first implemented one of the SIMD instructions as two sequential operations operating on half the size of the full SIMD register. Then later refinement of the chip (maybe after transistor size shrunk) they then could do the entire SIMD operation at once in parallel instead of sequentially. But this was all hided under the ISA, so you wouldn't know unless checking the clock cycles.

I'm not sure if you're referring to something different or just confused it with the ALUs on the P4 (NetBurst), which were divided into two 16-bit halves and took one more clock cycle (actually a half, because these were effectively "DDR" clocked) to obtain the full result if there was a carry between them.

http://www.realworldtech.com/isscc-2001/7/

https://gmplib.org/~tege/x86-timing.pdf

http://arstechnica.com/gadgets/2006/04/core/4/ has an explanation of how the P6's data buses were only 64 bits wide.

thanks! That's what I was remembering:

"The P6 core's internal data buses for floating-point arithmetic and MMX are only 64 bits wide. Thus the data input ports on the SSE execution units could only be 64 bits wide, as well. In order to execute a 128-bit instruction using its 64-bit SSE units, the P6 must first break down that instruction into a pair of 64-bit instructions which can be executed on successive cycles."

According to Agner the Skylake puts the top-half of the 256-bit AVX execution units to sleep when they're not in use, and during the warm-up period when you first start using them again, 256-bit operations are done by using the bottom 128-bits of the XUs twice.

http://www.agner.org/optimize/blog/read.php?i=415

I believe that's also how 256-bit AVX is implemented on current-gen consoles' AMD SoCs, as two sequential 128-bit ops.

That's a common strategy for Intel: get the instruction out the door and let programmers build on top of it, and then in the next revision, make the instruction fast.

One benefit of this strategy is that it makes it more difficult for 'other' x86 vendors to maintain binary compatibility if the industry leader is constantly changing what 'binary compatibility' means.

Could be that the reason of the 6502 being, clock per clock, faster than the Z80?

P.S. please consider adding "(2013)" to the title

Sure (though not the only reason). I'd also expect it is one of the reasons why the Z80 was able to achieve significantly higher clock speeds than 6502 or 6510.

Another interesting fact: If I'm remembering correctly, some models of the PDP8 had only a 1 bit ALU to reduce the purchase price. I thought this was pretty wild when I first heard it, but I guess the performance hit was ok if you could gain access to a computer at all.

The PDP-8/S was the serial model. Serial processors weren't uncommon in the "old days". Other examples are the F-14 CADC (an early MOS processor) and the Datapoint 2200 (whose architecture was turned into the 8008). Many of the early aerospace computers were serial because of weight constraints, such as the Arma Micro (on the Atlas), IBM ASC-15 (on the Saturn I and Titan) and the Autonetics D-37 (on the Minuteman).

And then there's the Motorola MC14500B, which was genuinely a 1-bit microprocessor. It was used for simple control operations to replace relay logic.

The CDP1802 also used a serial ALU:

http://www.visual6502.org/wiki/index.php?title=RCA_1802E

Each instruction took either 16 or 24 clock cycles due to this, and although other operations were done in parallel and could have been significantly faster, I guess performance was not much of a concern back then as making the microsequencer as simple as possible.

Discrete "bit slice" ALU chips were common in early IC computers, tackling only a few bits of the ALU each. Hardware designers could chain those together to get as wide a hardware ALU as necessary, within the timing constraints.

https://en.wikipedia.org/wiki/74181

Remember, these processors were designed either by hand or with very primitive CAD tools (6502 was designed and taped 100% by hand)

Positioning and routing between thousands of transistors was a daunting task. I believe a lot of simplifications were done because of that as well

...well that helps explain the famous 4x speed difference between the Z80 and the 6502.

Famous? Are you referring to performance or just clock frequency? The Z80 takes more cycles to do the same operation as the 6502, but it also (typically) had a higher max clock frequency, mostly making up for it.

I was referring to the fact that a 1MHz 6502 could match a 4MHz Z80.

>but it also (typically) had a higher max clock frequency, mostly making up for it.

That used to be true. It is no longer true nowadays, so 65C02 beats the Z80 speed-wise.

Except Zilog came out with successors to the original Z80 that were far more cycle efficient. For example the eZ80, which can clock up to 50mhz.

Not exactly "more cycle efficient", just more modern manufacturing processes. There are also 6502s available for up to 200 MHz. They are not easily available to hobbyists, though - the modern DIP modules are only guaranteed up to 20MHZ, but they can be run at 25MHz.

It got a few more upgrades than just better miniaturisation:

> The eZ80 has a 3-stages pipeline. Available at up to 50 MHz (2004), the performance is comparable to a Z80 clocked at 150 MHz if fast memory is used (i.e. no wait states for opcode fetches, for data, or for I/O) or even higher in some applications (a 16-bit addition is 11 times as fast as in the original). The eZ80 also supports direct continuous addressing of 16 MB of memory without a memory management unit, by extending most registers (HL, BC, DE, IX, IY, SP, and PC) from 16 to 24 bits. In order to do so, the CPU works in a Z80-compatible mode or a full 24-bit address mode.

https://en.wikipedia.org/wiki/Zilog_eZ80

Note the pipelining, and the 24 bit ALU

No I believe they actually made them more cycle efficient. And the eZ80 is available to hobbyists at the high clock rates if you're willing to do SMT.

Pardon my ignorance on the topic, but I've often wondered if it's possible to take one of these older CPU designs and "just" increase the address space and make the manufacturing process smaller (but otherwise leave the instruction set and architecture as-is) to create a modern bit version at a high clock rate for embedded or mobile use? Or is there a lot of "devil in the details" that has prevented such a thing from existing?

It seems to me like upgrading one of these existing designs would be much cheaper R&D wise that you'd be able to compete very well on price for the IoT or other markets.

While it might (I don't know) be possible to make the manufacturing process smaller, you couldn't increase the address space without effectively rewriting the entire ISA. You could use bank switching or an MMU to increase the effective address space (allowing the machine to access more RAM than it can physically address), which was done even back in the day, on pretty much every machine.

>you'd be able to compete very well on price for the IoT or other markets.

Why do you think that the Z80 and the 6502 (and their derivatives) are still on the market? :-D

If a 1 MHz 6502 could match a 4MHz Z80 then that would mean a C64 could match a ZX Spectrum (which was clocked at 3.5 MHz) for performance in not sprite blitting scenarios.

Which it couldn't.

The spectrum smashed the C64 for speed of numerical operations, that's why the specrrum had lots of wireframe and solid filled 3d games and the C64 didn't.

Like, Carrier Command on the Spectrum vs the abomination that appeared under the Carrier Command logo that appeared on the Commodore.

It's been 30 years man, let it go.

Never!

sure http://www.hardcoregaming101.net/freescape/freescape.htm

nothing like a rose tinted glasses and fanboizm when it comes to membering those fluid 60fps full color FPS Spectrum games.

Sorry, what were you saying? I fell asleep waiting for the C64 version of Total Eclipse to render a new frame

The 6502's two-phase clock throws a wrench in direct clock speed comparisons, no?

>The 6502's two-phase clock throws a wrench in direct clock speed comparisons, no?

Not really? The two phases are more or less just inverted versions of each other[1], but 1 clock cycle, for the purposes of counting cycles-per-instruction, is the same time (I think) whether you're measuring phase-1-high to phase-1-high or phase-2-low to phase-2-low.

[1]http://lateblt.livejournal.com/88105.html

The "two-phase clock" is just the alternate halves of one square wave. The 6502 accesses memory during one half and processes during the other. Only one clock signla is needed, and one instruction will be completed at the end of every complete clock cycle.

Fun fact: you can run a dual core 6502 system by hooking up the two processors to the same memory bus, one using an inverted clock. (Slightly more complicated than that, but only slightly.)

The Commodore Pet disk drives used this trick; one processor was the application processor, which listened for IEEE488 commands and handled the disk format; the other processor handled the low-level stuff (we'd call it a DSP today).

Yes, the Pet disk drive did have twice the number of processors as the computer it was attached to.

http://www.6502.org/users/andre/petindex/drives/arch/index.h...

And then you got the Amiga that apparently took that a step further by having the chipset act independently of the cpu, with a but of circuitry sitting in the middle to make sure they didn't both access the shared ram at the same time.

It's immensely charming that you are keeping lit the flame of this three decade old argument.

See http://www.ffd2.com/fridge/speccy/score

Is there a reason to implement decode logic in a PLA as opposed to ROM?

A PLA is much more efficient than a ROM because it can take advantage of "don't care" entries. Specifically, the 6502 has a 130x21 PLA = 2730 entries. A ROM would need 11 inputs (instruction + timing) and 130 outputs, so 130*2^11 = 266240 entries plus the decoding logic.

(You could reduce the ROM size by using tricks such as multiple levels of ROM or partially decoded ROMs.)

Instruction sets are usually defined so groups of bits have meanings and can be decoded separately. This makes the PLA a good fit.

For a specific example, the 6502 PLA decodes instructions matching 100XX1XX to the control line STY (ignoring the timing bits for simplicity). This takes 1 row in the PLA, but it would take 16 entries in a ROM.

More info on the 6502 PLA: http://visual6502.org/wiki/index.php?title=6507_Decode_ROM

Thanks for the excellent answer and the link!

I thought ROM had something similar to "don't care" bit which was a 0 was represented by the absence of a transistor. Or does "don't care" mean something else?

Z80 - my first CPU.

Reply on news.ycombinator.com