5 ms·

Since DAA generates #UB in 64-bit mode, I assume all such "adjust" instructions do (haven't bothered to check). In that case, is the auxiliary flag (AF) in the

by zvrba 4y ago

Since DAA generates #UB in 64-bit mode, I assume all such "adjust" instructions do (haven't bothered to check). In that case, is the auxiliary flag (AF) in the flags register used for anything at all in 64-bit mode?

kens 4y ago
Yes, the other adjust instructions are invalid in 64-bit mode. The Auxiliary Flag can get set in 64-bit mode, but I don't think anything uses it. You could access it through the EFLAGS register but I think it's otherwise useless.
userbinator 4y ago
One of the most puzzling things about 64-bit mode. There's no reason why they wouldn't work, and they didn't find anything else to reuse those valuable 1-byte opcodes for either.
- ajross 4y ago
  This is true for a lot of historical cruft (c.f. segment registers wired to zero in 64 bit mode, likewise there's no reason that calculation shouldn't work since you have to have it present in 32 bit protected mode anyway). Presumably AMD wanted to specify only the future-useful subset of the architecture to be usable in long mode so that in the future when people started shipping long mode only CPUs[1] they wouldn't have to bother with the junk. [1] Which never happened, presumably because the transistor overhead of supporting real and 32 bit mode on the monster cores of the modern world was negligible. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode.
  - userbinator 4y ago
    64-bit mode could've just been an extension of regular protected mode, using double-wide descriptors of the reserved types that may even have been reserved for that purpose. That would've been the ultimate in backwards compatibility and a logical step. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode I don't think so. I certainly wouldn't want one, and neither would a lot of other people. Intel learned that lesson twice --- once with the 80376, and again when it started making x86 smartphone SoCs. No one really wants x86 without the rest of the PC architecture, since then they might as well use something like ARM or even RISC-V instead.
    - ajross 4y ago
      Out of curiosity: 1. What software would you want to run that used 286-style segmentation in a 64 bit space? That model had been abandoned long before AMD wrote the x86_64 spec. 2. What 386 protected mode (or unreal mode too, I guess) software are you needing to run such that you wouldn't buy a 64-bit-only CPU? Again, this has been entirely abandoned (with the sole exception of the SMP boot mechanism, which is defined to start in real mode) on modern systems, even at the firmware level.

by zvrba 4y ago

kens 4y ago

Yes, the other adjust instructions are invalid in 64-bit mode. The Auxiliary Flag can get set in 64-bit mode, but I don't think anything uses it. You could access it through the EFLAGS register but I think it's otherwise useless.

userbinator 4y ago

One of the most puzzling things about 64-bit mode. There's no reason why they wouldn't work, and they didn't find anything else to reuse those valuable 1-byte opcodes for either.

ajross 4y ago
This is true for a lot of historical cruft (c.f. segment registers wired to zero in 64 bit mode, likewise there's no reason that calculation shouldn't work since you have to have it present in 32 bit protected mode anyway). Presumably AMD wanted to specify only the future-useful subset of the architecture to be usable in long mode so that in the future when people started shipping long mode only CPUs[1] they wouldn't have to bother with the junk. [1] Which never happened, presumably because the transistor overhead of supporting real and 32 bit mode on the monster cores of the modern world was negligible. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode.
- userbinator 4y ago
  64-bit mode could've just been an extension of regular protected mode, using double-wide descriptors of the reserved types that may even have been reserved for that purpose. That would've been the ultimate in backwards compatibility and a logical step. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode I don't think so. I certainly wouldn't want one, and neither would a lot of other people. Intel learned that lesson twice --- once with the 80376, and again when it started making x86 smartphone SoCs. No one really wants x86 without the rest of the PC architecture, since then they might as well use something like ARM or even RISC-V instead.
  - ajross 4y ago
    Out of curiosity: 1. What software would you want to run that used 286-style segmentation in a 64 bit space? That model had been abandoned long before AMD wrote the x86_64 spec. 2. What 386 protected mode (or unreal mode too, I guess) software are you needing to run such that you wouldn't buy a 64-bit-only CPU? Again, this has been entirely abandoned (with the sole exception of the SMP boot mechanism, which is defined to start in real mode) on modern systems, even at the firmware level.