4 ms·

Is the situation with x86 bad to begin with? Granted, I didn't read the full documentation provided online for my hardware before I powered it on. Honestly, I

Is the situation with x86 bad to begin with? Granted, I didn't read the full documentation provided online for my hardware before I powered it on. Honestly, I didn't read any documentation and it just works, kind of.

mwcampbell 10y ago
Depends on how much of the complexity described in those thousands of pages of documentation is actually necessary, and how much could be eliminated with a better design.
- Someone 10y ago
  Lots of it isn't so much bad design as not willing to give up backwards compatibility. Some examples: - the old floating point register stack and its 80-bit registers - I don't know how many iterations on SIMD instructions (MMX, a few iterations of SSE, a few iterations of AVX, various prefixes to make older instructions use newer registers) If you got rid of those, you also could get rid of quite a few prefix instructions, maybe a configuration bit here and there, etc. It also doesn't help that, at times, Intel and AMD independently added stuff to the x86.
pcwalton 10y ago
x86-64 has tons of cruft: complex instruction encoding (mod R/M and SIB bytes), bloated instruction encoding thanks to REX prefixes, real mode, virtual 8086 mode, odd SIMD limitations, pointless instructions like XLAT, binary coded decimal, a non-orthogonal instruction set with some 3-register instructions (LEA, IMUL, AVX2) mixed with a bunch of other 2-register instructions, individually addressable low and high bytes of certain registers but not others…
- h4nkoslo 10y ago
  Most of that cruft consumes minimal die area and results in absolutely minimal slowdown compared to an "optimized" minimal architecture. Fun exercise: do a histogram of instructions in some large program's binary. Not a ton of weirdness in practice.
  - pcwalton 10y ago
    I'm not disputing that. I'm talking about complexity of the programming model (number of pages in the manual), not performance.
  - flamedoge 10y ago
    What was the main reason to add REX prefix for 64bit? Why not create longer register bits to hold 16 registers? Was it for easier binary to binary transformation?
    - pcwalton 10y ago
      Because AMD was deathly afraid of AMD64 going the way of Itanium. So they went out of their way to make their architecture as similar to 32-bit x86 as possible, right down to reusing the encoding. They also probably figured that they could reuse decoding logic.
Redoubts 10y ago
The paper on the Design of RISC-V has a really good survey of existing ISA like x86: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
Kubuxu 10y ago
To show complexity of x86-64 it is best to look at boot process. You processor starts in 16bit mode, then is upgraded to 32bit and then to 64bit mode. You want to do some call to BIOS now? You have to downgrade through 32bit mode to 16 bit mode to do that and then back up to handle the response. And it is just very small component of cruft that x86-64 has.
- amluto 10y ago
  This particular issue is overhyped IMO. 64-bit UEFI mostly bypasses it. Sure, the firmware entry point has some bootstrapping to to, but this isn't a big deal. The really weird initial state of SMM is a bigger deal since it happens at runtime.
- hlandau 10y ago
  The rate at which the complexity of the amd64 boot process is increasing is quite alarming. UEFI is an overcomplicated, buggy monstrosity, but that's just the tail end of the "boot process". Nowadays, to get an x86 CPU to execute a single opcode, you need to have a Management Engine (or Platform Security Processor, in AMD-speak) firmware blob resident in the firmware flash chip. More modern CPUs, for Intel, say, oblige you to use Intel-provided "memory reference code" and other "firmware support package" blobs just to initialize the CPU in the early stage. AFAIK, Intel isn't even bothering to document the details of its CPU and chipset initialization sequences anymore, in favour of just making people use unexplained blobs. These are just some of the issues the coreboot project is having to deal with. It really feels like at least in the world of x86, the window is rapidly closing on projects like coreboot being able to accomplish anything useful, although there are at least some major users like Chromebooks. And then of course we have things like SMM, and the way in which secure firmware updates are facilitated (which relies on things like flash write protect functionality)...
  - djsumdog 10y ago
    Those blobs are run by the BIOS/UEFI correct? Like Grub/the Linux kernel don't need those Intel blobs just to get booting do they?

