7 ms·

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 diff

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.

kazinator 3mo ago
But "undefined ops" are not part of the "8080 instruction set"; supporting those would be "binary compatible with the 8080 silicon". The parity flag is a breaker though; "binary compatible for code only relying on the 8080 instruction set, other than values of the parity flag".
- Zardoz84 3mo ago
  By the same thinking that have the parent post The 80286 and 80386 aren't binary compatible with the 8086. Because they replaced undefined opcodes with new stuff.
adrian_b 3mo ago
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 distinction of belonging to the extremely few ISAs where overflow is not detected by hardware. Datapoint 2200 and its first successors had the excuse that they were extremely simple and cheap designs, which were never intended for general-purpose computing. RISC-V has absolutely no excuse. The lack of overflow detection is its greatest mistake.
- djmips 3mo ago
  RISC-V has no overflow flag? That's fascinating. I'll have to dig into that!
  - bonzini 3mo ago
    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/006013.html https://gmplib.org/list-archives/gmp-devel/2021-September/00...
    - adrian_b 3mo ago
      Unfortunately the criticism from that link is absolutely correct. Moreover, at that link it is shown only the ugly way in which RISC-V does multi-word addition. Checking the standard arithmetic operations for overflow is much more horrible and inefficient than that, and checking for overflows must be done in any program that claims to follow safe practices. Unlike in software, computing the carry and overflow flags in hardware is absolutely trivial and the extra gates needed for this add a cost that is below a rounding error in the total chip cost. With Z80, it was much easier to compute arithmetic expressions than it is with RISC-V, especially when working with big numbers and especially when mandating correct computations, with no undetected errors.
    - NooneAtAll3 3mo ago
      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.html 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://old.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignum_library_test_riscv_vs_arm/ https://old.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignu... so panic was for nothing
- inigyou 3mo ago
  It's obviously done like that in RISC-V to simplify it.
  - adrian_b 3mo ago
    Zilog Z80 was orders of magnitude simpler, but its designers never did something so foolish. At that time, many people still used assembly language and they would have never accepted to write arithmetic expressions in the contorted way forced by RISC-V. Now compilers hide this aspect of RISC-V so most are not aware of this. Moreover, most people are still using programs compiled from C/C++ with unsafe compilation options, or even from Rust, where by default integer overflow is not checked in programs compiled for "release", so they do not see how much performance RISC-V loses when executing programs that are designed to produce correct results.

kazinator 3mo ago

But "undefined ops" are not part of the "8080 instruction set"; supporting those would be "binary compatible with the 8080 silicon". The parity flag is a breaker though; "binary compatible for code only relying on the 8080 instruction set, other than values of the parity flag".

Zardoz84 3mo ago
By the same thinking that have the parent post The 80286 and 80386 aren't binary compatible with the 8086. Because they replaced undefined opcodes with new stuff.

adrian_b 3mo ago

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 distinction of belonging to the extremely few ISAs where overflow is not detected by hardware. Datapoint 2200 and its first successors had the excuse that they were extremely simple and cheap designs, which were never intended for general-purpose computing. RISC-V has absolutely no excuse. The lack of overflow detection is its greatest mistake.

djmips 3mo ago
RISC-V has no overflow flag? That's fascinating. I'll have to dig into that!
- bonzini 3mo ago
  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/006013.html https://gmplib.org/list-archives/gmp-devel/2021-September/00...
  - adrian_b 3mo ago
    Unfortunately the criticism from that link is absolutely correct. Moreover, at that link it is shown only the ugly way in which RISC-V does multi-word addition. Checking the standard arithmetic operations for overflow is much more horrible and inefficient than that, and checking for overflows must be done in any program that claims to follow safe practices. Unlike in software, computing the carry and overflow flags in hardware is absolutely trivial and the extra gates needed for this add a cost that is below a rounding error in the total chip cost. With Z80, it was much easier to compute arithmetic expressions than it is with RISC-V, especially when working with big numbers and especially when mandating correct computations, with no undetected errors.
  - NooneAtAll3 3mo ago
    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.html 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://old.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignum_library_test_riscv_vs_arm/ https://old.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignu... so panic was for nothing
inigyou 3mo ago
It's obviously done like that in RISC-V to simplify it.
- adrian_b 3mo ago
  Zilog Z80 was orders of magnitude simpler, but its designers never did something so foolish. At that time, many people still used assembly language and they would have never accepted to write arithmetic expressions in the contorted way forced by RISC-V. Now compilers hide this aspect of RISC-V so most are not aware of this. Moreover, most people are still using programs compiled from C/C++ with unsafe compilation options, or even from Rust, where by default integer overflow is not checked in programs compiled for "release", so they do not see how much performance RISC-V loses when executing programs that are designed to produce correct results.