9 ms·

So this is one tiny corner of the ISA, not something that makes ALL instruction sequences longer - essentially RISCV has no condition codes (they're a bit of an

So this is one tiny corner of the ISA, not something that makes ALL instruction sequences longer - essentially RISCV has no condition codes (they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other). It's a trade off - and the one that's been made is one that makes it possible to make ALL instructions a little faster at the expense of one particular case that isn't used much - that's how you do computer architecture, you look at the whole, not just one particular case RISCV also specifies a 128-bit variant that is of course FASTER than these examples

wbl 5y ago
You can opt in to generating and propagating conditions and rename the predicates as well.
theresistor 5y ago
This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing modes, compare-and-branch, etc. Where this really bites you is in workloads dominated by tight loops (image processing, cryptography, HPC, etc). While a microarchitecture may be more efficient thanks to simpler instructions (ignoring the added complexity of compressed instructions and macro-fusion, the usual suggested fixes...), it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop.
- rstuart4133 5y ago
  > it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop. As someone else who replied said, I'm not a CPU architect, just software that works close to the metal. That means I pay attention to compiler output. What you say is true in the very early says: compilers did indeed use the x86's addressing modes in all sorts of odd ways to squeeze as many calculations as possible into as few bytes as possible. Then it went in the reverse direction. You started seeing compilers emitting long series of simple instructions instead, seemingly deliberately avoiding those complex addressing modes. And now it's swung back again - I'm the complier using addressing modes to shift plus a couple of adds in one instruction is common again. I presume all these shifts were driven by speed of the resulting code. I have no idea why one method was faster than the other - but clearly there is no hard and fast rule operating here. For some internal x86's implementations using complex addressing modes was a win. On some, for exactly the same instruction set, it wasn't. There is no cut and dried "best" way of doing it, rather it varies as the transistor and power budget changes. One thing we do know about RISC-V is it is intended to cover a _lot_ transistor and power budgets. Where it's used now (low power / low transistor) is turned out their design decisions have turned out _very_ well, far better than x86. More fascinatingly to me, today the biggest speed ups compilers get for super scalar arch's has nothing to do with the addressing modes so much attention is being focused on here. It comes from avoiding conditional jumps. The compilers will often emit code that evaluates both paths of the computation (thus burning 50% more ALU time on a calculating a result that will never be used), then choose the result they want with a cmov. In extreme cases, I've seen doing that sort of thing gain them a factor of 10, which is far more than playing tiddly winks with addressing modes will get you. I have no idea how that will pan out for RISC-V. I don't think any one has done a super scalar implementation of it yet(?) But in the non-super scalar implementations the RISC-V instruction set choices have worked out very well so far. And when someone does do a super scalar implementation (and I'm sure there will be a lot of different implementations over time), it seems very possible x86's learnings on addressing mode use will be yesterdays news.
- nickez 5y ago
  For those use cases you typically have specialised hardware or an FPGA.
  - deleted 5y ago
    [deleted]
  - vadfa 5y ago
    So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?
    - lvh 5y ago
      An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).
      - plorkyeran 5y ago
        Hardware video decoding is done by a single-purpose chip on the graphics card (or dedicated hardware inside the GPU), not via software running on the GPU. Adding support for a new video codec requires buying a new video card which supports that codec.
        The_rationalist 5y ago
        While this is true (GPUs have embedded video ASICs), are there software GPU decoders for video codecs that outperform CPU decoders (and do not use the hardcoded GPU ASICs)? This would allow newer codecs to become mainstream more quickly vs the inertia of needing to buy a new GPU.
      - imtringued 5y ago
        SystemC bloat will require you to upgrade to a bigger FPGA!
- lottospm 5y ago
  I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer macro-instructions are not automatically a win. I guess we'll eventually see in benchmarks. Even though Intel has had decades to refine their CPUs I'm quite excited to see where RISC-V is going.
  - theresistor 5y ago
    As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it for performance, when most ISAs prefer to fix the problem upstream.
    - jasonhansel 5y ago
      Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips. Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...
      - seoaeu 5y ago
        RISC-V does document "official" macro-ops that implementations are encouraged to support.
    - evilos 5y ago
      > "X86 has an internal RISC" is an over-simplification that obscures reality Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.
sanxiyn 5y ago
RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).
- zozbot234 5y ago
  They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware.
  - throwaway81523 5y ago
    > They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware. I would like to see some benchmarks of this efficient implementation in hardware, even simulated hardware, compared against conventional architectures. Even for C, it's a recurring source of bugs and vulnerabilities that int overflow goes undetected. What we really need is an overflow trap like the one in IEEE floating point. RISC-V went the opposite direction.
  - adrian_b 5y ago
    Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software. A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient".
    - mlyle 5y ago
      > A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient". 1. There's not multiple additions in the recommended sequences. Unsigned is add,bltu; Signed with one known sign is add, blt; Signed in general is add, slt, slti, bne. 2. These instruction sequences are specified so that an instruction decoder can treat these sequences following the add as a "very wide" instruction specifying to check an overflow flag, if a hardware implementation so chooses.
