Live data from Hacker News

The Zilog Z80 has turned 50

goliath32.com

91–100 of 131 posts

Re: The Zilog Z80 has turned 50

#91
post #80

Earlier quoted context omitted.

It doesn't have a carry flag either. Multiprecision integer operations absolutely suck in RISC-V, you need three operations (SLT and two adds, with an awful dependency chain too) to do an add with carry, and op fusion can only do so much. At least add an instruction that computes the carry out, like "Rd = Cout(Rs1 + Rs2)" and the similar one for overflow... https://gmplib.org/list-archives/gmp-devel/2021-September/00…

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.

Despite the fact that using limbs is more cumbersome, the much greater number of arithmetic execution units available for vector instructions compensates that and ensures a greater performance.

Saying that RISC-V "removed carry flag for performance" is a fantasy. The saved hardware is completely negligible and significant performance is lost, not gained.

Moreover, the carry flag is required not only for multi-word operations, but also for detecting unsigned overflow. For this purpose, no limbs can save you.

Regarding the benchmarks linked by you, they show a really pathetic performance. 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. Cortex-A53 is an even worse comparison point, being a little core that is much older than a decade (from 2012).

Re: The Zilog Z80 has turned 50

#92
I learned BASIC in 1981 on the TRS-80 Model I with 4k RAM (later upgraded to a massive 16k), and it wasn't long before someone showed me EDTASM [1], and I was hooked. My parents couldn't believe me when I asked them to buy "How to Program the Z80" by Rodnay Zaks [2]. They were shocked, it was the first time I asked them to buy a technical book. I was so excited I couldn't sleep for days. I was in High School, and I would carry the book around and read, use the lookup tables, and write Z80 assembly in my spiral-bound 8.5"x11" notebook.

One three-day weekend, I slept about 4 hours while I was disassembling the BASIC ROM to find nuggets I could call in my Z80 programs, and also to learn so much more about the video, the cassette interface, interrupts, etc. My notebook looked like something a madman had scribbled on the walls of an asylum to everyone around me, but to me it was perfectly organized, and I used it to reference things I would use later in my programs. I got to the point where I could read the hex dumps and "see" the op codes in my mind; people would look over my shoulder while I was debugging, and I'd be explaining what the code was doing, but I hadn't disassembled it yet. I didn't even realize I was doing that until one of my classmates pointed it out: "Hey, disassemble that. I'm not following you, how the heck do you see that?"

And all of this because my science teacher had that TRS-80 Model I sitting in the corner of his classroom gathering dust; nobody knew what it was, I didn't either, but I had to figure it out. I've always had this bug, I don't believe in magic, I want to know how everything works, it's been an insatiable thing all my life, that first machine set me on a course of learning for the rest of my life.

Thanks, Mr. Kruzan, you changed my life. I'll never forget you. Oh, and thanks to all the people who created the Z80, the TRS-80 Model I, and paved the path for me to learn computers and never stop learning.

We are truly building on the shoulders of giants; every generation, more giants. It's humbling to look back and think about it forty-five years later...

[1] https://www.trs-80.org/edtasm.html

[2] http://www.z80.info/zip/zaks_book.pdf

PS: Pretty sure the memcpy examples have a stack bug.

Re: The Zilog Z80 has turned 50

#93
post #74

Earlier quoted context omitted.

RISC-V has no overflow flag? That's fascinating. I'll have to dig into that!

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 register.

When a cheaper solution than register renaming is desired, the correct solution was that of IBM POWER (1990), where there are 8 flag registers (with 4 flags in each, so the total size is 32 bits). That allows the parallel execution of up to 8 instructions per cycle, even without register renaming.

The superior IBM POWER ISA was implemented even in microcontrollers that were smaller and cheaper than the current RISC-V cores.

An alternative solution to having a flags register is to implement instructions with 3 input operands and 2 output operands. In this case, for the instructions that generate flags, they are stored in the second output registers.

In reality, all the 4 basic arithmetic operations with integers have 3 inputs and 2 outputs, when defined correctly. They are redefined to have 2 inputs and 1 output only to allow cheaper hardware, and in this case the additional input and additional output may be enabled only for some of the instructions, where they are stored in special registers, like the flag register, or in some ISAs in special extension registers used for multiplication/division/rotation/shifting.

