2 ms·

> attempting to turn RISC-V into Arm64 but without the restrictions This flew past me, do you have a link?

fidotron 2y ago
Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. This is enough of a philosophy change to break existing RISC-V software, and so is purely motivated by a desire to clone IP they supposedly licensed as honest brokers.
- rangestransform 2y ago
  Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?
  - wbl 2y ago
    So much is relative: on a giant OoO core it's barely noticeable. In the case of x86 the range of lengths is extreme: a simple two or four choice is much simpler.
  - jecel 2y ago
    The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that). This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors. The corresponding circuit for x86 would be huge. But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits: Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350) SERV: 532 NANDs (serial RISC-V) Revive: 506 NANDs (part of FPGAboy) You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs. The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.
  - dzaima 2y ago
    x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help. So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).
- starspangled 2y ago
  I don't really see how this follows. Fixed length instructions are a well known and highly desirable property for instruction decoders (at the cost of some density), which has been known about and done since the first RISCs. And ARMv8 is basically just a warmed-over RISC with very little new or innovative in there. It's just an ISA. ARM Ltd is basically rent-seeking on keeping the ISA proprietary, same as Intel and AMD do. Sure it's a highly specialized and very impressive task to make an ISA, but not to the value of extracting hundreds of millions of dollars ever year. If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy.
  - ksec 2y ago
    >If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy. ARM never said that. >but not to the value of extracting hundreds of millions of dollars ever year. ARM makes money on selling ARM design, not from their ISA licensing.
    - starspangled 2y ago
      > ARM never said that. Someone did. > ARM makes money on selling ARM design, not from their ISA licensing. That's not correct, they make money from ISA licensing. That's called their architectural license, and that is what is being canceled here.

Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. This is enough of a philosophy change to break existing RISC-V software, and so is purely motivated by a desire to clone IP they supposedly licensed as honest brokers.

rangestransform 2y ago
Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?
- wbl 2y ago
  So much is relative: on a giant OoO core it's barely noticeable. In the case of x86 the range of lengths is extreme: a simple two or four choice is much simpler.
- jecel 2y ago
  The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that). This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors. The corresponding circuit for x86 would be huge. But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits: Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350) SERV: 532 NANDs (serial RISC-V) Revive: 506 NANDs (part of FPGAboy) You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs. The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.
- dzaima 2y ago
  x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help. So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).
starspangled 2y ago
I don't really see how this follows. Fixed length instructions are a well known and highly desirable property for instruction decoders (at the cost of some density), which has been known about and done since the first RISCs. And ARMv8 is basically just a warmed-over RISC with very little new or innovative in there. It's just an ISA. ARM Ltd is basically rent-seeking on keeping the ISA proprietary, same as Intel and AMD do. Sure it's a highly specialized and very impressive task to make an ISA, but not to the value of extracting hundreds of millions of dollars ever year. If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy.
- ksec 2y ago
  >If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy. ARM never said that. >but not to the value of extracting hundreds of millions of dollars ever year. ARM makes money on selling ARM design, not from their ISA licensing.
  - starspangled 2y ago
    > ARM never said that. Someone did. > ARM makes money on selling ARM design, not from their ISA licensing. That's not correct, they make money from ISA licensing. That's called their architectural license, and that is what is being canceled here.