5 ms·

For me it is clear RISC-V will become the defacto standard in processors, soon it'll even compete on the high end. So besides being cheaper: - as a developer m

For me it is clear RISC-V will become the defacto standard in processors, soon it'll even compete on the high end. So besides being cheaper: - as a developer my RISC-V (assembly and system) skills will remain relevant and valuable - by using RISC-V MCU's now I will avoid future family migrations - RISC-V's are already the MCU's of choice embedded in FPGA's and AI chips, and I won't need to learn another tool before being able to utilize them - RISC-V enables collective community-enabled innovation (which was the prime driver for creating it) - Rust runs on RISC-V MCUs (besides ARM) - RISC-V simplicity simply means less bugs

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.
aseipp 7y ago
Almost all of those points are true of any mainstream architecture (x86, ARM aren't going anywhere, your skills are valuable today, you don't have to throw away any code anytime soon, Rust works today on both) and the others ("chip of choice for AI", "defacto standard", "simplicity means less bugs") are either entirely arguable or outright naivety, they don't say anything unique. The ISA being experimented with and extensions being made is certainly an undeniable plus, though. People on this website just hype it to outrageous levels because the ISA is all 95% of them interact with at any level, and sometimes not even then, so all other factors/considerations are completely ignored in favor of just believing it's really The Best (and I say that as someone who owns real RISC-V hardware and am writing my own emulator, and want it to succeed.) But you don't have to just make stuff up to sell it. You can just say "It's a pretty good ISA, it's freely available/modifiable, and there's a ton of good tooling already available for it". That's a pretty good sell on its own, to be perfectly honest.
- childintime 7y ago
  > x86, ARM aren't going anywhere x86's have never been a thing in MCU's, so ARM has more to lose. > Almost all of those points are true of any mainstream architecture No, that isn't true at all, not when you consider the end-game: they are not open source, they are not simple enough for that to make a difference, and they'll therefore never attract the collective creativity. Maybe some other new architecture will though. Everybody should make their own bets though. > People on this website just hype it to outrageous levels Though RISC-V certainly is in the hype phase this is also entirely justified. From that point of view it seems you have an invested interest in some other architecture, and see that investment threatened.
  - drudru11 7y ago
    Just to be clear, the ISA is open source. The design or implementation does not have to be.

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.

aseipp 7y ago

Almost all of those points are true of any mainstream architecture (x86, ARM aren't going anywhere, your skills are valuable today, you don't have to throw away any code anytime soon, Rust works today on both) and the others ("chip of choice for AI", "defacto standard", "simplicity means less bugs") are either entirely arguable or outright naivety, they don't say anything unique. The ISA being experimented with and extensions being made is certainly an undeniable plus, though. People on this website just hype it to outrageous levels because the ISA is all 95% of them interact with at any level, and sometimes not even then, so all other factors/considerations are completely ignored in favor of just believing it's really The Best (and I say that as someone who owns real RISC-V hardware and am writing my own emulator, and want it to succeed.) But you don't have to just make stuff up to sell it. You can just say "It's a pretty good ISA, it's freely available/modifiable, and there's a ton of good tooling already available for it". That's a pretty good sell on its own, to be perfectly honest.

childintime 7y ago
> x86, ARM aren't going anywhere x86's have never been a thing in MCU's, so ARM has more to lose. > Almost all of those points are true of any mainstream architecture No, that isn't true at all, not when you consider the end-game: they are not open source, they are not simple enough for that to make a difference, and they'll therefore never attract the collective creativity. Maybe some other new architecture will though. Everybody should make their own bets though. > People on this website just hype it to outrageous levels Though RISC-V certainly is in the hype phase this is also entirely justified. From that point of view it seems you have an invested interest in some other architecture, and see that investment threatened.
- drudru11 7y ago
  Just to be clear, the ISA is open source. The design or implementation does not have to be.