Hacker News Reader

Comment by mbitsnbites | Hacker News Reader

I think you're onto something, but I'm not entirely sure that that's exactly how it's going to play out.

First of all I don't think that "compatibility will reign". It's more like once the industry really starts picking up RISC-V, fragmentation will reign (at least for a decade or so).

It's also quite likely (IMO) that we'll see a "next generation" rather sooner than later, i.e. "RISC-VI". RISC-V, with some agreed upon extensions, may become the norm for Android, mobile, automotive and so on, but for the high end (servers, gaming, etc) I think that the industry will push for a different philosophy than the RISC-V authors originally envisioned - and that could become a new "revision" if you will.

View on HN

The baseline RISC-V ISA is tiny, it only really has a handful of integer insns. So as long as you're OK with RISC-V's choices wrt. basic principles such as insn length (32-bit, extensible) and number of general-purpose registers (you get to choose 16 or 32) there's almost no reason not to build on that work. Literally everything else is up for grabs, and could become a new standard extension if the argument for it is strong enough. That leaves out special-case approaches like VLIW with a higher insn length and more integer registers (also VLIWish things like "The Mill") but these are rare.

Completely right.

There is very little room to complain about what RISC-V does have, in RV32I/RV64I or even RV32G/RV64G. The core ISA works just fine and its primary attribute is that everyone is legally free to use and build on it, and that there is a large and growing body of software that runs on it.

The complaints are about things it doesn't have. No carry bit. No complex addressing modes. That kind of thing. If someone proves that those actually matter, for example by building a CPU with custom instructions that blows away everyone else's, then those can be added to RISC-V. There should never be any reason to need a "RISC-VI".

I'm actually quite sympathetic to Qualcomm's proposal to add some of the things Aarch64 has, as an optional but standardised extension. On the other hand I'm completely against the second part of their proposal, to do a "big bang" replacement of the C extension with their extension in e.g. the RVA23 profile.

Well there is the chance that you might not want to advertise your processor as supporting "RISC-V" if it means that someone else's extensions are not the same as yours.

Custom extensions go into custom space.

RISC-V cares about its trademarks; a non-compliant core would not be allowed to use them.

That's not what I mean. I'm saying that if someone makes a program that uses custom extensions, they might label it as "RISC-V" but it doesn't actually work on my machine. Of course other ISAs also have extensions, but they are standard and programs typically check for them before using them. Does RISC-V have a way of looking for which extensions are available? Especially if there are a lot of entities that can implement them?

The ISA spec does indeed have a sane, easy to understand method.

The rest is a software problem. I know that e.g. Linux exposes the required information about the CPU's ISA via a dedicated syscall.

I do not know whether there's some ELF header or the like.

It does? Isn't it read the device tree isa string, the csr bits for the most common things, or catch the trap on illegal instruction?

I think that companies will continue to suggest a "big bang" that involves supporting integer instructions with three source operands and possibly dropping compressed instructions.

Maybe it's out of selfishness (e.g. because they are repurposing an existing microarchitecture for RISC-V), or maybe it's because that's how they want to build their hardware (e.g. for their particular performance target decoding a plain-old 32-bit instruction may be more silicon/power efficient than to fuse 2-3 16-bit instructions).

Whatever the reasons, I think that RISC-V will have to live with this critique for as long as it lives.

I'm not saying that those are poor design choices, but they will always be pain points (for small cores and big cores alike - but for different reasons).

I don't think that you should underestimate the drive to modify an architecture if it does not fit your needs - especially if it is a free and open architecture like RISC-V. For example LoongArch has already happened, and I can easily see how something similar can happen if a major player decides to move from x86 or ARM to "something else" (e.g. if NVIDIA wants full control over their next gen super AI solution).

>(e.g. because they are repurposing an existing microarchitecture for RISC-V)

I don't think we'll see a repeat of Qualcomm's attempt. This was a very special situation that they ended up with the NUVIA purchase/ARM lawsuit fiasco.

Fortunately, RISC-V foundation handled the situation well. As RISC-V continues to grow exponentially, an unlikely later attempt will meet even stronger resistance, not just from the set precedent, but from the larger already deployed ecosystem of software and hardware.

Yes, but that's a big "if". When you start looking at it from the perspective "I don't need binary compatibility with microcontrollers", you realize that opcode space has been wasted on things that you don't need. It's similar to how x86 has wasted several single-byte encodings on instructions that are never used in modern programs. The extensions that you end up wanting to do overlap with the base ISA, but with slightly different semantics.

It's manageable and you can live with it, but already from the start you have an unnecessary legacy that needs to be handled.

If there is enough consensus in the industry, a new revision may be the best way forward.

Reply on news.ycombinator.com