8 ms·

I find it interesting that, in one aspect, ARM went into the opposite direction with its newer 64-bit ISA. Like with RISC-V, the designers of the 64-bit ARM ISA

by cesarb 6y ago

I find it interesting that, in one aspect, ARM went into the opposite direction with its newer 64-bit ISA. Like with RISC-V, the designers of the 64-bit ARM ISA "knew about instruction compression and macro-ops fusion when they began designing their ISA" (32-bit ARM already had the alternative compressed ISAs Thumb/Thumb2/ThumbEE); however, they chose to use fixed-size 32-bit instructions without any compressed format. I suspect that they did it expecting that, once compatibility with the 32-bit ARM ISAs is removed on newer processors, the fixed-size instructions would allow for very wide decoders, like we've seen with Apple M1 (which can decode 8 instructions in parallel). It remains to be seen whether the RISC-V choice (the first two bits of every instruction are enough to determine the instruction length) will allow for a similarly wide decoder.

cogman10 6y ago
I'd imagine it would since they limit the number of possible instruction lengths. The hard thing about x86 is the fact that instructions can by anywhere from 8 bits->256 bits in length (in 8 bit increments). So there's really no way to know if you are loading up an x86 instruction or you are splitting an instruction. The fact that risc-v only supports 32,64, or 128bit instructions means that you don't have to go through a lot of extra effort to determine where instructions start or end.
- jecel 6y ago
  Note that RISC-V can have 32, 64 or 128 bit wide registers. The instruction length can be any multiple of 16 bits, though the base instructions are all 32 bits and the C extension adds 16 bit instructions and other lengths have not yet been used. This diagram shows how instructions up to 192 bits long can be encoded: https://www.embarcados.com.br/wp-content/uploads/2017/05/RISCV_length.jpg https://www.embarcados.com.br/wp-content/uploads/2017/05/RIS... It is a very simple circuit that can take the bottom 16 bits of any RISC-V instruction and tell you exactly how long it is, unlike the x86 where you need a sequence of steps.
  - deleted 6y ago
    [deleted]
- woodruffw 6y ago
  Nitpick: the longest valid x86 instruction is 15 bytes, or 120 bits (longer instructions might be structurally sound, but no hardware or software decoder will accept them). Variable length isn't actually a huge problem at the instruction fetch level (and modern compilers will align x86 instructions to keep ifetch moving smoothly), but it does make both hardware and software decoding significantly more complex.
