[Pet_Ant]

> They are going to split the RISC V ecosystem.

Part of the DNA of RISC-V is to provide a basis from which a million flowers can bloom. Instead of homebrewing, you can reuse RISC-V and make tweaks as you need... if you really do need a custom variant. Think of it as English, a common substratum from which there are lots of mostly interoperable dialects. This is what happened with Unix.

Now if we want a mainstream consumer then we will need a dominant strain or two. The RISC-V foundation is doing that with the RVA23 profiles etc, but if there is a few major ones that should be navigable. Linux had support for PC-98[1] which was a Japanese alternate x86 platform.

The changes I've seen proposed by Qualcomm don't seem drastically different [2], and could be incorporated in the same binaries with sniffing the supported features. The semantics are what are important, and it's not different there at all. Could be supported with trap and emulate

[1] https://en.wikipedia.org/wiki/PC-98 [2] https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...

[Tuna-Fish]

The code size reduction instructions are an extension that will go through and will eventually be supported by everyone, and is not the bone of contention here. They are designed to be "brown-field" instructions, that is, fit into the unimplemented holes in the current spec.

The reason the spec is going to split is not them, but the fact that Qualcomm also wants to remove the C extension, and put something else in the encoding space it frees.

[Pet_Ant]

Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now.

That said, if they implemented C, and then had their replacement toggleable with a CSR that would still be backwards (albeit not forwards) compatible so that'd only be an issue if Qualcomm RISC-V binaries become dominant, but I don't think binaries are gonna be that dominant outside of firmware going forward, and any that are will be from vendors that will multi-target.

[phkahler]

>> Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now.

It may be low cost to decode a compressed instruction, but having them means regular 32-bit instructions can cross cache lines and page boundaries.

My own thought is that there should be a "next" version or RISC-VI that is mostly assembler-level compatible but changes all the instruction encodings to be more sane. What that means exactly is still a bit fuzzy, but I am a fan of immediate data being stored after the opcode.

[Pet_Ant]

> My own thought is that there should be a "next" version or RISC-VI that is mostly assembler-level compatible but changes all the instruction encodings to be more sane.

I feel like that is really a case of Chesterton's fence. It was done by people who litterally wrote the book on processor design (David Patterson, author of "Computer Architecture: A Quantitative Approach", "The Case for RISC", "A Case for RAID", ). I have heard a talk with the rationale behind where bits are placed to simplify low-end implementations.

> What that means exactly is still a bit fuzzy, but I am a fan of immediate data being stored after the opcode.

As a hobbyist, I get it... but except for when you are reading binary dumps directly, which happens so rarely these days, when is that ever relevant? That is just OCD. I think of this video when I get the same itch and temptation. https://www.youtube.com/watch?v=GPcIrNnsruc

Also, let's not forget that RISC-V is already a thing with millions of embedded units already shipped.

[phkahler]

>> I feel like that is really a case of Chesterton's fence. It was done by people who litterally wrote the book on processor design

It was originally intended for use in education where students could design their own processors and fixed instruction sizes made that easier. I'm not saying "therefore it's suboptimal", just that there were objectives that might conflict with an optimal design.

>> > What that means exactly is still a bit fuzzy, but I am a fan of immediate data being stored after the opcode.

>> As a hobbyist, I get it... but except for when you are reading binary dumps directly, which happens so rarely these days, when is that ever relevant?

How about in a linker, where addresses have to be filled in by automated tools? Sure, once the weirdness is dealt with in code its "done" but it's still an unnecessarily complex operation. Also IIRC there is no way to encode a 64bit constant, it has to be read from memory.

Maybe I'm wrong, maybe it's a near optimal instruction encoding. I'd like to see some people try. Oh, and Qualcomm seems to disagree with it but for reasons that may not be as important as they think (I'm not qualified to say).

[Pet_Ant]

> Also IIRC there is no way to encode a 64bit constant, it has to be read from memory.

There never is, you can never set a constant as wide as the word length. Instead you must "build" it. You can either load the high bits as low, shift the value, and then add the low bits, or sometimes as Sparc has it ('sethi'), there is an instruction that combines the two for you.

https://en.wikibooks.org/wiki/SPARC_Assembly/Control_Flow#Ju...

https://en.wikipedia.org/wiki/SPARC#Large_constants

[brucehoult]

> millions of embedded units already shipped

10+ billion. With billions added every year.

THead says they've shipped several billion C906 and C910 cores, and those are 64 bit Linux applications cores, almost all of them with draft 0.7.1 of the Vector extension. The number of 32 bit microcontroller cores will be far higher (as it is with Arm).

[__s]

yes, was curious why compression format didn't require

1. non compressed instructions are always 4 byte aligned (pad a 2 byte NOP if necessary, or use uncompressed 4 byte instruction to fix sizing)

2. jump targets are always 4 byte aligned (which exists without C, but C relaxes)

This avoids cache line issues & avoids jumps landing inside an instruction. Can consider each 2 compressed instructions as a single 4 byte instruction

Bit redundant to encode C prefix twice, so there's room to make use of that (take up less encoding space at least by having prefix be 2x as long), but not important

[fwsgonzo]

I completely agree. Not that everything has to be relaxed, but at least the things that made it impossible to decode RISC-V when C is enabled. The amount of code needed to detect when and how instructions are laid out is much larger than it should be.

[brucehoult]

"impossible"?

It's a little easier than ARMv7, and orders of magnitude easier than x86, which doesn't seem to be preventing high performance x86 CPUs (at an energy use and surely silicon size penalty admittedly).

Everyone else in the RISC-V community except Qualcomm thinks the "C" extension is a good trade-off, and the reason Qualcomm don't is very likely because they're adapting Nuvia's Arm core to run RISC-V code instead, and of course that was designed for 4-byte instructions only.

[Pet_Ant]

That is a trade-off towards density that seems not worth it where all it would take is a 16 bit NOP to pad and a few more bytes of memory to save on transistors of implementation.

Maybe they did the actual math and figured it's still cheaper? Might be worth it.

[__s]

SiFive slides: https://s3-us-west-1.amazonaws.com/groupsioattachments/10389...

Their argument is that since eventually there'll be 8 byte instructions, those will have the same cache line issues (tho that could be addressed by requiring 8 byte instructions be 8 byte aligned)

[panick21_]

C is good for high performance instruction sets to. Funny how every company that starts with green field RISC-V doesn't ever mention it as a problem. And yet the one company who wants to leverage their ARM investment thinks its a huge problem that will literally break the currently established standard.