2 ms·
No, the legacy decoder is virtually unused. This loop was designed to take advantage of the rules of the DSB. OK, think I see now. The DSB path is only able t
by nkurz 9y ago
No, the legacy decoder is virtually unused. This loop was designed to take advantage of the rules of the DSB.
OK, think I see now. The DSB path is only able to inject one "way" per cycle, and through NOP padding you are able to ensure that each "way" only contains a single instruction? While I can find clear descriptions of what can fit in a "way", I haven't found a clear statement of the "one way per cycle" restriction, although it would explain observed behavior.
Practically, it seems like the effect would be the same if one "defeated" the DSB and came up with a similar strategy for causing the legacy MITE to trickle in instructions. The overall goal is to restrict speculative execution of loads and stores in cases where one knows that the speculation is going to fail.
You'd think that there would be an MFENCE/LFENCE/SFENCE way of solving this more directly, but I haven't found it yet. Or maybe just a LOCK? Maybe a creative false dependency to keep the processor from getting to far ahead? Interesting. Thanks for helping explore this.
- pbsd 9y agoI later realized that padding to 32 bytes didn't make much of a difference, it is the number of vacuous NOP opcodes generated that matters. So it can be simplified to mov rcx, 400000000-1 up: nop nop nop add [counter], rcx nop nop nop dec rcx nop nop nop jnz up ret which probably works fine for the majority of decoding methods, be it MITE, LSD, or DSB.