[jsheard]

My understanding is that Rosetta sidesteps a bunch of tricky memory model issues by using non-standard hardware extensions only present in Apple Silicon, so even if Apple did share Rosetta, which they certainly won't, it wouldn't work properly on Valves hardware anyway.

[astrange]

It's not only present in Apple Silicon, it's just not required by the ARM standard. Fujitsu also has an ARM64 CPU with TSO.

[lugu]

Nice article on this topic: https://lwn.net/Articles/970907/

[wmf]

There are a bunch of undocumented flags and instructions beyond TSO.

[astrange]

Trust me on this one?

[chadaustin]

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.

[dangus]

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]

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?

[LeFantome]

I am not sure I consider it that likely.

First, these features are a big draw for developers (a key macOS audience).

Second, the ability to run Windows games is not getting less valuable.

[astrange]

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]

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".

[sitkack]

There are also RISC-V designs with TSO. If you are targeting x86 workloads, it makes sense to have a per thread TSO mode.

[fooblaster]

yeah that is correct. The m series chips can turn on total store ordering memory model solely for Rosetta. There's also some hardware extensions to arm to support x86 condition codes in the hardware because it's way more instruction efficient that way.

[sgerenser]

The latter is now an optional feature in the mainstream Arm ISA now (FEAT_FlagM and FEAT_FlagM2). Similarly the “alternate floating point mode” that Apple uses to match nuances of x86 FP semantics is a standard architectural feature as well. The TSO option though is Apples own thing.

[astrange]

If you mean FEAT_FlagM, that's standard in ARMv8.4. (There's also FlagM2 and AFP that are optional.)

The JavaScript instruction is cooler though.

https://developer.arm.com/documentation/dui0801/g/A64-Floati...

[gorkish]

RISC is dead; long live RISC