> While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions.
No, every high performance core I know of cracks them at decode, some re-fuse some of them after rename (Apple). Because otherwise you would need to rename up to 4 destinations per rename slot, effectively 4xing your already limiting rename stage.
Cracking other stuff later in the pipeline isn't expensive.
Really? Interesting.
Though, I guess fusing after cracking makes things easier because you don't actually have to search for fusion candidates (supported by the fact that Apple's Firestorm doesn't seem to make any effort to fuse things that aren't alu + branch, crypto, or amx)
Edit: removed
Yeah, fusing is probably easier, if you already know what to fuse. On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage, if fusion haopens after rename as well.
> On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage
That's a good point.
If some RISC-V μarch was going to invest the extra gates for a complex fusion setup, the search isn't actually going to slow anything down, as it can run in parallel with other frontend operations (like renaming).
I always just assumed fusion was done as early as possible, only considering instructions that are right next to each-other (that's certainly the intent of the RISC-V spec), and then resolved immediately after decode.
But maybe it's better to do it right at the end of the front end; After renaming, during insertion into the scheduler.
You shouldn't be sharing that.
Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other than optimising software for apple devices.
Discussing the design tradeoffs of RISC-V μarches couldn't be further from "optimising software for apple's devices".
> You shouldn't be sharing that
Ah, I suppose.