I built a computer around the Z80 from a kit of a TV Series („Klein Microcomputer Sebstgebaut und Programmiert“) when I was 12, with a Märklin trafo as power source and a Telefunken tape recorder as datasette. Typed moon lander into it in Z80 machine code and was so afraid to lose the program that I didn‘t turn it off for 2 weeks.
The Zilog Z80 has turned 50
111–120 of 131 posts
Re: The Zilog Z80 has turned 50
#112As the proud owner of a ZX-81 I remember staring at the Z80 instruction reference at the end of the user's manual without the faintest clue of what any of that meant. It took me some while before I managed to wrap my head around how CPUs actually run programs (vs. the high level abstractions like BASIC or other languages).
Actually, BASIC’s flat structure helped me a lot in understanding Z80 assembly when I was 12. You see, memory addresses were line numbers, registers were variables, JP was GOTO, CALL was GOSUB. CP was IF, JP, Z was THEN GOTO, and LD was LET, and so forth.
> You see, memory addresses were line numbers, registers were variables,
There was only a single[1] register though, the accumulator.
[1] Okay, there was the PC as well. Maybe a flags register too? But only one used for variables, IIRC.
Re: The Zilog Z80 has turned 50
#113This reminds me, a couple of months ago I made my Z80 assembler public on GitHub [1] but never mentioned it anywhere.
It has the usual opcodes and directives, includes, relocation data etc, with a couple of other helpful output files alongside the expected binary one.
Because the driver for it was coding on the ZX Spectrum it will also create tap files with a BASIC loader and loading screen support. And it has a not very featuresome sprite editor built in for the Spectrum screen and attributes. Oh, and a PNG-to-SCR conversion process for loading screens that does a bit of work to show problem areas (as heatmaps).
It's only actually been used by myself and one other person so there may be a few hiccups, but it WOMM :)
Re: The Zilog Z80 has turned 50
#114Earlier quoted context omitted.
IMO, the "out-of-order performance/complexity" excuse is complete bullshit. Out-of-order pipelines actually have a really elegant way of handling flags, they just store a copy of the flags register on every ROB entry. During renaming, instructions that consume flags just gain an extra implicit input pointing to the ROB that will contain the correct flags. Such pipelines already need deal with so much serialised state…
> Out-of-order pipelines actually have a really elegant way of handling flags, they just store a copy of the flags register on every ROB entry. And yet, flag writing instructions are usually half the throughput on regular ALU instructions, on modern wide ooo designs. [1, 2] But I generally agree, there is a good way of handling them, it's hust unclear to me how expensive it is. It can't be that expensive, but apparen…
I wonder if the issue is actually the cost of calculating the flags.
N and C are basically free (copy of bit 63, and it's carry out), V is an extra gate or two, but Z requires a full 64-bit wide NOR gate.
Or it might be about making the register file holding the flags smaller (only 3R3W, instead of 6R6W), along with simplifying the associated bypass network and routing (the first three ALUs are also the only units that can consume flags).
When I say ooo cpus get flag handling for "essentially free", I'm only actually talking about the complexity of tracking "implicit state", and that it can be done without extra latency. You still need to spend transistors to support renaming flags, and to actually calculate and storing the flags.
I can see an argument for an ISA that got rid of the N and Z flags, but kept C/V (potentially merged into a single flag). You can trivially reconstruct N/Z from the result register, but not C/V.
Re: The Zilog Z80 has turned 50
#115Earlier quoted context omitted.
taking architecture that explicitly removed carry flag for performance and then trying to to emulate carry flag anyway was stupid in 2021 and is still stupid today even on x64 you get better performance when you don't use carry flag and just use limbs https://www.chosenplaintext.ca/articles/radix-2-51-trick.htm... - risc-v is even more so and experimentally gmp bench results show performance in line with arm https://…
Limbs work well only when the operations with them are implemented with vector or matrix instructions. Using limbs is a workaround for the fact that most vector instruction sets also do not implement carry flags (an exception was the discontinued Intel Larrabee). Moreover, usually the fastest integer performance is obtained when using the floating-point multipliers, which limits the size of the limbs to 52 bits. Desp…
> Regarding the benchmarks linked by you, they do not seem so bad as they really are only because they are not compared with x86 CPUs or with any ARM CPU more recent than the 10-year old and obsolete Cortex-A72, which is many times slower than modern ARM CPU cores
"why do you compare 15y.o. chess GM against 15y.o. Carlsen instead of world champion he is today? if you do you'll see how pathetic performance actually is"
everything gets a weight category. immature architecture gets benched against immature state of architecture. narrow OoO gets compared against narrow OoO
check in 4 more years for results closer to frontline - but where we are, theoretical worries did not come to pass
Re: The Zilog Z80 has turned 50
#116Earlier quoted context omitted.
risc-v has no flags period modern out-of-order execution gets hindered by such non-parallel cpu state, so it wasn't included
In modern OoOE CPUs the flag register is renamed, like all other architectural registers, so it does not hinder in any way the parallel execution. OoOE CPUs need hundreds of registers in order to not hinder the parallel execution, so even the 32 general-purpose registers are not enough, so they must be renamed. Once register renaming is implemented, it does not matter any more if there is a single architectural flags…
> That allows the parallel execution of up to 8 instructions per cycle, even without register renaming
Though, PowerPC implementations (like the PowerPC 750) do have renaming of condition registers, which allows them to speculatively execute CR write instructions (though the PowerPC 750 can't speculatively read a CR, it can only speculate one branch at a time).
But I suspect other justification for renaming CRs, is that register renaming is actually how the PowerPC designs from that era handled hazard detection and result forwarding (and maybe why such designs only a few renaming registers, six GPRs and six FPRs on the 750)
Re: The Zilog Z80 has turned 50
#117Earlier quoted context omitted.
> Out-of-order pipelines actually have a really elegant way of handling flags, they just store a copy of the flags register on every ROB entry. And yet, flag writing instructions are usually half the throughput on regular ALU instructions, on modern wide ooo designs. [1, 2] But I generally agree, there is a good way of handling them, it's hust unclear to me how expensive it is. It can't be that expensive, but apparen…
I wonder if the issue is actually the cost of calculating the flags. N and C are basically free (copy of bit 63, and it's carry out), V is an extra gate or two, but Z requires a full 64-bit wide NOR gate. Or it might be about making the register file holding the flags smaller (only 3R3W, instead of 6R6W), along with simplifying the associated bypass network and routing (the first three ALUs are also the only units th…
That seems like a weird thing to save on, for architectures that have expensive but rarely used things like CLZ on all ALUs.
But I hadn't considered the ISA design option of only carry flag, no seperate cmp and branch, before.
Re: The Zilog Z80 has turned 50
#118Earlier quoted context omitted.
Actually, BASIC’s flat structure helped me a lot in understanding Z80 assembly when I was 12. You see, memory addresses were line numbers, registers were variables, JP was GOTO, CALL was GOSUB. CP was IF, JP, Z was THEN GOTO, and LD was LET, and so forth.
> You see, memory addresses were line numbers, registers were variables, There was only a single[1] register though, the accumulator. [1] Okay, there was the PC as well. Maybe a flags register too? But only one used for variables, IIRC.
You seem to be confusing Z80 with 6502.
Re: The Zilog Z80 has turned 50
#119Earlier quoted context omitted.
> You see, memory addresses were line numbers, registers were variables, There was only a single[1] register though, the accumulator. [1] Okay, there was the PC as well. Maybe a flags register too? But only one used for variables, IIRC.
You seem to be confusing Z80 with 6502.
> You seem to be confusing Z80 with 6502.
You're quite correct, I did confuse the two.
Too late to edit it now, but at least your response will stand as a correction.
Re: The Zilog Z80 has turned 50
#120Earlier quoted context omitted.
I wonder if the issue is actually the cost of calculating the flags. N and C are basically free (copy of bit 63, and it's carry out), V is an extra gate or two, but Z requires a full 64-bit wide NOR gate. Or it might be about making the register file holding the flags smaller (only 3R3W, instead of 6R6W), along with simplifying the associated bypass network and routing (the first three ALUs are also the only units th…
That seems like a weird thing to save on, for architectures that have expensive but rarely used things like CLZ on all ALUs. But I hadn't considered the ISA design option of only carry flag, no seperate cmp and branch, before.
Huh, it does have CLZ on all ALUs (And CLZ can actually be used to reduce the cost of checking for all zeros).
So it must be something about limiting the complexity of the flags register file and/or its bypass network.
> But I hadn't considered the ISA design option of only carry flag, no seperate cmp and branch, before.
Well, RISC-V does have a decent point: Most of the time you simply don't need flags. The only area this approach falls apart is detecting overflow or add-with-carry.
So, why not just cover that flaw by adding a carry/overflow flag.
The counter-argument is that as soon has you "ruin the purity of the design" by adding one flag, you might as well add the complete set of all four. Then you can simply branch instruction encodings, and use the extra bits for something else (like seperate set-flags versions of all the ALU instructions)