5 ms·

> The x86 ISA really is a mess! 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

by acqq 7y ago

> The x86 ISA really is a mess! 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.

Dylan16807 7y ago
I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess. 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.
- pcwalton 7y ago
  > I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess. Or heck, even just the fact that real mode is still a thing.
  - dfox 7y ago
    The CPU contains essentially no hardware that is there only to support real mode, which is simply an documented combination of configurations of various protected mode relevant mechanism plus changed behavior of exactly one microarchitectural operation, which involves replacing bunch of nontrivial microcoded logic with simple 4 bit left shift.
    - bonzini 7y ago
      There is hardware that is there only to support v86-mode and v86 mode extensions though. V86 mode really really should go away...
      - dfox 7y ago
        In fact there isn't any hardware to speak of (3 bits worth of architectural registers and bunch of trivial logic related to that?) to support vm86 mode, and that is to some extent the consequence of how true real mode is implemented. The combination of paging enabled (which is not strictly necessary), protected mode enabled, 16b code segment and real mode style segment loads gets you vm86 mode (complete with weird stuff on stack of exception handler vectors), in fact when you look at vm86 entry gate descriptor, this is exactly what it does. The microarchitecture essentially does not care about that. 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.
    - PopePompus 7y ago
      But it's not just a matter of wasting transistors and silicon. The ancient x86 modes are like old legacy code in a software package you have to maintain. They add complexity. Intel hasn't exactly been cranking out an endless series of bug-free chips lately. It might behoove them to make a line of chips which are pure x86-64.
      - tedunangst 7y ago
        How many of the recent intel vulnerabilities would have been prevented by jettisoning real mode?
    - bogomipz 7y ago
      Could you elaborate on this a little more? What exactly is "the changed behavior of exactly one microarchitectural operation"? Which operation?
  - skissane 7y ago
    It is still a useful feature for people who want (or need) to run legacy apps or OS versions under virtualisation (VirtualBox etc). Forcing that use case to use CPU emulation would have a performance cost. 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.
    - pcwalton 7y ago
      How many people need to run DOS apps at 2020 processor speeds? I get that there are legacy systems at banks and power plants running DOS, but practically by definition they don't need 2020 speeds.
      - skissane 7y ago
        It’s not just DOS apps. Booting any OS using legacy BIOS boot (as opposed to EFI) needs real mode support, even if it never uses real mode again after the boot process completes. (Theoretically, you might be able to build a hypervisor which uses CPU emulation for real mode and hardware-based virtualisation in protected mode, but no such thing exists yet.) So if someone has a legacy app running in a Windows XP/Vista/2003/etc VM, that VM needs real mode to boot.
- acqq 7y ago
  The point is, it didn't matter as people wrote assembly by hand, and it doesn't matter now when everybody is using compilers. The opcode details are trivially solved by the tables, the know-how of those who programmed assembly was enough for most of the times they programmed, compilers can handle a lot, and the real problems that really have to be solved are simply not dependent on these issues at all. 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.
  - Dylan16807 7y ago
    "It doesn't matter" (much) that it's a mess is one thing. "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.
pcwalton 7y ago
It's not my contention that RISC designs are necessarily faster/more power efficient/etc. It's just that the x86 design is, from an engineering perspective, a mess. > 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.
- fmakunbound 7y ago
  > from an engineering perspective It's pretty awesome. Remember engineering doesn't happen in a void. It's influenced all sorts of shit including economics, existing investments etc.
- blattimwind 7y ago
  From an engineering perspective it is hugely impressive that a 2020 AMD or Intel chip can run an x86 app compiled in '92 at something like 100 times the speed.
  - mumblemumble 7y ago
    From an engineering perspective, these two assertions that have been prefixed with the qualifier, "from an engineering perspective," are entirely compatible.
  - lallysingh 7y ago
    28 years later, the speedup on their selected representation is 100x? That seems low for such a long time.
bsder 7y ago
The x86 architecture is a mess and it matters. The reason it matters is because a disproportionate amount of energy is spent in the instruction decode system. And that affects your battery life.
- dbcurtis 7y ago
  Yes. Precisely. As ex-Intel, I confirm all of your points. 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.
  - api 7y ago
    How messy is AARCH64 compared to X64? I imagine it's less, but ARM's been around for a while too hasn't it?
    - saagarjha 7y ago
      Much less, but it’s starting to get some uglier stuff in it. Since it doesn’t need to be backwards compatible the task of keeping it reasonable is much easier.
  - wtmt 7y ago
    > 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. I think Itanium, or the pursuit of making Itanium the replacement for x86, demonstrated these quite well.

