RISC-V: The New Architecture on the Block • Hacker News Board

Re: RISC-V: The New Architecture on the Block

#21

Post by oldnews193 » Thu, Sep 30, 2021, 8:22 AM UTC

brucehoult wrote: post #11

hlieberman wrote: post #3

At least one of the points in this article isn't true. The article states "RISC-V is not affected by the Meltdown and Spectre vulnerabilities... [because it does] not perform any speculative memory accesses" -- but that's only true for some designs, not anything done by the ISA. Many of the higher performance RISC-V designs do, in fact, do speculation. RISC-V BOOM[0], by Berkeley, is vulnerable to Spectre[1][2]. One…

What you say is true, but it's not the end of the story. Higher performance RISC-V CPU cores that do speculation are under development or in some cases have been announced but not yet shipped. They have the opportunity to design to avoid those vulnerabilities from the start, which is a lot easier than fixing things up afterwards -- or simply losing a lot of performance on already-shipped CPUs by turning features off.…

> - don't update the branch prediction tables until the branch is proven to execute

> - if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute

This sounds interesting. How do these countermeasures actually prevent Spectre V1? And if they do, why didn't Intel implement them? Seems like they are fully microarchitectural, and therefore opaque to the software world.

Re: RISC-V: The New Architecture on the Block

#22

Post by GoblinSlayer » Thu, Sep 30, 2021, 9:32 AM UTC

throwaway81523 wrote: post #20

brucehoult wrote: post #12

Earlier quoted context omitted.

Newsflash: people who made different decisions on their own designs think they made the right decision. Update at 9. ISAs without condition codes have been around for a long time, and very technically successful. MIPS and DEC Alpha, for example. (both killed by clueless management, not any technical issue) The vast vast majority of condition code updates are either never used at all or are used by the very next instr…

The "1980's called" issue that always gets to me is the absence of arithmetic overflow (or divide by 0) detection. You end up having to generate several additional instructions if you want to catch those errors (-trapv in gcc). On other architectures that's done with condition flags or traps. This doesn't apply to floating point, where condition flags (confusingly called exceptions in IEEE parlance) are mandated by I…

I guess you use this mode when your application is IO bound.

Re: RISC-V: The New Architecture on the Block

#23

Post by zozbot234 » Thu, Sep 30, 2021, 10:04 AM UTC

brucehoult wrote: post #19

ncmncm wrote: post #13

Earlier quoted context omitted.

People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been not…

I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not su…

> This is much more straightforward on RISC-V

AIUI, if SLT returns 0 or -1 you can then reverse the arguments to SUB and get a correct result. If you return the result in a1 you can also keep the 2-operand compressed form of SUB, so there's effectively no difference. Equivalently, you can keep the SUB insn unchanged (thus using a 2-operand form to return in a0) while flipping the previous SLT insns: SLT a1, zero, a0; SLT a0, a0, zero.

Re: RISC-V: The New Architecture on the Block

#24

Post by GoblinSlayer » Thu, Sep 30, 2021, 10:30 AM UTC

brucehoult wrote: post #19

ncmncm wrote: post #13

Earlier quoted context omitted.

People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been not…

I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not su…

I saw mask generation use case only once for constant time ternary operator in cryptography, but I use booleans regularly - your use case 4. In case of cryptography it's x25519 algorithm, but the condition controlling the conditional swap is a bit extracted from the private key and the algorithm uses 255 bits of the key sequentially.

Re: RISC-V: The New Architecture on the Block

#25

Post by ncmncm » Thu, Sep 30, 2021, 12:10 PM UTC

brucehoult wrote: post #19

ncmncm wrote: post #13

Earlier quoted context omitted.

People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been not…

I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not su…

True, it would be better if they had defined RISC-V's C and C++ ABI to make 'true' physically equal to -1, negating or adding 1 to it when actually necessary to treat it as an int value. That would be rare.

The very late addition of the reified B extensions (and others) will be a continuing problem, as builds will not be able to count on them having been implemented. (Trap emulation would be much worse than useless.) The lack of rotate operations in the base instruction set is a problem for implementing modern encryption systems. On embedded chips likely to appear in routers and switches, "extensions" such as the Bs are especially likely to be omitted.

It would not be necessary to abandon the work on RISC-V to do a Risc-6. Most of the work done could carry over.

Re: RISC-V: The New Architecture on the Block

#26

Post by brucehoult » Thu, Sep 30, 2021, 2:10 PM UTC

ncmncm wrote: post #25

brucehoult wrote: post #19

Earlier quoted context omitted.

I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not su…

True, it would be better if they had defined RISC-V's C and C++ ABI to make 'true' physically equal to -1, negating or adding 1 to it when actually necessary to treat it as an int value. That would be rare. The very late addition of the reified B extensions (and others) will be a continuing problem, as builds will not be able to count on them having been implemented. (Trap emulation would be much worse than useless.)…

No more of a problem than in any other ISA that has seen incremental improvements -- which is all of them.

Modern x86_64 OSes such as Windows and Linux run on everything back to the original Opteron and Athlon 64 from 2003, which don't have POPCNT and LZCNT. Those were implemented by AMD starting with Bobcat and Bulldozer in 2011. Intel added POPCNT in Nehalem in 2008 and LZCNT in Haswell in 2013.

