3 ms·

> RISC-V simplicity simply means less bugs Fewer bugs in your code, or fewer bugs to encounter in the platform? I've found that my bugs are usually processor-

by kabdib 7y ago

> RISC-V simplicity simply means less bugs Fewer bugs in your code, or fewer bugs to encounter in the platform? I've found that my bugs are usually processor-independent, and that most of the bugs in SOCs are not with the CPU cores, but the support components around them (e.g., DMA engines and timer registers with bizarre behavior). Well . . . and cache coherency issues. But everyone has cache coherency bugs. :-)

garmaine 7y ago
> Well . . . and cache coherency issues. But everyone has cache coherency bugs. :-) RISC-V is trying to make that a thing of the past.
- kinghajj 7y ago
  "Can't have cache coherency bugs, if your ISA doesn't require cache coherency!"
  - garmaine 7y ago
    Maybe I need to elaborate. The RISC-V foundation is currently working to strictly define both strong and weak cache coherency modes, and a separate formal verification group is working to define and validate a formal model of cache coherency behavior for the RISC-V ISA. There have been numerous updates on this project at the past couple of RISC-V workshops. When this is all done, ensuring a given implementation is bug-free with respect to cache coherency will be a mechanical process (at least, that is the goal).
    - _chris_ 7y ago
      You are confusing memory consistency with cache coherency.
      - garmaine 7y ago
        On a multi-core system it applies to both.
snvzz 7y ago
It's not just your code, but the toolchain. Developers of compilers, debuggers and such are way more likely to introduce bugs with CISC architectures. Complexity doesn't end at the edge of the chip. It goes down the chain. Debugging RISC object code is also easier, for the same reason.
- aseipp 7y ago
  The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to do with how difficult it is to emit object code for some ISA, I'm afraid to tell you. RISC is a meaningless term today to describe design complexity. People see 'cmov' in x86 or the boot process or variable-length instructions or whatever, and think, "wow, how horribly complex this all is, it must be a huge design problem, and it's probably because of the instruction" -- but if they see some modern ARM machine do superscalar OoO execution in order to execute an instruction over multiple cycles and the compiler scheduled instructions taking that particular latency/throughput into account so it could generate optimal code for that uarch -- it's like, wow, this is all so simple, it must make everything so much easier. It doesn't, but it's worth asking what does the debate even mean at that point? All the actual complexity is elsewhere, and is (mostly) independent of the ISA. Side note, but I have RISC-V hardware on my desk and one of the errata for this particular silicon is "the MMU may not catch and deliver all memory access violations correctly" -- meaning you just don't have memory protection sometimes, in some cases, on some days with some shirt colors! I'm pretty sure the ISA doesn't mandate that, and I'm also pretty sure it didn't come from the instruction decoder. Luckily, in this case, programmers have repeatedly proven they are extremely reliable at handling and estimating issues of memory safety (reliably bad at it).
  - snvzz 7y ago
    >The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to do with how difficult it is to emit object code for some ISA, I'm afraid to tell you. Itanium is a counterexample to your argument. >All the actual complexity is elsewhere, and is (mostly) independent of the ISA. Which renders ISA complexity difficult to defend, particularly as RISC-V has demonstrated code density competitive with amd64. Complexity is inherently bad, thus the use of complexity needs strong justification.
guidoism 7y ago
Thank you for the less -> fewer correction. OMG, I am horrible at grammar but for some reason this one drives me crazy and I hear it all the time in our industry.
- mkl 7y ago
  It's not a correction, because "less" is also correct for countable things [1]. "Less" has been used this way for the entire existence of English, and the mistaken idea that it's wrong is relatively recent. [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.html http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.h...
- kabdib 7y ago
  Not intended as a correction, it's just how I english.

by kabdib 7y ago

garmaine 7y ago

> Well . . . and cache coherency issues. But everyone has cache coherency bugs. :-) RISC-V is trying to make that a thing of the past.

kinghajj 7y ago
"Can't have cache coherency bugs, if your ISA doesn't require cache coherency!"
- garmaine 7y ago
  Maybe I need to elaborate. The RISC-V foundation is currently working to strictly define both strong and weak cache coherency modes, and a separate formal verification group is working to define and validate a formal model of cache coherency behavior for the RISC-V ISA. There have been numerous updates on this project at the past couple of RISC-V workshops. When this is all done, ensuring a given implementation is bug-free with respect to cache coherency will be a mechanical process (at least, that is the goal).
  - _chris_ 7y ago
    You are confusing memory consistency with cache coherency.
    - garmaine 7y ago
      On a multi-core system it applies to both.

snvzz 7y ago

It's not just your code, but the toolchain. Developers of compilers, debuggers and such are way more likely to introduce bugs with CISC architectures. Complexity doesn't end at the edge of the chip. It goes down the chain. Debugging RISC object code is also easier, for the same reason.

aseipp 7y ago
The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to do with how difficult it is to emit object code for some ISA, I'm afraid to tell you. RISC is a meaningless term today to describe design complexity. People see 'cmov' in x86 or the boot process or variable-length instructions or whatever, and think, "wow, how horribly complex this all is, it must be a huge design problem, and it's probably because of the instruction" -- but if they see some modern ARM machine do superscalar OoO execution in order to execute an instruction over multiple cycles and the compiler scheduled instructions taking that particular latency/throughput into account so it could generate optimal code for that uarch -- it's like, wow, this is all so simple, it must make everything so much easier. It doesn't, but it's worth asking what does the debate even mean at that point? All the actual complexity is elsewhere, and is (mostly) independent of the ISA. Side note, but I have RISC-V hardware on my desk and one of the errata for this particular silicon is "the MMU may not catch and deliver all memory access violations correctly" -- meaning you just don't have memory protection sometimes, in some cases, on some days with some shirt colors! I'm pretty sure the ISA doesn't mandate that, and I'm also pretty sure it didn't come from the instruction decoder. Luckily, in this case, programmers have repeatedly proven they are extremely reliable at handling and estimating issues of memory safety (reliably bad at it).
- snvzz 7y ago
  >The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to do with how difficult it is to emit object code for some ISA, I'm afraid to tell you. Itanium is a counterexample to your argument. >All the actual complexity is elsewhere, and is (mostly) independent of the ISA. Which renders ISA complexity difficult to defend, particularly as RISC-V has demonstrated code density competitive with amd64. Complexity is inherently bad, thus the use of complexity needs strong justification.

guidoism 7y ago

Thank you for the less -> fewer correction. OMG, I am horrible at grammar but for some reason this one drives me crazy and I hear it all the time in our industry.

mkl 7y ago
It's not a correction, because "less" is also correct for countable things [1]. "Less" has been used this way for the entire existence of English, and the mistaken idea that it's wrong is relatively recent. [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.html http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.h...
kabdib 7y ago
Not intended as a correction, it's just how I english.