- cesarb 6y ago
  It's more than just limiting the number of possible instruction lengths; it's also that you only need the first few bits of the instruction to determine its length. With x86, you have to decode the first byte to know if the instruction has more bytes, decode these bytes to know if the instruction has even more bytes, and so on. But since I'm not a hardware designer, I don't know if the RISC-V design is enough to make a high-performance wide decoder. With 64-bit ARM it seems very easy; once you loaded a n-byte line from the cache, the first decoder gets the first four bytes, the second decoder gets the next four bytes, and so on. With compressed RISC-V, the first decoder gets the first four bytes (0-3); the second decoder gets either bytes 4-7 or bytes 2-5; the third decoder can get bytes 8-11, 6-9, or 4-7, depending on how many of the preceding instructions were compressed; and so on. Determining which bytes each decoder gets seems very easy (it's a simple boolean formula of the first two bits of each pair of bytes), but I don't know enough about hardware design to know if the propagation delay from this slows things down enough to need an extra pipeline step once the decode gets too wide (for instance, the eighth decoder would have 8 possible choices for its input), or if there are tricks to avoid this delay (similar to a carry-skip adder).
  - jleahy 6y ago
    I am a hardware designer. See my comment above, it's going to be ugly. Fast adders are still slow (and awkward), but they only have to propagate a single bit of information, this is much messier. As a side-note carry-skip doesn't really work in modern VLSI, I guess you were probably thinking of carry-lookahead.
  - imtringued 6y ago
    Ok so you are saying not only are there implicit super instructions via macro op fusion there are also variable length instructions in there too? Ok, I'm not a RISC-V expert but damn that kind of ruins even the last tiny shred of its original value proposition of being simple. Sure the core instruction set is easy but once you add extensions it's just plain ugly.
- fctorial 6y ago
  Why would you need more that 32 bits for an instruction, (other than backward compatibility, which I'm assuming riscv is free from.)
  - rwmj 6y ago
    RISC-V is designed to be extensible. As well as demanding obviously more than 32 bit instruction coding to support many extensions, we expect there will be some (corner) cases where very long instructions might be desirable for particular extensions.
    - socialdemocrat 6y ago
      As far as I understand a RISC-V CPU will have fixed length instructions potentially having some of them compressed. I don't think you are going to see 32, 64 and 128 length instructions mixed in the same program. But I might be wrong about this. Do you have any source that suggests that instructions of different length should be mixed in one RISC-V program other than use of compressed instructions?
      - rwmj 6y ago
        You are completely wrong, as well as mixing up instruction encoding with size of the data registers. Please read section 1.5 of the user spec.
        socialdemocrat 6y ago
        No, need to be such a dick about it. I was frank about not being certain about this. I have read section 1.5, and I cannot see it supporting your claim. The very first sentence says: "The base RISC-V ISA has fixed-length 32-bit instructions that must be naturally aligned on 32-bit boundaries." Later it talks about: "For implementations supporting only a base instruction set, ILEN is 32 bits. Implementations supporting longer instructions have larger values of ILEN." It seems clear to me that a standard RISC-V implementation today is 32-bit fixed sized on a 32-bit boundary. There may however be support for future architectures with longer instructions. None of this suggests that a regular RISC-V implementation has to assume that instructions can be any length. These things are not even part of the standard yet. So please, don't be such a dick about something that isn't all that clear at the moment.
- zozbot234 6y ago
  Nitpicking, but the documented RISC-V encoding supports anything from 16-bit through 176-bit long instruction words in 16-bit increments, with instruction length being determined by the first 16 bits of the instruction word. Some encoding space has been reserved for 192-bits or longer. Recent versions of the RISC-V spec have actually de-emphasized this length encoding, so implementations may well be allowed to use the encoding space in different ways as long as they don't conflict with existing 32-bit (or 16-bit if the C extension is specified) instructions.
- rwmj 6y ago
  You seem very confused. RISC-V supports variable length instructions from 16 bits up to 192 bits (and maybe longer in future), and it's easy to tell in an instruction stream when the next instruction starts (although the stream is not self-synchronising).
CalChris 6y ago
As you mention, ARM had Thumb for ARMv7. It's important to remember that ARMv7 is still a product. The Innovator's Dilemma may blindly say to cannibalize, but instead, ARM probably thinks that these are two different sectors. The 64b sector doesn't need Thumb (which comes at an opcode space + decoder cost). The chips that ARMv8 are going into have massive DRAMs and while Thumb saves some, it wasn't enough. RISC-V on the other hand is all things to all people. So an embedded chip needs the possibility of Cray style vectors because reasons. I do think that if someone wants an 8-wide RISC-V decoder all they have to do is throw the transistors at it. That's a consequence of fixed width. Yeah, RVC will require more transistors, but not n^2 (?) like X86 does. RISC-V is pretty elegant, well except for the bit manipulation nonsense. They really should have plagiarized ARM instead of Intel there.
amelius 6y ago
> It remains to be seen whether the RISC-V choice (the first two bits of every instruction are enough to determine the instruction length) will allow for a similarly wide decoder. It's common practice that CPU designers actually evaluate every possible choice in an emulated environment, and make a quantitative analysis, before actually choosing to go down a particular path. At least, that's typically part of CPU design courses. This is the game that has allowed Apple to make a major leap in a short amount of iterations, and other CPU designers should become better at it. We can discuss all kinds of optimizations, but before we throw them in a model there's little we can say about their effectiveness, while the model is a very cheap way to learn more.
- jabl 6y ago
  I'm sure ISA designers use modeling, but maybe those models differ in their precognition abilities, considering how different choices eg risc-v and aarch64 have made.
garmaine 6y ago
RISC-V also has fixed size 32-bit instructions. Are you talking about the optional compressed extension?
- GoOnThenDoTell 6y ago
  The Linux distros are generally expecting that the hardware supports compressed
  - garmaine 6y ago
    Sure, but that’s a single configuration option away from being changed if the hardware is altered.
    - rwmj 6y ago
      Not really, it requires everything to be recompiled, which takes a few weeks assuming you have access to the cluster of RISC-V machines required to do it. We (Fedora) have rejected one platform already that wasn't going to support the compressed extension.
      - garmaine 6y ago
        Why would you need to do the builds natively instead of cross compiled?
        rwmj 6y ago
        The whole toolchain just makes this assumption, and we want to build it the same way Fedora is built for other arches. Plus we're expecting server-class RISC-V hardware soon enough, at least comparable to ARM servers.
jleahy 6y ago
Macro-op fusion is something that is really quite painful to implement in the front-end. Essentially once you have both macro-op fusion and potentially multiple micro-ops for a single instruction you have fully variable length instructions. Potentially it becomes worse than x86, where macro-op fusion has no need to be pervasive, you just have to cover very few simple cases (eg. cmp+jmp). For RISC-V even trivial things like 'load a 32 bit constant' need macro-op fusion to be competitive with x86. An 8 wide front-end for ARM64 needs to run a decoder every 4 bytes (so 8 in total), then combine the results. It's an entirely trivial affair. For RISC-V, without any macro-op fusion, you first need a unit every 2-bytes that determines the instruction length using the first 2 bits (16 of these), then you need a very wide mux to expand out any compressed instructions (the last one can come from 7 or 8 different offsets) so you have 8x 32b instructions, then you need your 8 decoders. It's looking much more unpleasant because of that very wide muxing (8x 8:1 32-bit muxes is not a pleasant sight). Alternatively you could do it the brute force way and have 16 decoders followed by a 16->8 reduction layer (ignoring the decode results that were at bad offsets). The designer is going to have a hard time choosing between those two bad options (personally I would go with the latter I think). Now let's throw in macro-op fusion, suddenly rather than have two possible lengths (16b or 32b) you can have 16b+16b, 32b+32b, 16b+32b, 32b+16b. Complexity just explodes. If anybody really tried to implement a 8 wide RISC-V front-end with pervasive macro-op fusion then it would be a truly nasty thing.
- jabl 6y ago
  What do you think of the RISC-V argument that a flags register is hard to make fast for a superscalar ooo core, and thus the RISC-V choice of two-register branching instructions is better than the traditional choice of a jmp instruction that reads the flags? This also avoids the need to macro fuse cmp+jmp, but OTOH eats quite severely into the destination offset.
  - jleahy 6y ago
    I think it’s smart, most branches are short and almost all important branches are short (eg. loops). The flags register adds an extra implicit input/output everywhere, and renaming is expensive enough without that. However given they are already paying the cost of a variable length instruction set (for compression) I think a wide set of reg/reg, reg/imm8, reg/imm16, reg/imm32 compare+jumps would have been even better. Right now compare+jump against an imm32 is 3 instructions (4 if it’s long) vs 2 for x86, that number could have been 1 (given variable length). Personally I think only two good choices exist for instruction sets, fully fixed size at 32b or variable with 2b control (max 2 inputs and 1 output reg!) followed by 0b, 2b, 4b, etc data (and thus very powerful instructions like the aforementioned). Anything else seems to be off the pareto curve. Goodbye cmov.

by cesarb 6y ago

cogman10 6y ago

I'd imagine it would since they limit the number of possible instruction lengths. The hard thing about x86 is the fact that instructions can by anywhere from 8 bits->256 bits in length (in 8 bit increments). So there's really no way to know if you are loading up an x86 instruction or you are splitting an instruction. The fact that risc-v only supports 32,64, or 128bit instructions means that you don't have to go through a lot of extra effort to determine where instructions start or end.

jecel 6y ago
Note that RISC-V can have 32, 64 or 128 bit wide registers. The instruction length can be any multiple of 16 bits, though the base instructions are all 32 bits and the C extension adds 16 bit instructions and other lengths have not yet been used. This diagram shows how instructions up to 192 bits long can be encoded: https://www.embarcados.com.br/wp-content/uploads/2017/05/RISCV_length.jpg https://www.embarcados.com.br/wp-content/uploads/2017/05/RIS... It is a very simple circuit that can take the bottom 16 bits of any RISC-V instruction and tell you exactly how long it is, unlike the x86 where you need a sequence of steps.
- deleted 6y ago
  [deleted]
woodruffw 6y ago
Nitpick: the longest valid x86 instruction is 15 bytes, or 120 bits (longer instructions might be structurally sound, but no hardware or software decoder will accept them). Variable length isn't actually a huge problem at the instruction fetch level (and modern compilers will align x86 instructions to keep ifetch moving smoothly), but it does make both hardware and software decoding significantly more complex.
cesarb 6y ago
It's more than just limiting the number of possible instruction lengths; it's also that you only need the first few bits of the instruction to determine its length. With x86, you have to decode the first byte to know if the instruction has more bytes, decode these bytes to know if the instruction has even more bytes, and so on. But since I'm not a hardware designer, I don't know if the RISC-V design is enough to make a high-performance wide decoder. With 64-bit ARM it seems very easy; once you loaded a n-byte line from the cache, the first decoder gets the first four bytes, the second decoder gets the next four bytes, and so on. With compressed RISC-V, the first decoder gets the first four bytes (0-3); the second decoder gets either bytes 4-7 or bytes 2-5; the third decoder can get bytes 8-11, 6-9, or 4-7, depending on how many of the preceding instructions were compressed; and so on. Determining which bytes each decoder gets seems very easy (it's a simple boolean formula of the first two bits of each pair of bytes), but I don't know enough about hardware design to know if the propagation delay from this slows things down enough to need an extra pipeline step once the decode gets too wide (for instance, the eighth decoder would have 8 possible choices for its input), or if there are tricks to avoid this delay (similar to a carry-skip adder).
- jleahy 6y ago
  I am a hardware designer. See my comment above, it's going to be ugly. Fast adders are still slow (and awkward), but they only have to propagate a single bit of information, this is much messier. As a side-note carry-skip doesn't really work in modern VLSI, I guess you were probably thinking of carry-lookahead.
- imtringued 6y ago
  Ok so you are saying not only are there implicit super instructions via macro op fusion there are also variable length instructions in there too? Ok, I'm not a RISC-V expert but damn that kind of ruins even the last tiny shred of its original value proposition of being simple. Sure the core instruction set is easy but once you add extensions it's just plain ugly.
fctorial 6y ago
Why would you need more that 32 bits for an instruction, (other than backward compatibility, which I'm assuming riscv is free from.)
- rwmj 6y ago
  RISC-V is designed to be extensible. As well as demanding obviously more than 32 bit instruction coding to support many extensions, we expect there will be some (corner) cases where very long instructions might be desirable for particular extensions.
  - socialdemocrat 6y ago
    As far as I understand a RISC-V CPU will have fixed length instructions potentially having some of them compressed. I don't think you are going to see 32, 64 and 128 length instructions mixed in the same program. But I might be wrong about this. Do you have any source that suggests that instructions of different length should be mixed in one RISC-V program other than use of compressed instructions?
    - rwmj 6y ago
      You are completely wrong, as well as mixing up instruction encoding with size of the data registers. Please read section 1.5 of the user spec.
      - socialdemocrat 6y ago
        No, need to be such a dick about it. I was frank about not being certain about this. I have read section 1.5, and I cannot see it supporting your claim. The very first sentence says: "The base RISC-V ISA has fixed-length 32-bit instructions that must be naturally aligned on 32-bit boundaries." Later it talks about: "For implementations supporting only a base instruction set, ILEN is 32 bits. Implementations supporting longer instructions have larger values of ILEN." It seems clear to me that a standard RISC-V implementation today is 32-bit fixed sized on a 32-bit boundary. There may however be support for future architectures with longer instructions. None of this suggests that a regular RISC-V implementation has to assume that instructions can be any length. These things are not even part of the standard yet. So please, don't be such a dick about something that isn't all that clear at the moment.
zozbot234 6y ago
Nitpicking, but the documented RISC-V encoding supports anything from 16-bit through 176-bit long instruction words in 16-bit increments, with instruction length being determined by the first 16 bits of the instruction word. Some encoding space has been reserved for 192-bits or longer. Recent versions of the RISC-V spec have actually de-emphasized this length encoding, so implementations may well be allowed to use the encoding space in different ways as long as they don't conflict with existing 32-bit (or 16-bit if the C extension is specified) instructions.
rwmj 6y ago
You seem very confused. RISC-V supports variable length instructions from 16 bits up to 192 bits (and maybe longer in future), and it's easy to tell in an instruction stream when the next instruction starts (although the stream is not self-synchronising).

CalChris 6y ago

As you mention, ARM had Thumb for ARMv7. It's important to remember that ARMv7 is still a product. The Innovator's Dilemma may blindly say to cannibalize, but instead, ARM probably thinks that these are two different sectors. The 64b sector doesn't need Thumb (which comes at an opcode space + decoder cost). The chips that ARMv8 are going into have massive DRAMs and while Thumb saves some, it wasn't enough. RISC-V on the other hand is all things to all people. So an embedded chip needs the possibility of Cray style vectors because reasons. I do think that if someone wants an 8-wide RISC-V decoder all they have to do is throw the transistors at it. That's a consequence of fixed width. Yeah, RVC will require more transistors, but not n^2 (?) like X86 does. RISC-V is pretty elegant, well except for the bit manipulation nonsense. They really should have plagiarized ARM instead of Intel there.

amelius 6y ago

> It remains to be seen whether the RISC-V choice (the first two bits of every instruction are enough to determine the instruction length) will allow for a similarly wide decoder. It's common practice that CPU designers actually evaluate every possible choice in an emulated environment, and make a quantitative analysis, before actually choosing to go down a particular path. At least, that's typically part of CPU design courses. This is the game that has allowed Apple to make a major leap in a short amount of iterations, and other CPU designers should become better at it. We can discuss all kinds of optimizations, but before we throw them in a model there's little we can say about their effectiveness, while the model is a very cheap way to learn more.

jabl 6y ago
I'm sure ISA designers use modeling, but maybe those models differ in their precognition abilities, considering how different choices eg risc-v and aarch64 have made.

garmaine 6y ago

RISC-V also has fixed size 32-bit instructions. Are you talking about the optional compressed extension?

GoOnThenDoTell 6y ago
The Linux distros are generally expecting that the hardware supports compressed
- garmaine 6y ago
  Sure, but that’s a single configuration option away from being changed if the hardware is altered.
  - rwmj 6y ago
    Not really, it requires everything to be recompiled, which takes a few weeks assuming you have access to the cluster of RISC-V machines required to do it. We (Fedora) have rejected one platform already that wasn't going to support the compressed extension.
    - garmaine 6y ago
      Why would you need to do the builds natively instead of cross compiled?
      - rwmj 6y ago
        The whole toolchain just makes this assumption, and we want to build it the same way Fedora is built for other arches. Plus we're expecting server-class RISC-V hardware soon enough, at least comparable to ARM servers.

jleahy 6y ago

Macro-op fusion is something that is really quite painful to implement in the front-end. Essentially once you have both macro-op fusion and potentially multiple micro-ops for a single instruction you have fully variable length instructions. Potentially it becomes worse than x86, where macro-op fusion has no need to be pervasive, you just have to cover very few simple cases (eg. cmp+jmp). For RISC-V even trivial things like 'load a 32 bit constant' need macro-op fusion to be competitive with x86. An 8 wide front-end for ARM64 needs to run a decoder every 4 bytes (so 8 in total), then combine the results. It's an entirely trivial affair. For RISC-V, without any macro-op fusion, you first need a unit every 2-bytes that determines the instruction length using the first 2 bits (16 of these), then you need a very wide mux to expand out any compressed instructions (the last one can come from 7 or 8 different offsets) so you have 8x 32b instructions, then you need your 8 decoders. It's looking much more unpleasant because of that very wide muxing (8x 8:1 32-bit muxes is not a pleasant sight). Alternatively you could do it the brute force way and have 16 decoders followed by a 16->8 reduction layer (ignoring the decode results that were at bad offsets). The designer is going to have a hard time choosing between those two bad options (personally I would go with the latter I think). Now let's throw in macro-op fusion, suddenly rather than have two possible lengths (16b or 32b) you can have 16b+16b, 32b+32b, 16b+32b, 32b+16b. Complexity just explodes. If anybody really tried to implement a 8 wide RISC-V front-end with pervasive macro-op fusion then it would be a truly nasty thing.

jabl 6y ago
What do you think of the RISC-V argument that a flags register is hard to make fast for a superscalar ooo core, and thus the RISC-V choice of two-register branching instructions is better than the traditional choice of a jmp instruction that reads the flags? This also avoids the need to macro fuse cmp+jmp, but OTOH eats quite severely into the destination offset.
- jleahy 6y ago
  I think it’s smart, most branches are short and almost all important branches are short (eg. loops). The flags register adds an extra implicit input/output everywhere, and renaming is expensive enough without that. However given they are already paying the cost of a variable length instruction set (for compression) I think a wide set of reg/reg, reg/imm8, reg/imm16, reg/imm32 compare+jumps would have been even better. Right now compare+jump against an imm32 is 3 instructions (4 if it’s long) vs 2 for x86, that number could have been 1 (given variable length). Personally I think only two good choices exist for instruction sets, fully fixed size at 32b or variable with 2b control (max 2 inputs and 1 output reg!) followed by 0b, 2b, 4b, etc data (and thus very powerful instructions like the aforementioned). Anything else seems to be off the pareto curve. Goodbye cmov.