Hacker News Reader

Comment by camel-cdr | Hacker News Reader

Great to see this finally resolved.

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.

View on HN

>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.

Modern x86 (Golden Cove, Zen 3/4) is currently 6 wide. [https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021...]

A17/M3 is 9 wide [https://files.catbox.moe/vkbop7.png]

From what I've heard, Veyron V2 has only 4 wide rename.

Zen4 is 4-wide[0].

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

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.

>Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large).

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.

It's counter-intuitive to think that way. Modern x86 is designed to primarily operate out of the uOp cache.

You can argue about the cost of the uOp cache being expensive, but it's disingenuous to ignore it.

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.

Reply on news.ycombinator.com