By: Linus Torvalds (torvalds.delete@this.linux-foundation.org),
Room: Moderated Discussions
Adrian (a.delete@this.acm.org) on August 20, 2021 1:00 pm wrote:
>
> So I expect that increasing the number of fetched instruction bytes per cycle from 16 to 32 bytes
> would allow the decoding of 4 instructions per cycle in any circumstances, which will increase the
> average number of decoded instructions per cycle from maybe a little above 3 to 4, at least for the
> cycles when the instruction fetching is not delayed by mispredicted branches or cache misses.
..or affected by any of the instructions that want that first special decoder that Intel traditionally had.
Some of them are quite simple and common instructions. Things like "call" instructions, but also anything that has two immediates (ie compare immediate with memory operand with an offset - the uops can at least historically only contain one immediate value, and the address offset counts as one).
And the wider the decoder is, the more noticeable these secondary kind of "oh, have to decode in the first decoder" issues will be too.
That said, considering the fairly big change to the decoder, it may well be that Intel has changed their decoding rules in other ways, and hopefully that first decoder isn't as special any more.
Fingers crossed.
Linus
>
> So I expect that increasing the number of fetched instruction bytes per cycle from 16 to 32 bytes
> would allow the decoding of 4 instructions per cycle in any circumstances, which will increase the
> average number of decoded instructions per cycle from maybe a little above 3 to 4, at least for the
> cycles when the instruction fetching is not delayed by mispredicted branches or cache misses.
..or affected by any of the instructions that want that first special decoder that Intel traditionally had.
Some of them are quite simple and common instructions. Things like "call" instructions, but also anything that has two immediates (ie compare immediate with memory operand with an offset - the uops can at least historically only contain one immediate value, and the address offset counts as one).
And the wider the decoder is, the more noticeable these secondary kind of "oh, have to decode in the first decoder" issues will be too.
That said, considering the fairly big change to the decoder, it may well be that Intel has changed their decoding rules in other ways, and hopefully that first decoder isn't as special any more.
Fingers crossed.
Linus
