Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V: They Should Have Known Better

dmitry.gr

Post reply on HN
Print view View original

31–40 of 467 posts

Re: RISC-V: They Should Have Known Better

#31

Post by Retr0id »

I wrote an RV64IMA emulator recently. I just needed a virtual CPU core that could boot linux, and RV64IMA seemed like the simplest way to do that - and I think that's more or less true.

But then I wanted to be compatible with off-the-shelf toolchains and binaries, and I found myself needing to extend the ISA profile to RV64GC. Not a huge lift, but it involved pulling in a softfloat library. That got me as far as booting Alpine linux.

And then I wanted to be able to boot Ubuntu, which needed RVA23, which was comparatively a much bigger lift, involving the vector instruction set among many other things. At this point I think I'd have been better off just emulating aarch64.

Re: RISC-V: They Should Have Known Better

#32

Post by NetMageSCW »

IshKebab wrote: post #25
__d wrote: post #11

So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly entrenched.

Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.

Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.

Re: RISC-V: They Should Have Known Better

#33

Post by kjs3 »

hn_submit wrote: post #27
tsukikage wrote: post #21

Earlier quoted context omitted.

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, n…

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.

Re: RISC-V: They Should Have Known Better

#35

Post by kjs3 »

walrus01 wrote: post #26
hn_submit wrote: post #16

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 cyc…

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

Re: RISC-V: They Should Have Known Better

#36

Post by IshKebab »

NetMageSCW wrote: post #30
IshKebab wrote: post #20

I think a lot of this criticism is completely true. However it's also overblown. I do think the ISA matters, but little mistakes like these definitely don't matter enough to preclude making M-series class chips. The reason it hasn't happened yet is simply time. It takes a really really long time to build up to that level of performance. They've definitely gone overboard on the optionality stuff though. I don't think…

I don’t think making optional what optional features are available is a little mistake. It is a torpedo to the waterline.

It's not. In practice you have two scenarios:

1. You have a microcontroller. You're compiling code yourself and the docs tells you what features are available and which compiler flags to use.

2. You are writing application code. In that case you simply target RVA23.

The edge case is the same edge case where you use CPUID on x86, I.e. you want to target say RVA23 and RVA28 in the same binary. In that case you do have to use the OS APIs to discover what is supported... which is slightly annoying, but in practice you're just calling a different function.

In theory `mconfigptr` will eventually make this a lot nicer but nobody has put in the effort to define how it works yet (last I heard they were looking at ASN.1 sick emoji).

Re: RISC-V: They Should Have Known Better

#37

Post by duskwuff »

NetMageSCW wrote: post #32
IshKebab wrote: post #25

Earlier quoted context omitted.

Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.

Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.

The ARM ISAs are not free to implement. ARM holds patents relevant to the ISA.

Re: RISC-V: They Should Have Known Better

#38

Post by IshKebab »

NetMageSCW wrote: post #32
IshKebab wrote: post #25

Earlier quoted context omitted.

Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.

Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.

You're vastly underestimating the amount of work that has gone into RISC-V that would need to be redone. It's not just a spec. There's an absolute mountain of software and hardware supporting it.

Re: RISC-V: They Should Have Known Better

#39

Post by fluffybucktsnek »

walrus01 wrote: post #26
hn_submit wrote: post #16

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 cyc…

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

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

Re: RISC-V: They Should Have Known Better

#40

Post by exmadscientist »

hn_submit wrote: post #27
tsukikage wrote: post #21

Earlier quoted context omitted.

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, n…

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

Post reply on HN