4 ms·

I still feel that the criticisms in this article still stand: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/er

I still feel that the criticisms in this article still stand: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... The chief and most difficult to address among which is the lack of advanced addressing modes ('lea' in x86) means that address generation for array access requires 3 more instructions. The writer suggests that Macro-OP fusion will pick up the slack in this case, however it has been pointed out that this level of fusion (tons of instructions, which can have various read and write locations) is very complex to do in HW and is typically not done even in high-end commercial CPUs today.

klelatti 6y ago
> Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care. This seems to me to be under-debated. If / when RISC-V gets more adoption what is there to stop vendors trying to 'win' by adding proprietary extensions that fragment the ecosystem.
- remexre 6y ago
  Convincing the Chrome (or Firefox, Mathematica, MATLAB, $distro's emacs builds, ...) team to switch to their proprietary gcc/LLVM fork that supports the extensions, I assume. Proprietary extensions work better in the embedded space, where the status quo is a proprietary toolchain; I doubt you'd be able to get a ton of buy-in from application distributors before you have market dominance.
  - klelatti 6y ago
    Fair challenge. I fear though that once a firm gets to say Qualcomm or Apple size in the market then they have the scale to continue to maintain their own fork and develop their own apps with that (e.g. Apple could easily do with Safari etc.)
- nickik 6y ago
  Its not 'under-debated' it been literally debated in every single forum that ever had a post about RISC-V. Its literally the most debated thing. The reason its not very likely to happen is because we have a gigantic open source ecosystem that is unlikely to for free adopt your extension unless you pay them to do it. At the end of the day, you simply can't force hardware designer into some standard unless your ISA is proprietary.
  - klelatti 6y ago
    "Unlikely" and "for free". So it could happen and yes firms do pay for changes to open source software. You really haven't answered the point about what's stopping a big vendor adding its own extensions and fragmenting the ecosystem.
    - nickik 6y ago
      Nothing is stopping it, just as nothing is stopping people from copying any open source software. My point is exactly, its not designed to 'stop it'. In fact, the opposite. If somebody wants to replicate large parts of the open source ecosystem to support their extension then that's ok. The point is, that most of the time this simply doesn't happen and if it does, it doesn't actually hurt those that want to hold to the standard. In some segments of the market, doing such is perfectly fine and encouraged. In others its much more unlikely, difficult and expensive. RISC-V is designed to work from the smallest embedded chip to the largest server. Trying to create some sort of universality would never work, and trying to use legal means of preventing such is simply a bad idea and an anti-pattern. The ecosystem is designed so that all software is able to handle the different configuration and understand when a software is not supported and why. Its designed to have the base system be maximally portable and to cover most things in standard extensions so that new implementations can access a huge amount of tooling and software without issue.
pjc50 6y ago
Remind me, how is this done in ARM?
- torginus 6y ago
  Since ARM has plenty of space in a 32 bit instruction, both the shift and the add are baked into the ldr instruction.
  - duskwuff 6y ago
    Even in Cortex-M, most array accesses are two instructions (lsls+ldr), as the ldr includes a "free" register+register add. For example, given an index in r0 and an array base address in r3: lsls r0, r0, #2 ldr r0, [r0, r3]
zozbot234 6y ago
A simple 'lea' equivalent does not need multiple "read and write locations". ISTM that this ought to be an ideal case for macro-op fusion.
- torginus 6y ago
  Yup, you are correct. However, the CPU still needs to figure that out by examining the read and write locations of all 3 instructions, which need to be decoded, then fused before execution. I'm a dilettante in this area, but it doesn't sound trivial to me.
socialdemocrat 6y ago
I believe RISC-V follows a pretty simple rule, where one looks at destination register only. Intel CPUs have been doing macro fusion for years. And they had to tack that on in hindsight. I don't see why RISC-V cannot make this much simpler than Intel since they are deliberately designing their instructions to work well with macro-op fusion, something Intel never did. If Intel is able to do it I have trouble seeing why RISC-V cannot do it when they are even planning for it. I don't buy this complexity argument at all. It doesn't add up.
- imtringued 6y ago
  x86 only needs to macro op fuse 2 instructions at most, meaning you can look at the first instruction and immediately see which fusion to apply. With RISC-V there are proposals to macro op fuse things like array out of bounds checks which comprise 5 instructions. You can't just check the first instruction and then the second. It's entirely possible that instruction 1 has 6 different micro op fusion patterns and you have to read instruction 2 to cut down on the number of potential patterns. It's also possible that the second instruction is not relevant in determining the pattern meaning you have to scan 3 instructions to determine the pattern. You have to start this pattern search on the beginning of every instruction you decode which limits your ability to add more decoders. Of course with enough spare transistors this is merely an extremely difficult problem, not an impossible one.
  - socialdemocrat 6y ago
    Yeah but each CPU can choose exactly how much fusion they want to do. That is not part of the ISA or promise they make to developers. Doing macro-op fusion like x86 should be a big win anyway combined with compressed instructions.
imtringued 6y ago
What I have gathered boils down to: the RISC-V core instruction set is simple but there are too many extensions. The way they intend to speed up RISC-V processors is simply by throwing more hardware at it, hoping that at some point x86 and ARM will hit a complexity roadblock so that throwing even more hardware is simply not possible for them. For example, the idea of keeping the instruction set simple means you can start off with a non super scalar architecture and get energy efficiency for micro controllers. Once you keep up with the giants you can throw extreme macro op fusion into the pile. Macro op fusing up to 6 instructions is extremely difficult on RISC-V but it's impossible on ARM and x86. So eventually RISC-V will win simply because you can throw more transistors at the problem. Scaling up instruction decoding is viable on ARM and RISC-V but the smaller instruction set means you can have more decoders on RISC-V. However, doubling or tripling the number of decoded instructions per clock cycle is only relevant because RISC-V programs need more instructions in the first place to encode the same program.

klelatti 6y ago

> Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care. This seems to me to be under-debated. If / when RISC-V gets more adoption what is there to stop vendors trying to 'win' by adding proprietary extensions that fragment the ecosystem.

remexre 6y ago
Convincing the Chrome (or Firefox, Mathematica, MATLAB, $distro's emacs builds, ...) team to switch to their proprietary gcc/LLVM fork that supports the extensions, I assume. Proprietary extensions work better in the embedded space, where the status quo is a proprietary toolchain; I doubt you'd be able to get a ton of buy-in from application distributors before you have market dominance.
- klelatti 6y ago
  Fair challenge. I fear though that once a firm gets to say Qualcomm or Apple size in the market then they have the scale to continue to maintain their own fork and develop their own apps with that (e.g. Apple could easily do with Safari etc.)
nickik 6y ago
Its not 'under-debated' it been literally debated in every single forum that ever had a post about RISC-V. Its literally the most debated thing. The reason its not very likely to happen is because we have a gigantic open source ecosystem that is unlikely to for free adopt your extension unless you pay them to do it. At the end of the day, you simply can't force hardware designer into some standard unless your ISA is proprietary.
- klelatti 6y ago
  "Unlikely" and "for free". So it could happen and yes firms do pay for changes to open source software. You really haven't answered the point about what's stopping a big vendor adding its own extensions and fragmenting the ecosystem.
  - nickik 6y ago
    Nothing is stopping it, just as nothing is stopping people from copying any open source software. My point is exactly, its not designed to 'stop it'. In fact, the opposite. If somebody wants to replicate large parts of the open source ecosystem to support their extension then that's ok. The point is, that most of the time this simply doesn't happen and if it does, it doesn't actually hurt those that want to hold to the standard. In some segments of the market, doing such is perfectly fine and encouraged. In others its much more unlikely, difficult and expensive. RISC-V is designed to work from the smallest embedded chip to the largest server. Trying to create some sort of universality would never work, and trying to use legal means of preventing such is simply a bad idea and an anti-pattern. The ecosystem is designed so that all software is able to handle the different configuration and understand when a software is not supported and why. Its designed to have the base system be maximally portable and to cover most things in standard extensions so that new implementations can access a huge amount of tooling and software without issue.

pjc50 6y ago

Remind me, how is this done in ARM?

torginus 6y ago
Since ARM has plenty of space in a 32 bit instruction, both the shift and the add are baked into the ldr instruction.
- duskwuff 6y ago
  Even in Cortex-M, most array accesses are two instructions (lsls+ldr), as the ldr includes a "free" register+register add. For example, given an index in r0 and an array base address in r3: lsls r0, r0, #2 ldr r0, [r0, r3]

zozbot234 6y ago

A simple 'lea' equivalent does not need multiple "read and write locations". ISTM that this ought to be an ideal case for macro-op fusion.

torginus 6y ago
Yup, you are correct. However, the CPU still needs to figure that out by examining the read and write locations of all 3 instructions, which need to be decoded, then fused before execution. I'm a dilettante in this area, but it doesn't sound trivial to me.

socialdemocrat 6y ago

I believe RISC-V follows a pretty simple rule, where one looks at destination register only. Intel CPUs have been doing macro fusion for years. And they had to tack that on in hindsight. I don't see why RISC-V cannot make this much simpler than Intel since they are deliberately designing their instructions to work well with macro-op fusion, something Intel never did. If Intel is able to do it I have trouble seeing why RISC-V cannot do it when they are even planning for it. I don't buy this complexity argument at all. It doesn't add up.

imtringued 6y ago
x86 only needs to macro op fuse 2 instructions at most, meaning you can look at the first instruction and immediately see which fusion to apply. With RISC-V there are proposals to macro op fuse things like array out of bounds checks which comprise 5 instructions. You can't just check the first instruction and then the second. It's entirely possible that instruction 1 has 6 different micro op fusion patterns and you have to read instruction 2 to cut down on the number of potential patterns. It's also possible that the second instruction is not relevant in determining the pattern meaning you have to scan 3 instructions to determine the pattern. You have to start this pattern search on the beginning of every instruction you decode which limits your ability to add more decoders. Of course with enough spare transistors this is merely an extremely difficult problem, not an impossible one.
- socialdemocrat 6y ago
  Yeah but each CPU can choose exactly how much fusion they want to do. That is not part of the ISA or promise they make to developers. Doing macro-op fusion like x86 should be a big win anyway combined with compressed instructions.

imtringued 6y ago

What I have gathered boils down to: the RISC-V core instruction set is simple but there are too many extensions. The way they intend to speed up RISC-V processors is simply by throwing more hardware at it, hoping that at some point x86 and ARM will hit a complexity roadblock so that throwing even more hardware is simply not possible for them. For example, the idea of keeping the instruction set simple means you can start off with a non super scalar architecture and get energy efficiency for micro controllers. Once you keep up with the giants you can throw extreme macro op fusion into the pile. Macro op fusing up to 6 instructions is extremely difficult on RISC-V but it's impossible on ARM and x86. So eventually RISC-V will win simply because you can throw more transistors at the problem. Scaling up instruction decoding is viable on ARM and RISC-V but the smaller instruction set means you can have more decoders on RISC-V. However, doubling or tripling the number of decoded instructions per clock cycle is only relevant because RISC-V programs need more instructions in the first place to encode the same program.