mwcampbell 10y ago

Depends on how much of the complexity described in those thousands of pages of documentation is actually necessary, and how much could be eliminated with a better design.

Someone 10y ago
Lots of it isn't so much bad design as not willing to give up backwards compatibility. Some examples: - the old floating point register stack and its 80-bit registers - I don't know how many iterations on SIMD instructions (MMX, a few iterations of SSE, a few iterations of AVX, various prefixes to make older instructions use newer registers) If you got rid of those, you also could get rid of quite a few prefix instructions, maybe a configuration bit here and there, etc. It also doesn't help that, at times, Intel and AMD independently added stuff to the x86.

pcwalton 10y ago

x86-64 has tons of cruft: complex instruction encoding (mod R/M and SIB bytes), bloated instruction encoding thanks to REX prefixes, real mode, virtual 8086 mode, odd SIMD limitations, pointless instructions like XLAT, binary coded decimal, a non-orthogonal instruction set with some 3-register instructions (LEA, IMUL, AVX2) mixed with a bunch of other 2-register instructions, individually addressable low and high bytes of certain registers but not others…

h4nkoslo 10y ago
Most of that cruft consumes minimal die area and results in absolutely minimal slowdown compared to an "optimized" minimal architecture. Fun exercise: do a histogram of instructions in some large program's binary. Not a ton of weirdness in practice.
- pcwalton 10y ago
  I'm not disputing that. I'm talking about complexity of the programming model (number of pages in the manual), not performance.
- flamedoge 10y ago
  What was the main reason to add REX prefix for 64bit? Why not create longer register bits to hold 16 registers? Was it for easier binary to binary transformation?
  - pcwalton 10y ago
    Because AMD was deathly afraid of AMD64 going the way of Itanium. So they went out of their way to make their architecture as similar to 32-bit x86 as possible, right down to reusing the encoding. They also probably figured that they could reuse decoding logic.

Redoubts 10y ago

The paper on the Design of RISC-V has a really good survey of existing ISA like x86: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

Kubuxu 10y ago

To show complexity of x86-64 it is best to look at boot process. You processor starts in 16bit mode, then is upgraded to 32bit and then to 64bit mode. You want to do some call to BIOS now? You have to downgrade through 32bit mode to 16 bit mode to do that and then back up to handle the response. And it is just very small component of cruft that x86-64 has.

amluto 10y ago
This particular issue is overhyped IMO. 64-bit UEFI mostly bypasses it. Sure, the firmware entry point has some bootstrapping to to, but this isn't a big deal. The really weird initial state of SMM is a bigger deal since it happens at runtime.
hlandau 10y ago
The rate at which the complexity of the amd64 boot process is increasing is quite alarming. UEFI is an overcomplicated, buggy monstrosity, but that's just the tail end of the "boot process". Nowadays, to get an x86 CPU to execute a single opcode, you need to have a Management Engine (or Platform Security Processor, in AMD-speak) firmware blob resident in the firmware flash chip. More modern CPUs, for Intel, say, oblige you to use Intel-provided "memory reference code" and other "firmware support package" blobs just to initialize the CPU in the early stage. AFAIK, Intel isn't even bothering to document the details of its CPU and chipset initialization sequences anymore, in favour of just making people use unexplained blobs. These are just some of the issues the coreboot project is having to deal with. It really feels like at least in the world of x86, the window is rapidly closing on projects like coreboot being able to accomplish anything useful, although there are at least some major users like Chromebooks. And then of course we have things like SMM, and the way in which secure firmware updates are facilitated (which relies on things like flash write protect functionality)...
- djsumdog 10y ago
  Those blobs are run by the BIOS/UEFI correct? Like Grub/the Linux kernel don't need those Intel blobs just to get booting do they?