by making all hardware equivalent, good software enabled bad hardware.
An excellent point.
An excellent point.
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").
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?
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.
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.
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.
Accessing dwords off the top of the stack is a smallish penalty if they're in cache, and if the loads don't interfere with the pipeline.
Edit: be slightly less brief
However, in most cases, your 32 processor Sun box is replaced by one Quad Core Xeon machine, and it handles the same workload in an eighth the time.
This is why Red Hat don't bother competing with Microsoft - they make the biggest part of their revenue from replacing Sun gear - and two of the four guys I worked with closely at Red Hat were ex-Sun staff.
Sun does have a slight but well-earned reputation as vanity hardware.
Sun on Intel is just another one of those vendors.