classichasclass 5y ago
So do what Power does: most instructions that update the condition flags can do so optionally (except for instructions like stdcx. or cmpd where they're meaningless without it, and corner oddballs like andi.). For that matter, Power treats things like overflow and carry as separate from the condition register (they go in a special purpose register), so you can issue an instruction like addco. or just a regular add with no flags, and the condition register actually is divided into eight, so you can operate on separate fields without dependencies.
- jabl 5y ago
  ARM also does something similar, many instructions has a flag bit specifying whether flags should be updated or not. It doesn't have the multiple flag registers of POWER though.
  - crest 5y ago
    Which at least back in the day neither the IBM compilers nor GCC 2.x - 4.x made much use of. I've seen only a few handoptimzed assembler routines get decent use out of them. Easy to fuse pairs a probably a good compromise for carry calculation e.g. add + a carry instruction. That would get rid of one of the additional dependencies, but it would take a three operand addition or fusing two additions to get rid of the second RISC V specific dependency. And while GMP isn't unimportant it is still a niche use case that's probably not worth throwing that much hardware resources at to fix the ISA limitations in the uarch.
    - bshanks 5y ago
      Which feature are you saying was not used much? Addition with carry; or addition without carry; or multiple flag registers?
- crest 5y ago
  IIRC few Power(PC) cores really split the condition register nibbles into 8 renamable registers and while Power(PC) includes everything (including at least two spare kitchen sinks) only a few instructions can pick which condition register nibble to update. Most integer instructions can only update cr0 and floating point instructions cr1. On the other hand you can do nice hacks with the cornucopia of bitwise available bitwise operations on condition register bits and it's one of the architectures where (floating point) comparisons return the full set of results (less, equal, greater, unordered).
bitwize 5y ago
It's not a tiny corner. People do arithmetic with carry all the time. Arbitrary precision arithmetic is more common than you think. Congratulations, RISC-V, you've not only slowed down every bignum implementation in existence, all those extra instructions to compute carry will blow the I$ faster, potentially slowing down any code that relies on a bignum implementation as well.
- andrekandre 5y ago
  > all those extra instructions to compute carry will blow the I$ faster i think the idea is, as others have mentioned, the add/comp instructions are fused internally to a single instruction, so probably its not that bad for i$ as we might think?
monocasa 5y ago
> they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other It's doesn't have to be _that_ bad. As long as condition flags are all written at once (or are essentially banked like PowerPC) the dependency issue can go away because they're renamed and their results aren't dependent on previous data. Now, of course, instructions that only update some condition flags and preserve others are the devil.
user-the-name 5y ago
> RISCV also specifies a 128-bit variant that is of course FASTER than these examples Is it actually implemented on any hardware?
- ncmncm 5y ago
  No. Mentioning it is only meant to distract.
  - TheCondor 5y ago
    Is there a semi competitive Risc-V core implemented anywhere? It all seem hypothetical to me now, fast cores would fuse the instructions together so instruction count alone isn't adequate for the original evaluation of the ISA. Now I'm not sure that there are any that really do that..
    - mhh__ 5y ago
      SiFive have a new thing which is roughly as fast as a low-power CPU from Intel or Apple (e.g. IceStorm). Obviously not really competitive, but I think they are still mostly making hardware so there is hardware at-all stage.
    - monocasa 5y ago
      BOOM cores fuse ops already, so the cores don't have to be all that fast to start to see wins from it.

wbl 5y ago

You can opt in to generating and propagating conditions and rename the predicates as well.

theresistor 5y ago

This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing modes, compare-and-branch, etc. Where this really bites you is in workloads dominated by tight loops (image processing, cryptography, HPC, etc). While a microarchitecture may be more efficient thanks to simpler instructions (ignoring the added complexity of compressed instructions and macro-fusion, the usual suggested fixes...), it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop.

rstuart4133 5y ago
> it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop. As someone else who replied said, I'm not a CPU architect, just software that works close to the metal. That means I pay attention to compiler output. What you say is true in the very early says: compilers did indeed use the x86's addressing modes in all sorts of odd ways to squeeze as many calculations as possible into as few bytes as possible. Then it went in the reverse direction. You started seeing compilers emitting long series of simple instructions instead, seemingly deliberately avoiding those complex addressing modes. And now it's swung back again - I'm the complier using addressing modes to shift plus a couple of adds in one instruction is common again. I presume all these shifts were driven by speed of the resulting code. I have no idea why one method was faster than the other - but clearly there is no hard and fast rule operating here. For some internal x86's implementations using complex addressing modes was a win. On some, for exactly the same instruction set, it wasn't. There is no cut and dried "best" way of doing it, rather it varies as the transistor and power budget changes. One thing we do know about RISC-V is it is intended to cover a _lot_ transistor and power budgets. Where it's used now (low power / low transistor) is turned out their design decisions have turned out _very_ well, far better than x86. More fascinatingly to me, today the biggest speed ups compilers get for super scalar arch's has nothing to do with the addressing modes so much attention is being focused on here. It comes from avoiding conditional jumps. The compilers will often emit code that evaluates both paths of the computation (thus burning 50% more ALU time on a calculating a result that will never be used), then choose the result they want with a cmov. In extreme cases, I've seen doing that sort of thing gain them a factor of 10, which is far more than playing tiddly winks with addressing modes will get you. I have no idea how that will pan out for RISC-V. I don't think any one has done a super scalar implementation of it yet(?) But in the non-super scalar implementations the RISC-V instruction set choices have worked out very well so far. And when someone does do a super scalar implementation (and I'm sure there will be a lot of different implementations over time), it seems very possible x86's learnings on addressing mode use will be yesterdays news.
nickez 5y ago
For those use cases you typically have specialised hardware or an FPGA.
- deleted 5y ago
  [deleted]
- vadfa 5y ago
  So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?
  - lvh 5y ago
    An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).
    - plorkyeran 5y ago
      Hardware video decoding is done by a single-purpose chip on the graphics card (or dedicated hardware inside the GPU), not via software running on the GPU. Adding support for a new video codec requires buying a new video card which supports that codec.
      - The_rationalist 5y ago
        While this is true (GPUs have embedded video ASICs), are there software GPU decoders for video codecs that outperform CPU decoders (and do not use the hardcoded GPU ASICs)? This would allow newer codecs to become mainstream more quickly vs the inertia of needing to buy a new GPU.
    - imtringued 5y ago
      SystemC bloat will require you to upgrade to a bigger FPGA!
lottospm 5y ago
I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer macro-instructions are not automatically a win. I guess we'll eventually see in benchmarks. Even though Intel has had decades to refine their CPUs I'm quite excited to see where RISC-V is going.
- theresistor 5y ago
  As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it for performance, when most ISAs prefer to fix the problem upstream.
  - jasonhansel 5y ago
    Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips. Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...
    - seoaeu 5y ago
      RISC-V does document "official" macro-ops that implementations are encouraged to support.
  - evilos 5y ago
    > "X86 has an internal RISC" is an over-simplification that obscures reality Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.

sanxiyn 5y ago

RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).

