3 ms·

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/ https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f... > Apple M1 has an undocumented

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/ https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f... > Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.

astrange 11mo ago
Oh yeah, maybe that one was too obscure for me. I don't think I've ever seen something use PF/AF… You do want FEAT_AFP though, so you do want ARMv8.6+.
- bonzini 11mo ago
  SETP is used rarely to compute parity, though it doesn't really save anything if you can use POPCNT. PF is also used by floating point comparisons with a different meaning though that is not useful for the Arm extension from Apple. AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".
  - astrange 11mo ago
    You can eliminate flag generation almost all the time with a little optimization (slash deoptimizing if you hit an unexpected use) but it certainly is less convenient to have to implement an optimizer.
    - bonzini 10mo ago
      The unexpectedly hard bit is switch statements, which are the main case in which compiled code has two back to back jumps... therefore the input flags come from a different basic block and you don't know which instruction generated it.
dangus 11mo ago
Perhaps another interesting aspect of this is that it’ll be Apple with their vertical stack that will decide when to physically remove this logic from the chips. macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.
- wtallis 11mo ago
  Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?
  - dangus 11mo ago
    I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad. They might even decide that they will be moving that functionality to software and decide to also leverage FEX. I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
    - wtallis 11mo ago
      > They might even decide that they will be moving that functionality to software and decide to also leverage FEX. That's crazy. Modifying an already-working CPU design to remove hardware features, and modifying Rosetta to implement that capability in software instead, or wholly replacing Rosetta with FEX, would all require investing more resources and effort than continuing to ship what's already done and working. > I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior. Fair enough, but we don't actually have to make projections based on past patterns of behavior when Apple has explicitly shared their plans. They do plan to maintain support for unmaintained games. I think the only reasonable way to interpret what Apple has said about their plans for Rosetta is to assume they're not likely to muck about with the low-level details of how they handle running x86 machine code, but they are likely to start dropping some x86 libraries from the OS, breaking applications that depend on them. We can reasonably expect that they're retain all the pieces necessary for running x86 Windows software (especially games) under Wine. (Keep in mind that Apple's approach is to not mix x86 and Arm code in the same process; they didn't do anything like Microsoft's Arm64EC.)

astrange 11mo ago

Oh yeah, maybe that one was too obscure for me. I don't think I've ever seen something use PF/AF… You do want FEAT_AFP though, so you do want ARMv8.6+.

bonzini 11mo ago
SETP is used rarely to compute parity, though it doesn't really save anything if you can use POPCNT. PF is also used by floating point comparisons with a different meaning though that is not useful for the Arm extension from Apple. AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".
- astrange 11mo ago
  You can eliminate flag generation almost all the time with a little optimization (slash deoptimizing if you hit an unexpected use) but it certainly is less convenient to have to implement an optimizer.
  - bonzini 10mo ago
    The unexpectedly hard bit is switch statements, which are the main case in which compiled code has two back to back jumps... therefore the input flags come from a different basic block and you don't know which instruction generated it.

dangus 11mo ago

Perhaps another interesting aspect of this is that it’ll be Apple with their vertical stack that will decide when to physically remove this logic from the chips. macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.

wtallis 11mo ago
Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?
- dangus 11mo ago
  I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad. They might even decide that they will be moving that functionality to software and decide to also leverage FEX. I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
  - wtallis 11mo ago
    > They might even decide that they will be moving that functionality to software and decide to also leverage FEX. That's crazy. Modifying an already-working CPU design to remove hardware features, and modifying Rosetta to implement that capability in software instead, or wholly replacing Rosetta with FEX, would all require investing more resources and effort than continuing to ship what's already done and working. > I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior. Fair enough, but we don't actually have to make projections based on past patterns of behavior when Apple has explicitly shared their plans. They do plan to maintain support for unmaintained games. I think the only reasonable way to interpret what Apple has said about their plans for Rosetta is to assume they're not likely to muck about with the low-level details of how they handle running x86 machine code, but they are likely to start dropping some x86 libraries from the OS, breaking applications that depend on them. We can reasonably expect that they're retain all the pieces necessary for running x86 Windows software (especially games) under Wine. (Keep in mind that Apple's approach is to not mix x86 and Arm code in the same process; they didn't do anything like Microsoft's Arm64EC.)