Aarch64 got both from the start, but there are other things added in ARMv8.1-A through ARMv8.8-A (and ARMv9) which are presumably also useful to certain software.

Embedded chips used in routers and switches will take exactly the extensions useful to them and none that aren't. If Zbb is useful to them then they will certainly include it -- that's why the extensions are specified so finely with three non-overlapping extensions for BitManip being defined this year. Applications processors running shrink-wrapped OSes are required to take all the extensions in RVA22 (or none). The embedded world picks and chooses what they want.

Re: RISC-V: The New Architecture on the Block

#27

Post by ncmncm » Thu, Sep 30, 2021, 7:32 PM UTC

brucehoult wrote: post #26

ncmncm wrote: post #25

Earlier quoted context omitted.

True, it would be better if they had defined RISC-V's C and C++ ABI to make 'true' physically equal to -1, negating or adding 1 to it when actually necessary to treat it as an int value. That would be rare. The very late addition of the reified B extensions (and others) will be a continuing problem, as builds will not be able to count on them having been implemented. (Trap emulation would be much worse than useless.)…

No more of a problem than in any other ISA that has seen incremental improvements -- which is all of them. Modern x86_64 OSes such as Windows and Linux run on everything back to the original Opteron and Athlon 64 from 2003, which don't have POPCNT and LZCNT. Those were implemented by AMD starting with Bobcat and Bulldozer in 2011. Intel added POPCNT in Nehalem in 2008 and LZCNT in Haswell in 2013. Aarch64 got both fr…

In other words, as much of a problem as in any ISA that has seen incremental improvements. We are supposed to learn from the mistakes of our forbears, not repeat them verbatim.

Chips used in routers and switches will be exactly what is cheapest, just as now, regardless of what performs best or adequately. Thus, they will lack B extensions, howsoever useful they might have been.

Re: RISC-V: The New Architecture on the Block

#28

Post by zozbot234 » Thu, Sep 30, 2021, 8:37 PM UTC

ncmncm wrote: post #27

brucehoult wrote: post #26

Earlier quoted context omitted.

No more of a problem than in any other ISA that has seen incremental improvements -- which is all of them. Modern x86_64 OSes such as Windows and Linux run on everything back to the original Opteron and Athlon 64 from 2003, which don't have POPCNT and LZCNT. Those were implemented by AMD starting with Bobcat and Bulldozer in 2011. Intel added POPCNT in Nehalem in 2008 and LZCNT in Haswell in 2013. Aarch64 got both fr…

In other words, as much of a problem as in any ISA that has seen incremental improvements. We are supposed to learn from the mistakes of our forbears, not repeat them verbatim. Chips used in routers and switches will be exactly what is cheapest, just as now, regardless of what performs best or adequately. Thus, they will lack B extensions, howsoever useful they might have been.

> In other words, as much of a problem as in any ISA that has seen incremental improvements.

That's way overstated. RISC-V is still an amazingly clean and elegant design, placing extreme focus on technical excellence and on making effective use of limited insn encoding space. (Just look at how cautious the ratification of B and V has been - some of that was due to wanting to maximize feasible overlap between B and other exts, so as to avoid wasting even the smallest fractions of insn space). Tiny warts like SLT returning 0/1 as opposed to 0/-1 don't change that in any way.

Re: RISC-V: The New Architecture on the Block

#29

Post by ncmncm » Thu, Sep 30, 2021, 8:41 PM UTC

zozbot234 wrote: post #17

ncmncm wrote: post #13

Earlier quoted context omitted.

People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been not…

> Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Going from 0/1 to 0/~0 (or conversely) just takes a NEG instruction. All in all, it's a trivial difference. And it's hard to say what's more convenient in actual code.

"Just takes" is another way to say "takes". And, when all your instructions are at least 4 bytes, that takes another 4 bytes.

Re: RISC-V: The New Architecture on the Block

#30

Post by ncmncm » Thu, Sep 30, 2021, 9:07 PM UTC

zozbot234 wrote: post #28

ncmncm wrote: post #27

Earlier quoted context omitted.

In other words, as much of a problem as in any ISA that has seen incremental improvements. We are supposed to learn from the mistakes of our forbears, not repeat them verbatim. Chips used in routers and switches will be exactly what is cheapest, just as now, regardless of what performs best or adequately. Thus, they will lack B extensions, howsoever useful they might have been.

> In other words, as much of a problem as in any ISA that has seen incremental improvements. That's way overstated. RISC-V is still an amazingly clean and elegant design, placing extreme focus on technical excellence and on making effective use of limited insn encoding space. (Just look at how cautious the ratification of B and V has been - some of that was due to wanting to maximize feasible overlap between B and ot…

Way understated, rather. If you have AVX, you know you also have POPCNT and everything else older than AVX. Having thing A on RISC-V tells you nothing about whether you have thing B or C, or vice versa. The set of possible targets is exponential in the number of extensions, rather than strictly linear in the number of additions, as seen in existing chips.

"Tiny warts" reveal mindset: how aware are the designers of the consequences of their choices? Each is a clue. Lack of rotate and popcount instructions in the core instruction set provides a clue. Expectation that five-instruction sequences can be fused might be another. (When your instructions are already 4 bytes or more, each, five means at least 20 bytes for a single primitive operation.) The extremely complicated extensions landscape is another.