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.
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.
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.
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.
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.
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.
>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.
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.
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.
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.
"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.
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.
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.
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.
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?
41 comments
[ 44.2 ms ] story [ 1567 ms ] threadAnd then there's the Motorola MC14500B, which was genuinely a 1-bit microprocessor. It was used for simple control operations to replace relay logic.
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.
https://en.wikipedia.org/wiki/74181
>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.
> 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
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.
>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
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.
nothing like a rose tinted glasses and fanboizm when it comes to membering those fluid 60fps full color FPS Spectrum games.
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 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...
http://www.realworldtech.com/isscc-2001/7/
https://gmplib.org/~tege/x86-timing.pdf
"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."
http://www.agner.org/optimize/blog/read.php?i=415
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.
P.S. please consider adding "(2013)" to the title
(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
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?
Positioning and routing between thousands of transistors was a daunting task. I believe a lot of simplifications were done because of that as well