6 ms·

The OP perpetuates the mistaken assumption that x86-64 looks as it does because it extends good ol' 32-bit x86 encodings, which one might assume still work so w

The OP perpetuates the mistaken assumption that x86-64 looks as it does because it extends good ol' 32-bit x86 encodings, which one might assume still work so well that one could run 32-bit code in 64-bit mode and have it still work. Which is not the case at all. Those REX prefix bytes used to be perfectly good 32-bit x86 instructions that now simply don't work in 64-bit mode with their original encodings. So the "compatibility" between 32-bit and 64-bit modes is mythical -- the Opteron could have had a nice shiny new 64-bit programming model that was far less confusing than the dog's breakfast that is x86-64, but just didn't.

ant6n 10y ago
They probably wanted to re-use most of the x86-32 decoder that they had on the chip anyway. Kind of strange, nowadays, an embedded armv8 cpu will come with multiple decoders (ARM32, thumb2, AARCH64).
- gens 10y ago
  AFAIK the reason for amd64 being what it is are intels lawyers.
  - eloff 10y ago
    That makes little sense, could you elaborate? AMD could have done anything they wanted with amd64 instruction encodings.
    - gens 10y ago
      Well, not lawyers directly. More through lack of cooperation (due to competitive mentality). http://www.agner.org/optimize/blog/read.php?i=25 http://www.agner.org/optimize/blog/read.php?i=25
      - eloff 10y ago
        I don't see how that matters in this case, AMD took the lead on AMD64 and Intel had to copy them afterward. They really could have done anything they wanted. As someone else here mentioned it was probably more to re-use the existing investment in x86 decoders.
        gens 10y ago
        Amd64 encoding, as is the case with most x86 encodings, is longer then it should be. Due to the two companies not communicating/cooperating. That is the one advantage that i think ARM has over x86/amd64. That ARM encoding is much shorter.
        eloff 10y ago
        You just repeated your point without adding anything new, that doesn't help your argument.
        gens 10y ago
        They couldn't use the shorter code space. So no, they could not do whatever they wanted. (note that making a completely new instruction encoding scheme would fail for obvious reasons)
        eloff 10y ago
        I disagree, 64bit mode did not have to have any kind of instruction compatibility. It could have been a completely new instruction encoding scheme. A 64bit process must run all 64bit code, there is no invoking 32bit code from a 64bit process on any modern OS for AMD64.
        ant6n 10y ago
        And adding to that, they could've probably come up with some sort of 32bit per instruction risc structure where the the makeup overlaps with the cisc x86 encoding. For example, pack the 16 bits of a normal x86 instruction into the first bits of the risc, then add second source register and a bit or to each operand to increase the number of registers.
- lisper 10y ago
  This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for competition.
  - gsnedders 10y ago
    Related to this is the PPC615, an IBM project in the mid-90s, socket compatible with the original Pentium, and ran x86-32, PPC32, and PPC64 natively. (It got scrapped because all the signs looked like Intel was going to push IA-64 heavily, and rely on it's backwards compatibility for x86-32, hence an expectation x86-32 was soon to be legacy.)
    - setpatchaddress 10y ago
      Do you have a reference for that? I've heard various things about the 615, one of which was that it wasn't ever a real project.
  - pcwalton 10y ago
    > It's all RISC under the hood anyway, why not give us access to it? Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. It feels to me like people have trouble accepting that both of these are true: (1) RISC vs. x86 doesn't matter that much in practice; (2) technically speaking, RISC is a superior design to x86.
    - nullc 10y ago
      > Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. Intel invested in a new instruction set (IA64). AMD did not. The market chose AMD's offering.
      - 10y ago
bonzini 10y ago
Those instructions were hard to optimize because of partial flags stalls. In the end because of this and because of strength reduction compilers were not generating that many INC and DEC instructions.

ant6n 10y ago

They probably wanted to re-use most of the x86-32 decoder that they had on the chip anyway. Kind of strange, nowadays, an embedded armv8 cpu will come with multiple decoders (ARM32, thumb2, AARCH64).

gens 10y ago
AFAIK the reason for amd64 being what it is are intels lawyers.
- eloff 10y ago
  That makes little sense, could you elaborate? AMD could have done anything they wanted with amd64 instruction encodings.
  - gens 10y ago
    Well, not lawyers directly. More through lack of cooperation (due to competitive mentality). http://www.agner.org/optimize/blog/read.php?i=25 http://www.agner.org/optimize/blog/read.php?i=25
    - eloff 10y ago
      I don't see how that matters in this case, AMD took the lead on AMD64 and Intel had to copy them afterward. They really could have done anything they wanted. As someone else here mentioned it was probably more to re-use the existing investment in x86 decoders.
      - gens 10y ago
        Amd64 encoding, as is the case with most x86 encodings, is longer then it should be. Due to the two companies not communicating/cooperating. That is the one advantage that i think ARM has over x86/amd64. That ARM encoding is much shorter.
        eloff 10y ago
        You just repeated your point without adding anything new, that doesn't help your argument.
        gens 10y ago
        They couldn't use the shorter code space. So no, they could not do whatever they wanted. (note that making a completely new instruction encoding scheme would fail for obvious reasons)
        eloff 10y ago
        I disagree, 64bit mode did not have to have any kind of instruction compatibility. It could have been a completely new instruction encoding scheme. A 64bit process must run all 64bit code, there is no invoking 32bit code from a 64bit process on any modern OS for AMD64.
        ant6n 10y ago
        And adding to that, they could've probably come up with some sort of 32bit per instruction risc structure where the the makeup overlaps with the cisc x86 encoding. For example, pack the 16 bits of a normal x86 instruction into the first bits of the risc, then add second source register and a bit or to each operand to increase the number of registers.
lisper 10y ago
This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for competition.
- gsnedders 10y ago
  Related to this is the PPC615, an IBM project in the mid-90s, socket compatible with the original Pentium, and ran x86-32, PPC32, and PPC64 natively. (It got scrapped because all the signs looked like Intel was going to push IA-64 heavily, and rely on it's backwards compatibility for x86-32, hence an expectation x86-32 was soon to be legacy.)
  - setpatchaddress 10y ago
    Do you have a reference for that? I've heard various things about the 615, one of which was that it wasn't ever a real project.
- pcwalton 10y ago
  > It's all RISC under the hood anyway, why not give us access to it? Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. It feels to me like people have trouble accepting that both of these are true: (1) RISC vs. x86 doesn't matter that much in practice; (2) technically speaking, RISC is a superior design to x86.
  - nullc 10y ago
    > Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. Intel invested in a new instruction set (IA64). AMD did not. The market chose AMD's offering.
    - 10y ago

bonzini 10y ago

Those instructions were hard to optimize because of partial flags stalls. In the end because of this and because of strength reduction compilers were not generating that many INC and DEC instructions.