Post #2409972

2025-09-09 05:41 UTC

@JamesWidman@mastodon.social The key point being that it definitely easily scales to 9-wide (I mean, the product has been on shelves for a year) and probably much further, lets you stack 3-wide decoders (which are at a reasonably sweet spot for x86) and doesn't have any scary super-linear stuff (that I can tell) on the branch pred/fetch/merge sides either. Might hit a wall at some point, but a reasonable (and low-power!) way to get to at least 15-wide decode or so is a lot of runway.

Replies (3)

@camelcdr@tech.lgbt 2025-09-09 17:12

@rygorous@mastodon.gamedev.place @JamesWidman@mastodon.social You have to decouple the decoders or do more fancy things in the icache once you are that wide anyways. The average instructions/taken branch integer workloads is 10-15 and that's (presumably) the good case. https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf

Open ##2409973
@wren6991@types.pl 2025-09-09 19:13

@rygorous@mastodon.gamedev.place @JamesWidman@mastodon.social How does the clustered decoder stuff actually get more parallelism for single-threaded execution? Are they getting the offsets of the three-instruction bundles from the BTB? Decoding the instruction boundaries on cache fill? Maybe just having the decoder clusters work on different basic blocks from different links in the prediction chain so that they're not dependent on each other's length decode? I've never found any useful details on this online

Open ##2409975
@unnick@booping.synth.download 2025-09-09 21:55

@rygorous@mastodon.gamedev.place @JamesWidman@mastodon.social why do the big x86 cores not do this (yet)? is it because uop caching is good enough for those?

Open ##2409983