logoalt Hacker News

phiretoday at 6:28 AM1 replyview on HN

But imagine the code density you could get combining both strategies.

> Arm uses complex instructions with multiple writeback, that require cracking, to improve code density.

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.

They do crack other instructions.

But the cracking seems to be more about ALU limitations (aarch64 has instructions that can do both a shift of any width and an add, but the ALUs might not support this, or only support smaller shifts of 1-3 bits (useful for addressing)

What this means is that despite the cracking, each μop in an aarch64 core is quite a bit more powerful than a typical RISC-V instruction (especially compressed instructions).

So to be competitive on backend performance, a high performance RISC-V is going to spend a lot of resources post-decode doing massive amounts of instruction fusion to try to get μops of similar capabilities to aarch64 (or just settle for simpler μops, and pay scheduling costs of more μops)

So the costs of the RISC-V compressed instruction approach aren’t just limited to pre-decode.


Replies

camel-cdrtoday at 6:57 AM

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

show 1 reply