[brucehoult]

Qualcomm have a Plan B.

This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia.

At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite.

The proposed extension was actually not bad, and could very reasonably be adopted.

Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years.

So they'd have to support both "C" and its replacement anyway.

Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.

[eqvinox]

> Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question.

For general purpose Linux, I agree. But if someone makes Android devices and maintains that for RISC-V… that's basically a closed, malleable ecosystem where you can just say "f it, set this compiler option everywhere".

But also, yes, another commenter pointed out C brings some power savings, which you'd presumably want on your Android device…

[brucehoult]

Qualcomm can do whatever they want with CPUs for Android. I don't care. They only have to convince Google.

But what they wanted to do was strip the "C" extension out of the RVA23 profile, which is (will be) used for Linux too, as a compatible successor to RVA22 and RVA20, both of which include the "C" extension.

If Qualcomm wants to sponsor a different, new, profile series ... RVQ23, say ... for Android then I don't have a problem with that. Or they can just go ahead and do it themselves, without RISC-V International involvement.

[brucehoult]

Qualcomm can do whatever they want with CPUs for Android. I don't care. They only have to convince Google.

But what they wanted to do was strip the "C" extension out of the RVA23 profile, which is (will be) used for Linux too, as a compatible successor to RVA22 and RVA20, both of which include the "C" extension.

If Qualcomm wants to sponsor a different, new, profile series ... RVQ23, say ... for Android then I don't have a problem with that. Or they can just go ahead and do it themselves, without RISC-V International involvement.

[wmf]

Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question.

Android was never really Linux though.

[refulgentis]

This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago

[snvzz]

>Support _reversed_ for it, got pulled 5 months ago

Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.

[refulgentis]

If you trust PR (I don't, and I worked on Android for 7 years until a year ago) - this is a nitpick 5 levels down -- regardless of how you weigh it, there is no Android RISC-V

[weebull]

Dropping the compressed instructions is also a performance / power issue. That matters to mobile.

[eggsome]

What do you mean by Plan B? From what you've just said it sounds like their proposal was rejected, so there is no plan b now?

[brucehoult]

They can roll their sleeves up and do the small amount of work that they tried to persuade everyone else was not necessary. And I'm sure they will have done so.

It's not that hard to design a wide decoder that can decode mixed 2-byte and 4-byte instructions from a buffer of 32 or 64 bytes in a clock cycle. I've come up with the basic schema for it and written about it here and on Reddit a number of times. Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.

Not that anyone is going that wide at the moment. SiFive's P870 fetched 36 bytes/cycle from L1 icache, but decodes a maximum of 6 instructions from it. Ventana's Veyron v2 decodes 16 bytes per clock cycle into 4-8 instructions (average about 6 on random code).

[cesarb]

> Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.

For those who haven't read the details of the RISC-V ISA: the first two bits of every instruction tell the decoder whether it's a 16-bit or a 32-bit instruction. It's always in that same fixed place, there's no need to look at any other bit in the instruction. Decoding the length of a x86-64 instruction is much more complicated.

[Narishma]

Why do they use two bits for it? Do they plan to support other instruction lengths in the future?

[brucehoult]

So that there are 48k combinations available for 2-byte instructions and 1 billion for 4-byte (or longer) instructions. Using just 1 bit to choose would mean 32k 2-byte instructions and 2 billion 4-byte instructions.

Note that ARMv7 uses a similar scheme with two instruction lengths, but using The first 4 bits from each 2-byte parcel to determine the instruction length. It's quite complex, but the end result is 7/8 (56k) 2-byte instructions are possible and 1/8 (512 million) 4-byte instructions.

IBM 360 in 1964 thru Z-System today also uses a 2-bit scheme to choose between 2-byte instructions with 00 meaning 2-bytes (16k instructions available), 01 or 10 meaning 4-bytes (2 billion instructions available), and 11 meaning 6-bytes (64 terra instructions available).

[cesarb]

> Why do they use two bits for it?

To increase the number of 16-bit instructions. Of the four possible combinations of these two bits, one indicates a 32-bit or longer instruction, while the other three are used for 16-bit instructions.

> Do they plan to support other instruction lengths in the future?

They do. Of the eight possible combinations for the next three bits after these two, one of them indicates that the instruction is longer than 32 bits. But processors which do not know any instruction longer than 32 bits do not need to care about that; these longer instructions can be naturally treated as if they were an unknown 32-bit instruction.