Re: The Zilog Z80 has turned 50

#94

Earlier 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…

What really hindered flags and OOOE were instructions that only partially updated flag bits. For example if increment sets the overflow and zero flags but doesn't change the negative flag, it has a dependency on the old value of the flags register and a chain of increments must be serialised. Not fundamentally, but yes if you treat flags as a single register.

If you fix that by saying that every instruction sets the whole flags register, then it only makes sense to read the flags register in the very next instruction after setting it, and you may as well combine those into one single instruction and then you don't need the register at all.

Exception is ADC chains which both read and set the register. I think RISC-V doesn't support them?

Re: The Zilog Z80 has turned 50

#95
post #74

Earlier quoted context omitted.

RISC-V has no overflow flag? That's fascinating. I'll have to dig into that!

risc-v has no flags period modern out-of-order execution gets hindered by such non-parallel cpu state, so it wasn't included

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. The flags are actually one of the easier things to deal with, they basically get support for free when they implement register renaming.

It's actually the "classic RISC" style in-order pipelines where flags are annoying to deal with. They pipelines don't need to do any register renaming, so they don't have a free solution to handle flags. And the RISC-V ISA is very much optimised for these simpler pipelines.

Re: The Zilog Z80 has turned 50

#96

The article claims: > The Z80 is fully binary compatible with the 8080 instruction set. It wasn't in regards to the flag register. The parity flag behaved differently for some ops. And of course it would be possible to write an 8080 program that used undefined ops that would execute in some random way (often just duplicating an existing instruction) while the Z80 repurposed that opcode for something new.

Making the parity flag not perfectly compatible was a wise choice. In legacy programs the parity flag was seldom tested and practically never after the instructions where in Z80 it behaved differently. This allowed the repurposing of the parity flag as an overflow flag, which was an extremely useful extension of Z80. The instruction sets of Datapoint 2200, Intel 8008 and Intel 8080 share with that of RISC-V the disti…

It's obviously done like that in RISC-V to simplify it.

Re: The Zilog Z80 has turned 50

#97
post #95

Earlier 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

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…

Instructions that update some flags and not others have to be serialised in this design.

Re: The Zilog Z80 has turned 50

#98
post #94

Earlier quoted context omitted.

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…

What really hindered flags and OOOE were instructions that only partially updated flag bits. For example if increment sets the overflow and zero flags but doesn't change the negative flag, it has a dependency on the old value of the flags register and a chain of increments must be serialised. Not fundamentally, but yes if you treat flags as a single register. If you fix that by saying that every instruction sets the…

What you say about partially updated flag registers is right.

Because of this, most modern ISAs take care so that the flags register is always updated completely.

In legacy ISAs, like in x86-64 where the carry flag is updated or not updated separately from the other flags, it is handled by the CPU as a distinct register, so the carry flag is renamed independently of the other flags.

Moreover, in x86-64 the overflow flag can be used as second carry flag in some instructions. Having 2 carry flags permits the elimination of some functional dependencies between instructions that would not be eliminated by the renaming of a single carry flag (renaming solves only resource dependencies, not data dependencies).

Re: The Zilog Z80 has turned 50

#99
post #97
post #95

Earlier 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…

Instructions that update some flags and not others have to be serialised in this design.

True, and I wouldn't be surprised if modern x86 implementations need to do something a bit smarter.

But if you are designing a new ISA for the modern era (the purported selling point of RISC-V), you just don't implement any such instructions. Only implement clean instructions that update all the flags or none. ARM and PowerPC already did this 35-40 years ago.

Re: The Zilog Z80 has turned 50

#100
post #97
post #95

Earlier 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…

Instructions that update some flags and not others have to be serialised in this design.

In ISAs where this problem exists, i.e. in x86-64 where the carry flag is updated or not updated regardless of what happens with the other flags, the flags register is split into 2 separate registers, which are renamed independently.

The 2 parts of the flags register are reunited only for the purpose of saving or restoring from the main memory. (Actually the x86-64 flags register has 3 independent parts, the carry flag, the other status flags, and a set of configuration flags, which are not modified by most instructions.)

Post reply on HN