3 ms·

Compared to most architectures, X86 sucks pretty badly. Thanks to good compilers, though, you don't have to care about the lameness of the instruction set (eg,

by orib 18y ago

Compared to most architectures, X86 sucks pretty badly. Thanks to good compilers, though, you don't have to care about the lameness of the instruction set (eg, there are ambiguities in the encoding that need to be disambiguated by register prefixes, there are lots of subtle and pointless variations in the instructions, etc.) Good software lets you pretend that the instruction set you're using isn't actually complete crap.

tptacek 18y ago
It's definitely the conventional wisdom that X86 is inferior to MIPS, SPARC, and PowerPC, but I rarely see that opinion backed up. There is a lot of legacy crap tacked on to X86 instructions, which X86 CPUs don't actually execute directly. There's also legacy crap built into other instruction sets, like register windows in SPARC, predicated instructions in ARM, and bloated call frames on PowerPC. Can you be more specific about what you don't like about the X86 architecture? (A couple years ago, you'd have an easy win with "the bus").
- orib 18y ago
  Edit: Some people seem to have missed my point; in summary: x86 is ugly (and below is why I think so) but we don't care because compilers enable us to just forget about what ISA we're using. This is a good thing. This is the way it should be. But it's also an example of what the OP was talking about -- bad hardware design (in this case the x86 ISA; the actual hardware is quite good) not mattering because software is sufficiently good Sure. Some of these I'm not 100% sure of, so I hope I don't make myself look too stupid (sorry, don't have access to the docs right now) but here goes: - Too few registers Mostly fixed in x86_64, but still an issue if you want to support 99% of the machines out there still on 32 bits - Overlapping register classes This makes the register allocator's job much more difficult, since not only do registers interfere with other registers which hold the same mode of varible, they sometimes -- but not always -- interfere with other registers of the same class. - Irregular instructions If you use some registers, they're encoded in less bytes than others, so the optimizer/allocator has yet another parameter to take into account. - Fixed registers for integer multiplication/division You're forced to clobber %eax/%edx and one other reg of your choice. This causes more spills than it should, and makes the job of the register allocator harder. - Way too many jump variants I think I counted 63 variants of the instructions, and you can encode the same one multiple times, which gives you hundreds of ways of encoding a jump. - Complicated encoding First, it's a variable length encoding. You can have one, two, or 3 byte instruction opcodes, with various prefixes and suffixes. - Ambiguity in some cases Instructions can sometimes take the same initial byte sequences as a prefix, despite not actually having that prefix switched on; when decoding you have to figure out the rest of the instruction before you decide if you've got a prefix. - Useless Instructions (minor annoyance) x86 has lots (and lots) of instructions that are unused by compilers, are slower than simply doing the smaller instructions that they are composed of, but are still around for compatibility. Sure, it's needed, but do I have to like it? Really, x86 implementations these days are quite good, but the instruction set is not pretty. x86 has more cruft than most other architectures out there. It's certainly not impossible to write a good compiler for it, it's just a whole lot harder, especially when it comes to doing register allocation. (x86 isn't even too painful to write by hand!)
  - gaius 18y ago
    Fortunately (?) the market is large enough that nearly infinite resources can be thrown at the problem of making halfway decent compilers. The cost - that those programmer's time could have been used to advance the state of the art - is unquantified.
  - ajross 18y ago
    I think you're overstating things. Generating x86 output from an intermediate language really isn't that bad. Is it what you would come up with if you were designing an ISA from scratch, but it's hardly rocket science either. More to the point: the real determining factor for "CPU uberness" isn't the ISA at all, it's the process technologies. Modern x86 CPUs aren't exactly handicapped; in fact they're pretty much the best parts you can buy in almost all major market areas. Other architectures at this point are increasingly niche parts: very low power (the ARM family, although Intel is moving into this market as we speak), or very high parallelism (Sun's Niagra, IBM's Cell), etc... If any of the stuff you're complaining about really mattered, it ought to be a competitive advantage to someone, no? But it's verifiably not.
    - orib 18y ago
      I fully agree, but I was asked for why I don't like the x86 architecture, so I gave an answer. Current x86 CPUs are pretty awesome when it comes down to it. the ISA is quite hairy, and that makes writing tools for them quite a bit more painful than for, eg, mips, but because compilers are good you don't feel the pain from using x86 anymore, so nobody cares -- or should care -- that they're actually using x86.
  - tptacek 18y ago
    What an awesome comment! Isn't the (notoriously restrictive) X86 register file a tradeoff, though? Didn't this get PPC in trouble? Every extra register winds up getting represented in the calling conventions. Accessing dwords off the top of the stack is what, a 2 cycle penalty? That's what the spill is costing you, for an instruction sequence that isn't happening all that often. When you say "there are 63 variants of the instructions" --- you mean a plain JMP, right? You're not complaining about how many Jcc variants there are? The X86 instruction set is definitely not pretty, but current X86 hardware does a really excellent job of executing it.

by orib 18y ago

tptacek 18y ago

It's definitely the conventional wisdom that X86 is inferior to MIPS, SPARC, and PowerPC, but I rarely see that opinion backed up. There is a lot of legacy crap tacked on to X86 instructions, which X86 CPUs don't actually execute directly. There's also legacy crap built into other instruction sets, like register windows in SPARC, predicated instructions in ARM, and bloated call frames on PowerPC. Can you be more specific about what you don't like about the X86 architecture? (A couple years ago, you'd have an easy win with "the bus").

orib 18y ago
Edit: Some people seem to have missed my point; in summary: x86 is ugly (and below is why I think so) but we don't care because compilers enable us to just forget about what ISA we're using. This is a good thing. This is the way it should be. But it's also an example of what the OP was talking about -- bad hardware design (in this case the x86 ISA; the actual hardware is quite good) not mattering because software is sufficiently good Sure. Some of these I'm not 100% sure of, so I hope I don't make myself look too stupid (sorry, don't have access to the docs right now) but here goes: - Too few registers Mostly fixed in x86_64, but still an issue if you want to support 99% of the machines out there still on 32 bits - Overlapping register classes This makes the register allocator's job much more difficult, since not only do registers interfere with other registers which hold the same mode of varible, they sometimes -- but not always -- interfere with other registers of the same class. - Irregular instructions If you use some registers, they're encoded in less bytes than others, so the optimizer/allocator has yet another parameter to take into account. - Fixed registers for integer multiplication/division You're forced to clobber %eax/%edx and one other reg of your choice. This causes more spills than it should, and makes the job of the register allocator harder. - Way too many jump variants I think I counted 63 variants of the instructions, and you can encode the same one multiple times, which gives you hundreds of ways of encoding a jump. - Complicated encoding First, it's a variable length encoding. You can have one, two, or 3 byte instruction opcodes, with various prefixes and suffixes. - Ambiguity in some cases Instructions can sometimes take the same initial byte sequences as a prefix, despite not actually having that prefix switched on; when decoding you have to figure out the rest of the instruction before you decide if you've got a prefix. - Useless Instructions (minor annoyance) x86 has lots (and lots) of instructions that are unused by compilers, are slower than simply doing the smaller instructions that they are composed of, but are still around for compatibility. Sure, it's needed, but do I have to like it? Really, x86 implementations these days are quite good, but the instruction set is not pretty. x86 has more cruft than most other architectures out there. It's certainly not impossible to write a good compiler for it, it's just a whole lot harder, especially when it comes to doing register allocation. (x86 isn't even too painful to write by hand!)
- gaius 18y ago
  Fortunately (?) the market is large enough that nearly infinite resources can be thrown at the problem of making halfway decent compilers. The cost - that those programmer's time could have been used to advance the state of the art - is unquantified.
- ajross 18y ago
  I think you're overstating things. Generating x86 output from an intermediate language really isn't that bad. Is it what you would come up with if you were designing an ISA from scratch, but it's hardly rocket science either. More to the point: the real determining factor for "CPU uberness" isn't the ISA at all, it's the process technologies. Modern x86 CPUs aren't exactly handicapped; in fact they're pretty much the best parts you can buy in almost all major market areas. Other architectures at this point are increasingly niche parts: very low power (the ARM family, although Intel is moving into this market as we speak), or very high parallelism (Sun's Niagra, IBM's Cell), etc... If any of the stuff you're complaining about really mattered, it ought to be a competitive advantage to someone, no? But it's verifiably not.
  - orib 18y ago
    I fully agree, but I was asked for why I don't like the x86 architecture, so I gave an answer. Current x86 CPUs are pretty awesome when it comes down to it. the ISA is quite hairy, and that makes writing tools for them quite a bit more painful than for, eg, mips, but because compilers are good you don't feel the pain from using x86 anymore, so nobody cares -- or should care -- that they're actually using x86.
- tptacek 18y ago
  What an awesome comment! Isn't the (notoriously restrictive) X86 register file a tradeoff, though? Didn't this get PPC in trouble? Every extra register winds up getting represented in the calling conventions. Accessing dwords off the top of the stack is what, a 2 cycle penalty? That's what the spill is costing you, for an instruction sequence that isn't happening all that often. When you say "there are 63 variants of the instructions" --- you mean a plain JMP, right? You're not complaining about how many Jcc variants there are? The X86 instruction set is definitely not pretty, but current X86 hardware does a really excellent job of executing it.