One of the most fundamental instructions of x86, the Jcc conditional jump, can apparently be executed incorrectly by most Intel CPUs out there.
What's worse, part of Intel's strategy for mitigation is to push compiler toolchain changes that, if deployed as they desire, will punish the performance of everybody on x86, including those who are using unaffected processors (cough AMD cough).
I'm assuming it will get resolved, as the errata suggests by shoving lots of 0x2c segment overrides to re-align those jumps.
The price won't be 0, but will definitely less than the very extreme 20% edge case I stumbled upon.
I'm more "worried" or annoyed by older binaries that will never get updated. But hey... (；⌣̀_⌣́)
> The MCU prevents jump instructions from being cached in the Decoded ICache when the jump instructions cross a 32-byte boundary or when they end on a 32-byte boundary. In this context, Jump Instructions include all jumptypes: conditional jump (Jcc), macro-fusedop-Jcc(where opis one ofcmp, test, add, sub, and, inc, ordec), direct unconditional jump, indirect jump, direct/indirect call, and return
These patches are just to recover some of the performance penalty...
A more recent Phoronix article ("Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD", https://www.phoronix.com/scan.php?page=news_item&px=AMD-With...) says otherwise.
Unfortunately, IA-64 is already taken for the itanium architecture. That's why the Intel Software Developer Manual names it IA32-E and not IA64. IA32 is x86, IA32-E is x86 Extended, or x86_64.
Thanks intel, I guess.
And like this Intel errata, it's instruction-address-dependent: one of the conditions to trigger it is when the relevant instruction is near the end of a 4K page. One workaround being "put the instruction somewhere else".
The initial reports and secrecy around the Intel issue makes it sound like they need to be mitigating all the time in normal modes.. But I guess it will take some time to see what is really going on.