It also answers the question "why don't compilers emit INC and DEC?" Short answer: they don't set the carry, so on some CPUs that means that they cause an unnecessary dependency on the previous instruction that sets EFLAGS.
The x86 ISA really is a mess!
A lot of the information there is a decade out of date.
And neither Clang nor GCC emits inc or dec: https://godbolt.org/z/47y8K3
OK, but what does it even mean that they avoid AL then, if they use them for 8-bit math? Under what other scenarios would they even want to use them?
FWIW, compilers could use 32-bit arithmetic ops almost all the time even when bytes are used in the source, because excect for right shifts and division, information flows only to more significant bits, so 32-bit bit ops give you the right results in the low bits.
In fact, I thought they did this more often – but when I looked into it recently they seem to prefer the low 8 bit registers.
> but they don't use the high bytes.
Not often, but of course the use case for the "second least significant byte" is very narrow in the first place [2]! If you just want to deal with byte values, you'll use the low bytes, after all.
The high 8-bit values are reserved for special cases, e.g., extracting that particular byte, and there compilers do use them (at least gcc, clang and icc on the first try, but not msvc):
The performance characteristics for the high bytes are quite different from the low bytes on modern, x86 too: see [1]!
> And neither Clang nor GCC emits inc or dec
Yes, if you don't set the march they will compile for an archaic blend of chips at least one of which may have the old inc/dec behavior.
Try setting a "modern" march flag like Haswell and fixing the issue where i wasn't actually used except as the loop induction variabale (allowing loop transformations away from simple +1) and both clang and gcc use inc:
---
[1] https://stackoverflow.com/a/45660140/149138
[2] It is possible one of the original motivations for the high bytes was to double the number of 8 byte registers in the 16 bit era. I.e., 8x byte registers was considered significantly better than 4x, and you couldn't use the low byte of di,si,sp and bp for other reasons.
In 64-bit, however, we now have 8 additional registers each with a low byte variant (r8b-r15b), so there are plenty of low byte registers for most work, so the remaining use of the high byte registers mostly seems to be taking advantage of their ability to quickly access the 2nd byte of a larger value.
No, it's not. I've written the compilers for both x86 and x64. One should not look for too much idealistic "symmetry" but look at it as a domain specific encoding language. Behind that encoding is anyway huge machinery that significantly speeds up that what is written in the language, and it's even proven that, when there is enough silicon, it is of advantage that some optimizations are actually done during the execution. Some execution statistics are simply dependent on the information which dynamically depends on execution and can't be pre-coded by a compiler.
Since long ago, even those processors that started as RISC got more and more instructions and started to worry about having them encoded with less bits.
And that all doesn't mean that the compilers shouldn't be as smart as possible to use the hardware the best it can be used.
Even ignoring all the annoying mismatches in semantics, all the awkwardly-fit expansions and prefixes do not lead to a good encoding. And it's far slower to figure out how long an instruction is than it should be.
Or heck, even just the fact that real mode is still a thing.
edit: there is no documented direct way to flip the segment/selector bit, which is the reason why you need documented vm86 mode. The hardware always calculate the linear address according to whatever is in shadow descriptor of segment/selector register, difference between real/vm86 and protected mode is what happens when you store something into there.
Although, they could disable real mode support in some CPUs as a market segmentation mechanism. Running a 64-bit OS with EFI boot, most users probably don’t really need real mode support.
So if someone has a legacy app running in a Windows XP/Vista/2003/etc VM, that VM needs real mode to boot.
And diagonally, the instruction set is surely not the reason why every internet page is tracked by thousands of companies and has to download more megabytes than the total RAM the whole x86 computers had.
And like I've said, all instruction sets since a while have to take care to be "compressed" in a way, which is simply a total opposite of what the critics pointed since RISC was introduced. Pure RISC was/is useful only under some very specific assumptions.
The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real.
"It's not a mess" is quite another.
But 'compression' and 'mess' are very very different things. You can have organized compression. Look at the length encoding on RISC-V, or something. No prefix bytes in sight. On x86 the balance and methodology for getting different instruction sizes is completely garbage for historical reasons.
> The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real.
It's because it's been collecting legacy since it was 8-bit all the way to 64-bit with vector units, not as an inevitable result of being successful.
> Since long ago, even those processors that started as RISC got more and more instructions and started to worry about having them encoded with less bits.
x86-64 is not very space efficient, because of all the REX prefixes. Look at the comparative sizes of AArch64 and x86-64 binaries if you don't believe me.
It's pretty awesome. Remember engineering doesn't happen in a void. It's influenced all sorts of shit including economics, existing investments etc.
The reason it matters is because a disproportionate amount of energy is spent in the instruction decode system.
And that affects your battery life.
The “mess”, though, is just a natural artifact of longevity. Many years of decisions that made sense in the moment accumulated to appear to be a “what WERE they thinking?” situation when, in fact, they were addressing the market forces and technology constraints of the day.
In the end, nobody buys your product because the elegant design means that two generations of your product later it will have good performance. Sales are driven by what you can do in the here-and-now. If you do that well enough, you can live long enough to accumulate the kind of cruft that is the X86 ISA.
> In the end, nobody buys your product because the elegant design means that two generations of your product later it will have good performance. Sales are driven by what you can do in the here-and-now. If you do that well enough, you can live long enough to accumulate the kind of cruft that is the X86 ISA.
I think Itanium, or the pursuit of making Itanium the replacement for x86, demonstrated these quite well.
Battery life in benchmarks (and in a lot of real-world use cases) is more about how long the CPU spends in its halted sleep state, and how much power that takes, than its "full throttle" power usage.
Mobile x86 CPUs since Core Duo(?) have the ability to turn off parts of their caches in lower-power modes, for this reason.
[Edit:] I got deja vu, searched my comment history, and found we were still harping on about this exact same crap 9 years ago: https://news.ycombinator.com/item?id=2061500
Even on 32nm, instruction decoding was a tiny % of die space!
Exactly that. Looking what the actual problems with the processors that tried to be better than x86-line were, the good or bad instruction "decoding" was certainly not what made them worse than x86-line, at the end.