5 ms·

Is the situation appreciably better with ARMv8? How about ARMv7?

static_noise 10y ago
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?
monocasa 10y ago
ARMv7 was already approaching x86 levels of complexity. Something like 1200 instructions and 30 years of cruft.
pcwalton 10y ago
Most ARMv8 CPUs in the wild are backwards compatible with 32-bit ARM and Thumb (able to switch modes on CPU exceptions), but AArch64 is a near-complete redesign of the ISA to eliminate cruft. It's very nice that ARM removed things like the conditional execution, weird behavior of the "pc" register, and most of the barrel shifter complexity. It is not an architectural requirement for ARMv8 processors to implement the 32-bit ARM ISA (though of course for practical reasons they do today). So, eventually, if we start seeing ARMv8 processors that eliminate the 32-bit compatibility, we may see a nice architectural simplification (though I wouldn't be surprised if the transistor count doesn't decrease that much).
- mwcampbell 10y ago
  I think Apple will be the first to drop 32-bit compatibility, since they've been requiring 64-bit support in all iOS App Store submissions for a while now.
  - dpc_pw 10y ago
    Definitely. As a dominant platform owner they can push everyone to bend over backwards all the time. And they will since any fab and power savings will be totally worth it for the user, even if they marginal.
- flukus 10y ago
  So AArch64 is simpler? Could we expect a simpler architecture to take a performance lead in future?
  - pcwalton 10y ago
    Yes, it's significantly simpler. I would be very glad to see that yield a performance increase, though I suspect the difference would be small.
  - nn3 10y ago
    If you go by pages in the specification https://people-mozilla.org/~sstangl/arm/AArch64-Reference-Manual.pdf https://people-mozilla.org/~sstangl/arm/AArch64-Reference-Ma... is 5183 pages, which is about 10% longer than the Intel manual, which currently has 4670 pages.

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?

monocasa 10y ago

ARMv7 was already approaching x86 levels of complexity. Something like 1200 instructions and 30 years of cruft.

pcwalton 10y ago

Most ARMv8 CPUs in the wild are backwards compatible with 32-bit ARM and Thumb (able to switch modes on CPU exceptions), but AArch64 is a near-complete redesign of the ISA to eliminate cruft. It's very nice that ARM removed things like the conditional execution, weird behavior of the "pc" register, and most of the barrel shifter complexity. It is not an architectural requirement for ARMv8 processors to implement the 32-bit ARM ISA (though of course for practical reasons they do today). So, eventually, if we start seeing ARMv8 processors that eliminate the 32-bit compatibility, we may see a nice architectural simplification (though I wouldn't be surprised if the transistor count doesn't decrease that much).

mwcampbell 10y ago
I think Apple will be the first to drop 32-bit compatibility, since they've been requiring 64-bit support in all iOS App Store submissions for a while now.
- dpc_pw 10y ago
  Definitely. As a dominant platform owner they can push everyone to bend over backwards all the time. And they will since any fab and power savings will be totally worth it for the user, even if they marginal.
flukus 10y ago
So AArch64 is simpler? Could we expect a simpler architecture to take a performance lead in future?
- pcwalton 10y ago
  Yes, it's significantly simpler. I would be very glad to see that yield a performance increase, though I suspect the difference would be small.
- nn3 10y ago
  If you go by pages in the specification https://people-mozilla.org/~sstangl/arm/AArch64-Reference-Manual.pdf https://people-mozilla.org/~sstangl/arm/AArch64-Reference-Ma... is 5183 pages, which is about 10% longer than the Intel manual, which currently has 4670 pages.