RISC-V Board of Directors decision on the Compressed extension
lists.riscv.org
lists.riscv.org
The working group was about to collect data that could've been interesting, but the time this could/would take was undetermined. It would've also been questionable because all parties that could do the measurements (IP vendors) are biased.
The Samsung talk about Zc on the risc-v summit was also supposed to show performance improvements for the Zc side. We'll probably get the YouTube upload at the end of the month.
There is still space for a seperate profile without 16 bit instructions, so we'll have to see how that develops.
To be clear: RISC-V does also support instructions above 32bit. This was stressed during the discussion.
Qualcomm's focus in the discussion seemed to be to have RVA23 be a fixed size ISA. They failed to convince the board, as the ISA's variable size was designed to be very easy for a hardware decoder implementation to deal with, unlike m68k or x86.
To provide some practical real world RISC-V hardware examples, SiFive P870 is 6-wide, Tenstorrent Ascalon is 8-wide, Ventana Veyron V2 seems to be 12-wide.
Whereas modern x86 microarchitectures seem to be 4-wide and struggling to break into 6-wide, while the largest ARM aarch64 (which is fixed 32bit size) microarchitectures, Apple's M1/M2/M3, are 8-wide.
A17/M3 is 9 wide [https://files.catbox.moe/vkbop7.png]
From what I've heard, Veyron V2 has only 4 wide rename.
I understand Zen2 (and thus 3) are also 4-wide.
I do not know about Intel's designs.
Has Apple officially published these details about M3?
0. https://en.wikichip.org/wiki/amd/microarchitectures/zen_4
Apple don't publish much details of the core - most of what we know is intuited from benchmarking.
Yes, but decode is what we're talking about.
uOp cache is clever, but as any cache it is costly (power, area) and necessary only because x86 decode is very hard.
You can argue about the cost of the uOp cache being expensive, but it's disingenuous to ignore it.
Yes, modern x86 are wide from the uop cache, but this cache is made of simple, easy to process uop and not native instructions. The native part is still "only" 4 wide. The whole existence of the uop cache is to avoid repetitive native instructions decoding and replace it by dealing with simple uop. That's because this native x86 decoding is expensive and hard to widen, which is exactly GP's point.
You're saying the uop cache makes this a non issue in practice: maybe (cost/efficiency of this cache vs a simpler design? I don't know ;), but that was not the point GP was discussing. The point was only that the C extension is easy to decode, with as practical proof the width of existing implementations supporting it.
Qualcomm’s other proposal to add a standard extension with more complex (Aarch64-like) instructions to the ISA should be a totally independent question.
There is plenty of room for it in the ISA, people can choose to implement it or not, and if more than one vendor wants such an extension then it makes sense to standardize it.
ISA is one thing. Providing alternative extensions that implementors can choose between according to their needs is a good thing.
Profiles — that is a set of extensions for a particular application space, which vendors must implement and shrink-wrapped software can depend on — is a totally different thing, which MUST have strong backward compatibility guarantees.
The right decision has been made concerning the RVA* profile series.
I hope this doesn’t preclude discussion regarding a standard extension to the ISA.
Unexpectedly the Board of Directors stepped in to make this decision yesterday. This doesn't preclude another profile (eg. "high end servers") being created in future.
Uh no.
Let's set the record straight: It was proposed by Qualcomm, and only Qualcomm presented a case against C, which was quickly and thoroughly shot down by SiFive[0].
During the discussion, it became apparent that Qualcomm was only having issues because they tried to swap the frontend of the ARM core they got from Nuvia with the minimal amount of effort.
This end result shows that RISC-V Board is strong and won't be easily derailed by one of its member companies.
0. https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
Yes, I saw this rumor too.
Rivos actually appeared in the conversation to basically give the polite equivalent of "don't put words in our mouth".
It turned out, the rumor was made up.
Doubly so right that the effort to remove RV-C failed then.
As fact?
Certainly I've seen (and repeated) speculation that this might be the case.