zozbot234 5y ago
They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware.
- throwaway81523 5y ago
  > They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware. I would like to see some benchmarks of this efficient implementation in hardware, even simulated hardware, compared against conventional architectures. Even for C, it's a recurring source of bugs and vulnerabilities that int overflow goes undetected. What we really need is an overflow trap like the one in IEEE floating point. RISC-V went the opposite direction.
- adrian_b 5y ago
  Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software. A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient".
  - mlyle 5y ago
    > A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient". 1. There's not multiple additions in the recommended sequences. Unsigned is add,bltu; Signed with one known sign is add, blt; Signed in general is add, slt, slti, bne. 2. These instruction sequences are specified so that an instruction decoder can treat these sequences following the add as a "very wide" instruction specifying to check an overflow flag, if a hardware implementation so chooses.

classichasclass 5y ago

So do what Power does: most instructions that update the condition flags can do so optionally (except for instructions like stdcx. or cmpd where they're meaningless without it, and corner oddballs like andi.). For that matter, Power treats things like overflow and carry as separate from the condition register (they go in a special purpose register), so you can issue an instruction like addco. or just a regular add with no flags, and the condition register actually is divided into eight, so you can operate on separate fields without dependencies.

jabl 5y ago
ARM also does something similar, many instructions has a flag bit specifying whether flags should be updated or not. It doesn't have the multiple flag registers of POWER though.
- crest 5y ago
  Which at least back in the day neither the IBM compilers nor GCC 2.x - 4.x made much use of. I've seen only a few handoptimzed assembler routines get decent use out of them. Easy to fuse pairs a probably a good compromise for carry calculation e.g. add + a carry instruction. That would get rid of one of the additional dependencies, but it would take a three operand addition or fusing two additions to get rid of the second RISC V specific dependency. And while GMP isn't unimportant it is still a niche use case that's probably not worth throwing that much hardware resources at to fix the ISA limitations in the uarch.
  - bshanks 5y ago
    Which feature are you saying was not used much? Addition with carry; or addition without carry; or multiple flag registers?
crest 5y ago
IIRC few Power(PC) cores really split the condition register nibbles into 8 renamable registers and while Power(PC) includes everything (including at least two spare kitchen sinks) only a few instructions can pick which condition register nibble to update. Most integer instructions can only update cr0 and floating point instructions cr1. On the other hand you can do nice hacks with the cornucopia of bitwise available bitwise operations on condition register bits and it's one of the architectures where (floating point) comparisons return the full set of results (less, equal, greater, unordered).

bitwize 5y ago

It's not a tiny corner. People do arithmetic with carry all the time. Arbitrary precision arithmetic is more common than you think. Congratulations, RISC-V, you've not only slowed down every bignum implementation in existence, all those extra instructions to compute carry will blow the I$ faster, potentially slowing down any code that relies on a bignum implementation as well.

andrekandre 5y ago
> all those extra instructions to compute carry will blow the I$ faster i think the idea is, as others have mentioned, the add/comp instructions are fused internally to a single instruction, so probably its not that bad for i$ as we might think?

monocasa 5y ago

> they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other It's doesn't have to be _that_ bad. As long as condition flags are all written at once (or are essentially banked like PowerPC) the dependency issue can go away because they're renamed and their results aren't dependent on previous data. Now, of course, instructions that only update some condition flags and preserve others are the devil.

user-the-name 5y ago

> RISCV also specifies a 128-bit variant that is of course FASTER than these examples Is it actually implemented on any hardware?

ncmncm 5y ago
No. Mentioning it is only meant to distract.
- TheCondor 5y ago
  Is there a semi competitive Risc-V core implemented anywhere? It all seem hypothetical to me now, fast cores would fuse the instructions together so instruction count alone isn't adequate for the original evaluation of the ISA. Now I'm not sure that there are any that really do that..
  - mhh__ 5y ago
    SiFive have a new thing which is roughly as fast as a low-power CPU from Intel or Apple (e.g. IceStorm). Obviously not really competitive, but I think they are still mostly making hardware so there is hardware at-all stage.
  - monocasa 5y ago
    BOOM cores fuse ops already, so the cores don't have to be all that fast to start to see wins from it.