Hacker News Reader

Comment by londons_explore | Hacker News Reader

I really wish RISC-V had been designed in such a way that every RISC-V core must run every RISC-V binary.

However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated. The standard would require that hardware trap everything unimplemented, and that software always contain a fallback implementation.

Then, the fragmentation problem turns from a "it won't work" problem into a "it might not be quite as fast" problem - and for general users, that effectively means everything is 100% compatible.

View on HN

This does not make much sense to me. First off, extensions are added all the time. That means an application would crash if it used a newer extension that the kernel/firmware didn't know about when it was compiled.

Secondly, extensions cover a lot of things. They can do much more than just introduce instructions, like introduce new hardware registers. The RVA23 profile that's under discussion here for example includes a hypervisor extension[1]. I don't see how you can emulate that in software after the fact in a meaningful way.

Third, RISC-V was designed to be used all the way from microcontrollers to application processors. Especially for the embedded use-cases, you're targeting a well-defined collection of processors, so which extensions you can use is well-known and not subject to changes willy-nilly.

The RVA23 profile that's just been ratified is aimed at more general processors, which will run more varied software. There it makes sense to agree on a well-defined subset of extensions, which is why they do exactly that through these profiles.

> The RVA23 profile that's under discussion here for example includes a hypervisor extension[1]. I don't see how you can emulate that in software

In fact the hypervisor extension was explicitly designed to be relatively efficient to implement in software emulation.

It even says so at the URL you failed to include:

"The hypervisor extension has been designed to be efficiently emulable on platforms that do not implement the extension, by running the hypervisor in S-mode and trapping into M-mode for hypervisor CSR accesses and to maintain shadow page tables. The majority of CSR accesses for type-2 hypervisors are valid S-mode accesses so need not be trapped. Hypervisors can support nested virtualization analogously."

https://five-embeddev.com/riscv-priv-isa-manual/Priv-v1.12/h...

> In fact the hypervisor extension was explicitly designed to be relatively efficient to implement in software emulation.

Fair point, I stand corrected on that one. Should have checked more thoroughly before posting.

> It even says so at the URL you failed to include

That site doesn't render right on my mobile, which I was on at the time, so couldn't read the contents.

> "[...] by running the hypervisor in S-mode [...]"

That doesn't sound very efficient if all you got is an M-mode-only chip though.

In any event, you also have extensions like Ztso[2], which even the spec says to just let the binary crash in event of non-presence, or Zam[3] which you technically could emulate but surely would be dog slow.

[1]: https://five-embeddev.com/riscv-priv-isa-manual/Priv-v1.12/p...

[2]: https://five-embeddev.com/riscv-user-isa-manual/Priv-v1.12/z...

[3]: https://five-embeddev.com/riscv-user-isa-manual/Priv-v1.12/z...

[4}: https://www.riscfive.com/2022/12/07/sifive-intelligence-fami...

> That doesn't sound very efficient if all you got is an M-mode-only chip though.

There is approximately a light-year of space between an M-mode-only chip and anything where you'd consider running a hypervisor.

Suggesting that you want a hypervisor is implicitly saying that you already have S and U modes, virtual memory, page tables, MMU etc.

Otherwise you're at much the same point as those news stories about how someone is running RISC-V Linux on an AVR or Pi Pico (original) or vim macros, by writing a RISC-V emulator on one of those.

Hey, OP wanted RISC-V binaries to run anywhere, not me...

This is really the whole problem that Profiles is aiming to solve. A core claiming to be RVA23 must implement certain extensions and may implement others. Your binary can therefore assume the required extensions and test for the optional ones.

This is no different from how x86 works today. Both Windows and Linux OSes and their binaries assume some minimum level of x86-64 support (eg. x86_64-v3 will be the base "profile" for RHEL 10 [1]). For other things like AVX-512, portable binaries test for the "extension" before using.

[1] https://developers.redhat.com/articles/2024/01/02/exploring-...

As the extension spaghetti from OpenGL and Vulkan have proven, alongside with the required software rendering fallback in OpenGL, this doesn't really quite work in practice.

That would involve a 100x slowdown in most cases, without dynamic code generation.

It's much better to compile multiple versions of the code or multiple binaries.

Also, any OS kernel could do transparent emulation like that with no need for CPU assistance (beyond trapping on unsupported instructions, which all modern ISAs of course already do), so it's more of a Linux/Windows ABI issue. You can also write an LD_PRELOAD library that does the emulation.

Why though? We don't expect that of X86, ARM, or anything else. X86, ARM or the hundreds of other ISAs that have come and gone. We don't ask because it's impossible without putting a freeze on adding new instrucions. Once you add a new instruction there's no way for binaries with that instruction have that instruction run on an older processor. A compiler reads a value from memory. If that value doesn't map to an instruction it can follow, what do?

RISCV is actually better than most in this. First of all there is a core ISA that will run on everything and the extensions can be setup to be ignored when running on a system without them, defaulting to some core-ISA alternative.

The only alternative is to get the entire ISA spec done before letting anyone make anything... and that's just not happening.

One would simply specify that for any instruction used by a binary outside some core set, a fallback must be offered. For many instructions, the fallback might be just a few bytes of code.

