Hacker News Reader

Comment by hn_submit | Hacker News Reader

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.

View on HN

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.

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.

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.

So you write software for a platform you know nothing about?

Very often. Yes. Or software that will run on any similar arch by auto detecting the environment.

> 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/

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.

If you knew anything about ASIPs you would know that you're complaining about yourself.

> 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.

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.

If the product manager isn't an engineer he shouldn't be making these kinds of decisions.

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.

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.

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.

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.

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

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.

>"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/microcon...

[2] https://www.aestechno.com/en/risc-v-2026-arm-x86-market/

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.

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).

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.

> RISC-V MCUs with MMUs or MPUs

MPUs are more common. The Physical Memory Protection option is basic and allows ranges of memory to be set unavailable in user mode. A few well-defined ranges do let you lock a user process down securely but it's not a real MMU. Low-end microcontrollers don't have enough RAM to warrant a real MMU.

The RISC-V core in the Raspberry Pi RP2350 has PMP as do the ESP32 cores.

> 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.

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.

>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?

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.

Yeah, I completely misinterpreted you post. Apologies.

Every time I've seen someone use an 8051 in the past twenty years, it's had new, bespoke software written for it. They were more used because they were a known quantity with the patents obviously dead rather than support for existing codebases.

Interesting comment. I suspect without solid facts that new bespoke stuff is mostly either 1) some ARM variant, or 2) some rando US$0.001 Chinese uproc. I think 8051 survives because there's many decades of experience using it, but as I understand the cool kids going into embedded don't think the boomers 8051 is fun and the pool of talent is shrinking fast. SO we'll see what the future holds.

Those aren't mutually exclusive. Some of the sophgo and bouffalo chips have 8051s for always on cores, and riscv for the main cores.

They didn't choose 8051 there for experience, but because it was a tiny core with a decent IPC they could license for a small part, then focus on the main cores. I wouldn't be surprised if they eventually switch to riscv there too.

Also, these 8051 cores tend to be extremely diverse. I don't think I've come across cores from different manufacturers that were actually compatible for real code. They all seem to want to handle accessing 16/32 bit memory differently, have different interrupt details, etc.

Interesting...I don't know much about sophgo and bouffalo chips. Not surprising since the 8051 is patent-free these days. Something I found crazy is how many places someone embedded an 8051 core. Like the tire pressure monitor in every tire these days. Fun stuff.

> Because nobody will write software for 300 unique hardware variations

Who said they have to? One can select a RISC-V configuration for a baseline for a particular purpose. Desktop? Choose the one that's most powerful.

ARM is more popular than x86 and is less consistent than it.

I believe the market will standardize on certain extensions for specific solutions. No one is going to make a mobile phone with only RV32I, for example.

Yeah, that's the point of the profiles. A curated set of extensions for common use cases like application cores for generic software to target.

How can you use consistency and SSE/AVX in the same sentence?

SSE has inconsistencies like SSE4.x vs SSE4a. AVX is an even more mixed bag. There are some 19 AVX-512 extensions and ZERO chips support all of them.

The situation is so bad that AMD and Intel got together to make AVX10 to unify everything. That seemed great, but Intel now has AVX 10.1 and 10.2 in addition to the base set, so there we go again...

x86 is a massive battleground with tons of competing extensions like FMA3 vs FMA4 (why did FMA3 win???) and in cases where one of the competing variants didn't win, we get something like virtualization extensions being completely different between Intel and AMD. There's also the rash of security extensions that have gone through various support and dropped support (not to mention using some of this stuff for market segmentation and further fragmenting the ecosystem).

x86 is anything but consistent if you look into its history (or even it's present).

> but Intel now has AVX 10.1 and 10.2 in addition to the base set

Intel committed to not slicing and dicing the AVX instruction set going forward. AVX 10.(n+1) will not remove instructions that were in AVX 10.n. Feature testing is also easier: a single feature bit and a single version number.

I bet Intel's management will find some new counterproductive way of segmenting the market but AVX-10 (and therefore AVX-512) should be safe now.

Reply on news.ycombinator.com