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.
>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.
Zen4 has an 8 wide frontend (from uOp cache) but 6 wide rename, making the overall design 6 wide. Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large).
Apple don't publish much details of the core - most of what we know is intuited from benchmarking.
Not really, GP was talking specifically (and exclusively) about the ease of decoding the native ISA.
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.
It was never going to go any other way for the RVA* profiles.
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.
RISC-V Profiles is a technical working group of RISC-V International which decides on a common set of extensions that hardware in particular profiles (eg. application servers) must implement. Recently there has been some rather heated discussion of the Compressed extension. The C extension adds 16 bit instructions, somewhat like Thumb on armv7. Larger server vendors argued that the C extension made it harder to verify implementations and proposed alternatives. Other RVI members argued that dropping C would effectively split the standard (especially if the space used by the C extension was reused for other things).
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.
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.
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.