The hardware would provide some assistance for said fallback mechanism - for example in the form of a pointer to a "fallback vector". If you execute unknown instruction 0x80 then code at the fallback pointer+0x80 will be executed instead.

The binary doesn't have to use this fallback mechanism - for performance critical binaries which want to run fast on different hardware implementations, the compiler could use feature detection to make multiple implementations of some functions, the way many SSE/AVX extensions are dealt with in the x86 world.

Binaries that aren't intended to run on bare metal, but instead run on some OS (eg. windows/linux) could instead specify as part of their ABI which instructions are part of the core, and the OS will ensure that anything unsupported by the hardware but required by the binary will be provided by the OS.

Almost everything here is outside of the ISA-spec's scope though. Mandating a fallback-vector be specified for each compilation and there be compatible alts available there seems like you're going beyond an ISA spec and into how programs and data are stored. Sure, RISCV could say "here's what you run instead of new instruction Y if Y ins't available but I'm not sure it's in there remit to ensure these alt instructions are always there.

Your comment about the compiler using feature suggestions has got nothing to do with RISCV, it's up to the compiler developers how to do that and if they want to. This is how it works right now. The compiler inspects the hardwarew and works accordingly.

RISCV dont get to decide how the OS works. It's up to the OS developers on how a binary is handled. They can't stop me creating an OS that doesn't filter unsupported instructions and therefore the guarantee cannot be kept.

You could have an interrupt style thing for unsupported instructions with suggestions on how software/the OS handle them, but whether or not they choose to handle them is not RISC-Vs problem.

> One would simply specify that for any instruction used by a binary outside some core set, a fallback must be offered.

That is exactly what RVA23 does. It specifies what must work. It doesn't specify the performance of any instruction -- that is between a hardware vendor and their customers as to which ones are fast.

> If you execute unknown instruction 0x80 then code at the fallback pointer+0x80 will be executed instead.

RISC-V instructions are 4 bytes long (i.e. 2^32 of them), not 1 byte. Using that simple technique, with just a pointer to the actual handler included in the table, the table will be 32 GB in size.

> I really wish RISC-V had been designed in such a way that every RISC-V core must run every RISC-V binary.

Obviously impossible, given that commercially-available RISC-V chips start from 2 KB RAM, 16 registers, and 48 MHz.

> wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated

And that is exactly what RVA23 is.

Every instruction must work. Nothing requires them to be fast. Missing instructions or capabilities (e.g. misaligned load/store) are handled in M-mode software, transparent to both the User program and the operating system.

> Then, the fragmentation problem turns from a "it won't work" problem into a "it might not be quite as fast" problem - and for general users, that effectively means everything is 100% compatible.

That is exactly the situation with RVA23.

I don't understand why this is something people bring up all the time. Downstream users can build the binaries for their arch on their own. Unless you want to distribute programs as binaries? But then why wouldn't you and your users be happy targeting ARM instead of RISC-V then?

Yeah, the extensibility of RISC-V that allows implementations to scale up and down on features, including non-standard ones is really cool, but compared to other ISA I think the biggest improvement is it being Open and royalty free (except for trademark+compliance certifications)

- https://riscv.org/about/faq/ j - https://riscv.org/membership/ (I thought this was going to be expensive, but 2k USD/yr -> 5kUSD/yr after 2yr can keep a small company going)

Nothing prevents OEM vendors to add their proprietary extensions not available on other vendors RISC-V cores.

Welcome to non-copyleft hardware designs.

I think you want that, but in a reserved instruction space with mandatory fallbacks.

It's how things work anyway, things that are on the edge of what can be done are good for running business and maybe not finalized enough to become standards.

Kind of, that isn't what many FOSS advocates of RISC-V are expecting, yet that is how many things will go, if it ever reaches ARM adoption levels.

It'd be cool for it to be copy-left, but at the same time I guess it could end up being too hard to get business running as the apparent risk of a competitor just copying your product would scare investors and that would end up in lower availability of actual hardware you can buy.

> However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated.

For (fixed-length-)vector extensions in particular, I’m not sure that would work well. For nontrivially vectorizable things (i.e. you’re not just doing a bunch of math in parallel), the usual tradeoff is that you use a couple times more compute, but because the vector unit can provide a couple dozen or more times the compute per clock the result is faster despite the apparent waste. Emulating such code, on the other hand, will likely be miserable.

But 99% of code does not use vector instructions. That last 1% will either get slower (emulating trapped instructions), or have a 2nd non-vectorized implementation, with the binary containing both.

>But 99% of code does not use vector instructions.

Note that both LLVM and GCC will try to auto-vectorize code and emit vector instructions.

Firstly, that's a high ask even for operating system software today. Something built for Mac 9 today is not expected to run on Mac OS 15. Demanding that from a cpu is quite the extreme.

Secondly, that's like asking cpu to do the job of a compiler. The compiler has one advantage over a cpu: it runs in a completely situation where memory and time do not matter. The cpu doesn't have the luxury of trading off memory or time.

By all means, feel free to design your own ISA to fit every use case from the get-go, publish it in its final state, port toolchains and relevant software, and convince the world to use it.

RISC-V chose a different approach, because this one, quite frankly, would not have worked.

LoongArch may be for them?

Reply on news.ycombinator.com