3 ms·

Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is alrea

Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time. Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cycles doesn't really matter that much. And RISC-V does have a link register, making returning much faster when the parameters for the interrupt can all fit in registers and no external memory access is needed, as is the case with most MCUs which put the stack in RAM. To fetch the return address an external memory access is always needed even if there are no parameters.

tsukikage 2mo ago
He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.
- hn_submit 2mo ago
  You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, not to provide an "one size fits all" solution.
  - kjs3 2mo ago
    I don't think I've read a more "doesn't actually know anything about how software is produced, but with absolute confidence knows everything about it" post in a very long time.
    - hn_submit 2mo ago
      So you write software for a platform you know nothing about?
      - kjs3 2mo ago
        [flagged]
        deleted 2mo ago
        [deleted]
        fluffybucktsnek 2mo ago
        Both of your post are actual ad hominem towards OP. In the first, you just said they didn't know how software is developed, without elaborating. With this in mind, their reply is less of an ad hominem and more of an inquiry. In the next, you accuse them of having a fragile ego and being a kid. Not very insightful.
        kjs3 2mo ago
        [flagged]
      - dmitrygr 2mo ago
        Very often. Yes. Or software that will run on any similar arch by auto detecting the environment.
      - Twirrim 2mo ago
        > So you write software for a platform you know nothing about? That's how a sizeable chunk of software is written and shipped. Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day. Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap https://docs.openssl.org/master/man3/OPENSSL_ia32cap/ https://docs.openssl.org/master/man3/OPENSSL_ia32cap/ This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.
  - exmadscientist 2mo ago
    > You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. In practice, this is not the case. The scenarios mentioned in the article involving binary blobs are pretty common, as well as other similar scenarios. Really, I'm going to go out and say it bluntly: it is just completely freaking stupid to make an architecture where everything is optional but you have no way to query what's present. If you're going to go the optional-pieces route, you have to have a query mechanism of some sort. As the article explains, you cannot even trap instructions on RISC-V to figure out what your core supports, because bad instructions might belong to some other option. Complete. Idiocy.
  - jcranmer 2mo ago
    I'm not an embedded programmer myself, but from what I've heard... it's actually a pretty big assumption that the software people know what model hardware they're running on. Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.
    - hn_submit 2mo ago
      If the product manager isn't an engineer he shouldn't be making these kinds of decisions.
    - monocasa 2mo ago
      That doesn't really happen in the embedded space. Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package. You're looking at explicit support for each chip.
      - apple1417 2mo ago
        I worked on a project porting from an STM32L073 to a STM32U073, which management were assured was a complete drop in replacement. Well, it was only in the sense that you could drop one onto the old PCB. It became a running joke how many software compatibilities we ran into. My favourite was an "LCD clock disable" bit became "LCD clock enable". And this was for a specifically chip designed to be an easy replacement.