by acqq 7y ago

Dylan16807 7y ago

I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess. 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.

pcwalton 7y ago
> I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess. Or heck, even just the fact that real mode is still a thing.
- dfox 7y ago
  The CPU contains essentially no hardware that is there only to support real mode, which is simply an documented combination of configurations of various protected mode relevant mechanism plus changed behavior of exactly one microarchitectural operation, which involves replacing bunch of nontrivial microcoded logic with simple 4 bit left shift.
  - bonzini 7y ago
    There is hardware that is there only to support v86-mode and v86 mode extensions though. V86 mode really really should go away...
    - dfox 7y ago
      In fact there isn't any hardware to speak of (3 bits worth of architectural registers and bunch of trivial logic related to that?) to support vm86 mode, and that is to some extent the consequence of how true real mode is implemented. The combination of paging enabled (which is not strictly necessary), protected mode enabled, 16b code segment and real mode style segment loads gets you vm86 mode (complete with weird stuff on stack of exception handler vectors), in fact when you look at vm86 entry gate descriptor, this is exactly what it does. The microarchitecture essentially does not care about that. 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.
  - PopePompus 7y ago
    But it's not just a matter of wasting transistors and silicon. The ancient x86 modes are like old legacy code in a software package you have to maintain. They add complexity. Intel hasn't exactly been cranking out an endless series of bug-free chips lately. It might behoove them to make a line of chips which are pure x86-64.
    - tedunangst 7y ago
      How many of the recent intel vulnerabilities would have been prevented by jettisoning real mode?
  - bogomipz 7y ago
    Could you elaborate on this a little more? What exactly is "the changed behavior of exactly one microarchitectural operation"? Which operation?
- skissane 7y ago
  It is still a useful feature for people who want (or need) to run legacy apps or OS versions under virtualisation (VirtualBox etc). Forcing that use case to use CPU emulation would have a performance cost. 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.
  - pcwalton 7y ago
    How many people need to run DOS apps at 2020 processor speeds? I get that there are legacy systems at banks and power plants running DOS, but practically by definition they don't need 2020 speeds.
    - skissane 7y ago
      It’s not just DOS apps. Booting any OS using legacy BIOS boot (as opposed to EFI) needs real mode support, even if it never uses real mode again after the boot process completes. (Theoretically, you might be able to build a hypervisor which uses CPU emulation for real mode and hardware-based virtualisation in protected mode, but no such thing exists yet.) So if someone has a legacy app running in a Windows XP/Vista/2003/etc VM, that VM needs real mode to boot.
acqq 7y ago
The point is, it didn't matter as people wrote assembly by hand, and it doesn't matter now when everybody is using compilers. The opcode details are trivially solved by the tables, the know-how of those who programmed assembly was enough for most of the times they programmed, compilers can handle a lot, and the real problems that really have to be solved are simply not dependent on these issues at all. 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.
- Dylan16807 7y ago
  "It doesn't matter" (much) that it's a mess is one thing. "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.

pcwalton 7y ago

It's not my contention that RISC designs are necessarily faster/more power efficient/etc. It's just that the x86 design is, from an engineering perspective, a mess. > 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.

fmakunbound 7y ago
> from an engineering perspective It's pretty awesome. Remember engineering doesn't happen in a void. It's influenced all sorts of shit including economics, existing investments etc.
blattimwind 7y ago
From an engineering perspective it is hugely impressive that a 2020 AMD or Intel chip can run an x86 app compiled in '92 at something like 100 times the speed.
- mumblemumble 7y ago
  From an engineering perspective, these two assertions that have been prefixed with the qualifier, "from an engineering perspective," are entirely compatible.
- lallysingh 7y ago
  28 years later, the speedup on their selected representation is 100x? That seems low for such a long time.

bsder 7y ago

The x86 architecture is a mess and it matters. The reason it matters is because a disproportionate amount of energy is spent in the instruction decode system. And that affects your battery life.

dbcurtis 7y ago
Yes. Precisely. As ex-Intel, I confirm all of your points. 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.
- api 7y ago
  How messy is AARCH64 compared to X64? I imagine it's less, but ARM's been around for a while too hasn't it?
  - saagarjha 7y ago
    Much less, but it’s starting to get some uglier stuff in it. Since it doesn’t need to be backwards compatible the task of keeping it reasonable is much easier.
- wtmt 7y ago
  > 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. I think Itanium, or the pursuit of making Itanium the replacement for x86, demonstrated these quite well.