The decoder decodes them into two or more internal instructions (uops).
Take for example a post increment load, which does a=mem[b++], notice how this writes to two registers.
Handeling two writes (up to 4) would explode the stage after decode (rename).
So high performance arm implementations generate two uops for this.
But since the number of decoders is fixed and the number of rename slots as well, you now have alnost the same problem as in RISC-V with compressed instructions: the nth input to the rename stage can come from a variaty of outputs of the decode stage, so you need a large shuffle network, and propagate the uop counts from start to end.
Cracking is a lot cheaper, if you can do it later in the pipeline. E.g. the cheapest is if you can simply "replay" the instruction. That is, instead of removing the entry from the issue queue, when it starts executing, you decrement a counter and keep the entry to do something else next.
But as I mentioned that doesn't really work with multiple write back.
The decoder decodes them into two or more internal instructions (uops).
Take for example a post increment load, which does a=mem[b++], notice how this writes to two registers. Handeling two writes (up to 4) would explode the stage after decode (rename). So high performance arm implementations generate two uops for this. But since the number of decoders is fixed and the number of rename slots as well, you now have alnost the same problem as in RISC-V with compressed instructions: the nth input to the rename stage can come from a variaty of outputs of the decode stage, so you need a large shuffle network, and propagate the uop counts from start to end.
Cracking is a lot cheaper, if you can do it later in the pipeline. E.g. the cheapest is if you can simply "replay" the instruction. That is, instead of removing the entry from the issue queue, when it starts executing, you decrement a counter and keep the entry to do something else next. But as I mentioned that doesn't really work with multiple write back.
A lot of CPUs does not execute instructions directly, but instead translate them into a second set of "uOps"
This allows it to split complex instructions into multiple operations instead of having dedicated hardware for it.
High performance cores can also do the opposite trick of "fusing" two instructions into a single uOp: The usual example is compare-and-branch