- mappu 2mo ago
  I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.
  - monocasa 2mo ago
    Well, misa won't be in most cases since you'll be running ins mode rather than m mode for most kernels on an application core (and misa won't tell you about the X* and Z* extensions). But you'll practically be passed a device tree from SBI that will tell you.
  - Neywiny 2mo ago
    He actually explains this too. You only know at compile time what you're building for. For example with microblaze-V, I often tweak what ISA I'm generating. If I ran the same elf without thinking about it, who knows what could happen given the instruction collision problem
- camel-cdr 2mo ago
  There is a very easy way to determine what hardware you are running on, it's the baseline of the OS. Armv9-a doesn't mandate FP or SIMD support, but nobody does detection for those, why? Because it's required on the OS level. Similarly OS are moving their baseline to RVA23 so software can assume all of those instructions are available.
walrus01 2mo ago
> The market can sort it out for themselves Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.
- kjs3 2mo ago
  Noone uses an 8051 because it's elegant. Billions are still still sold every year because no matter if you learned it in the 70s or last week and no matter who made it, the basics are exactly alike. Software matters; ISAs don't.
  - lowbloodsugar 2mo ago
    >You learned it in the 70s [emphasis mine] I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts. As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?
    - kjs3 2mo ago
      I really don't know anything about this space And yet you couldn't help yourself... but you just said that 8051 is dominant I said absolutely no such thing. If the Software can't run because of hundreds of extensions The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z". Which ISA means my software runs on the most devices? Easiest question evah: x86.
      - lowbloodsugar 2mo ago
nickff 2mo ago
>"RISC-V is already dominant in the MCU space[...]" Where are you getting the idea that RISC-V is dominant? As someone who works in this space, that doesn't jive with my experience or the sources I've seen.[1] 32-bit microcontrollers only recently achieved a majority market share for gosh sakes! RISC-V is claiming that they have achieved 25% market share across selected segments, but they're still behind ARM (and x86).[2] [1] https://www.grandviewresearch.com/industry-analysis/microcontroller-market https://www.grandviewresearch.com/industry-analysis/microcon... [2] https://www.aestechno.com/en/risc-v-2026-arm-x86-market/ https://www.aestechno.com/en/risc-v-2026-arm-x86-market/
- gertop 2mo ago
  Risc-v is nowhere near dominant, people are just being swayed by headlines such as Western Digital or Nvidia shipping billions of risc-v cores. I do find it odd that you go on and compare to x86 marketshare however, the topic you've quoted is very clearly about MCU and whilst 8086 MCU still exists they haven't been used in greenfield projects for decades. Let alone any more recent x86 implementation.
  - hn_submit 2mo ago
    Because it's in stuff where you don't see it: in your vacuum cleaner, your toaster oven, your microwave or your electric kettle. Do you really think Chinese manufacturers are going to buy ARM MCUs when their budget for a controller is less than 10 cents? ARM has long ceded this market to RISC-V. It's mostly focusing on high-end application MCUs and AI now. And lots of newer stuff is making use of standardized boards like Raspberry Pi Pico (RISC-V and ARM hybrid) or ESP32 (RISC-V too on some versions).
- hn_submit 2mo ago
  It's used widely in Chinese stuff (which is basically everything) so in terms of volume it's probably already dominant. In terms of dollar volume ARM is still the leader, especially for higher-end (application level MCUs) stuff. RISC-V MCUs with MMUs or MPUs are scarce at the moment.

tsukikage 2mo ago

He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.

hn_submit 2mo ago
You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, not to provide an "one size fits all" solution.
- kjs3 2mo ago
  I don't think I've read a more "doesn't actually know anything about how software is produced, but with absolute confidence knows everything about it" post in a very long time.
  - hn_submit 2mo ago
    So you write software for a platform you know nothing about?
    - kjs3 2mo ago
      [flagged]
      - deleted 2mo ago
        [deleted]
      - fluffybucktsnek 2mo ago
        Both of your post are actual ad hominem towards OP. In the first, you just said they didn't know how software is developed, without elaborating. With this in mind, their reply is less of an ad hominem and more of an inquiry. In the next, you accuse them of having a fragile ego and being a kid. Not very insightful.
        kjs3 2mo ago
        [flagged]
    - dmitrygr 2mo ago
      Very often. Yes. Or software that will run on any similar arch by auto detecting the environment.
    - Twirrim 2mo ago
      > So you write software for a platform you know nothing about? That's how a sizeable chunk of software is written and shipped. Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day. Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap https://docs.openssl.org/master/man3/OPENSSL_ia32cap/ https://docs.openssl.org/master/man3/OPENSSL_ia32cap/ This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.
- exmadscientist 2mo ago
  > You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. In practice, this is not the case. The scenarios mentioned in the article involving binary blobs are pretty common, as well as other similar scenarios. Really, I'm going to go out and say it bluntly: it is just completely freaking stupid to make an architecture where everything is optional but you have no way to query what's present. If you're going to go the optional-pieces route, you have to have a query mechanism of some sort. As the article explains, you cannot even trap instructions on RISC-V to figure out what your core supports, because bad instructions might belong to some other option. Complete. Idiocy.
- jcranmer 2mo ago
  I'm not an embedded programmer myself, but from what I've heard... it's actually a pretty big assumption that the software people know what model hardware they're running on. Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.
  - hn_submit 2mo ago
    If the product manager isn't an engineer he shouldn't be making these kinds of decisions.
  - monocasa 2mo ago
    That doesn't really happen in the embedded space. Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package. You're looking at explicit support for each chip.
    - apple1417 2mo ago
      I worked on a project porting from an STM32L073 to a STM32U073, which management were assured was a complete drop in replacement. Well, it was only in the sense that you could drop one onto the old PCB. It became a running joke how many software compatibilities we ran into. My favourite was an "LCD clock disable" bit became "LCD clock enable". And this was for a specifically chip designed to be an easy replacement.
mappu 2mo ago
I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.
- monocasa 2mo ago
  Well, misa won't be in most cases since you'll be running ins mode rather than m mode for most kernels on an application core (and misa won't tell you about the X* and Z* extensions). But you'll practically be passed a device tree from SBI that will tell you.
- Neywiny 2mo ago
  He actually explains this too. You only know at compile time what you're building for. For example with microblaze-V, I often tweak what ISA I'm generating. If I ran the same elf without thinking about it, who knows what could happen given the instruction collision problem
camel-cdr 2mo ago
There is a very easy way to determine what hardware you are running on, it's the baseline of the OS. Armv9-a doesn't mandate FP or SIMD support, but nobody does detection for those, why? Because it's required on the OS level. Similarly OS are moving their baseline to RVA23 so software can assume all of those instructions are available.

walrus01 2mo ago

> The market can sort it out for themselves Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.

kjs3 2mo ago
Noone uses an 8051 because it's elegant. Billions are still still sold every year because no matter if you learned it in the 70s or last week and no matter who made it, the basics are exactly alike. Software matters; ISAs don't.
- lowbloodsugar 2mo ago
  >You learned it in the 70s [emphasis mine] I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts. As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?
  - kjs3 2mo ago
    I really don't know anything about this space And yet you couldn't help yourself... but you just said that 8051 is dominant I said absolutely no such thing. If the Software can't run because of hundreds of extensions The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z". Which ISA means my software runs on the most devices? Easiest question evah: x86.
    - lowbloodsugar 2mo ago

nickff 2mo ago

>"RISC-V is already dominant in the MCU space[...]" Where are you getting the idea that RISC-V is dominant? As someone who works in this space, that doesn't jive with my experience or the sources I've seen.[1] 32-bit microcontrollers only recently achieved a majority market share for gosh sakes! RISC-V is claiming that they have achieved 25% market share across selected segments, but they're still behind ARM (and x86).[2] [1] https://www.grandviewresearch.com/industry-analysis/microcontroller-market https://www.grandviewresearch.com/industry-analysis/microcon... [2] https://www.aestechno.com/en/risc-v-2026-arm-x86-market/ https://www.aestechno.com/en/risc-v-2026-arm-x86-market/

gertop 2mo ago
Risc-v is nowhere near dominant, people are just being swayed by headlines such as Western Digital or Nvidia shipping billions of risc-v cores. I do find it odd that you go on and compare to x86 marketshare however, the topic you've quoted is very clearly about MCU and whilst 8086 MCU still exists they haven't been used in greenfield projects for decades. Let alone any more recent x86 implementation.
- hn_submit 2mo ago
  Because it's in stuff where you don't see it: in your vacuum cleaner, your toaster oven, your microwave or your electric kettle. Do you really think Chinese manufacturers are going to buy ARM MCUs when their budget for a controller is less than 10 cents? ARM has long ceded this market to RISC-V. It's mostly focusing on high-end application MCUs and AI now. And lots of newer stuff is making use of standardized boards like Raspberry Pi Pico (RISC-V and ARM hybrid) or ESP32 (RISC-V too on some versions).
hn_submit 2mo ago
It's used widely in Chinese stuff (which is basically everything) so in terms of volume it's probably already dominant. In terms of dollar volume ARM is still the leader, especially for higher-end (application level MCUs) stuff. RISC-V MCUs with MMUs or MPUs are scarce at the moment.