Too bad Arm doesn't allow architectural licenses, because this is exactly the kind of thing Valve and the FEX developers would want to extend the ISA to support. I bet we see a RISC-V backend to FEX in the next 6 months, it probably already exists in a private repo.
FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.
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.
> 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.
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.
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?
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.
> 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.)
If carrying around a little bit of x86 compatibility baggage had enough die size cost to matter for Apple, then Intel and AMD would be pushing much harder to reduce their comparative mountain of x86 compatibility baggage.
In reality, the costs of design changes and validation and updating software to not rely on a newly-deprecated hardware feature can easily outweigh the potential per-chip cost savings of eliminating an instruction or two from a CPU core.
Intel and AMD have to maintain compatibility in a much different way. They don’t control what is done on the OS, they don’t control what is done with the physical product sold in stores. They have gigantic customers like Dell and HP and Microsoft that make specific technical demands out of their architecture.
Apple controls the whole stack. They decide exactly what features are in software and are in hardware. There are zero Apple machines in data centers running BigCorp’s legacy CashCow software. There are zero laptop or desktop OEMs that use Apple’s chips besides Apple. Apple won’t piss off their core consumer or creative professional customers by changing some technical behind-the-scenes feature.
I think Apple would gladly cut a very small and specific architecture feature from their chips if they feel it’s obsolete, better accomplished in software or not at all.
And this isn’t just for cost savings, it could be for performance and/or battery life optimization, or to make room for something else in the package.
I don’t think Apple is catering to developers at all. If that were the case they wouldn’t be charging them $100 a year just to exist. They have the marketshare especially in iOS to force developers on to their platform.
I believe that running Windows games is something that Apple does not care about at all. Their efforts to create the game porting tool kit are 100% about getting more Windows games ported to the macOS App Store.
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".
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.
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.
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.
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.
ARM already has most stuff required for this on board. Two proprietary extensions are used by Rosetta: one emulates the parity (rarely used) and half-carry (obsolete) flags, which can also be emulated conventionally. The other implementa TSO memory ordering, which can either be ignored or implemented with explicit barriers; some other chips apparently have a similar setting.
The other stuff is all present in ARMv8.5 I think.
ARM were perfectly fine getting the bad press for suing Qualcomm for releasing the Snapdragon that was finally performing enough despite these companies paying them a lot of money.
They seemed quite happy to destroy their eco system if they won.
Rosetta performance is best in class to my knowledge, although they had the benefit of being able to add custom instructions and modes to the cpu to make some parts easier. Meaning Rosetta would not have helped valve unless they built the frame on apple silicon.
As for not improving, it is likely that Apple no longer feels the need to invest in Rosetta improvements now that Apple silicon is so dominant and software support is already very strong, but nothing is stopping them from investing in it if they need it for example for gaming
Why would a company on its way to the moon, entrust such an important project as translation layer between two major architectures to a single rinky-dinky corp that got rich selling common electronics marketed as luxury fluff, that's on the decline and has head so far stuck up its butt that it thinks it can do whatever it wants, instead of just write it themselves with support of the global developer community?
Apple could never do games because there are no luxury games. That's completely out of their zone of comprehensibility.
> got rich selling common electronics marketed as luxury fluff
Apple products have pretty good build quality and perf per watt that more than justifies the premium. AS far as I can tell, the only payer in the market thats even trying to compete with apple on quality in the laptop space is framework. But Framework can't make their own chips.
The AAA games industry with their multi-million budgets and "being too big to fail" mentality is on decline. It seems that anything that is not a new Call of Duty is considered not worth by the industry.
But smaller games and indie studios are thriving. We got lots of very interesting indie games this year.
Games take years to make, as a consumer you’re seeing results from the past. Most indie studios are doing poorly, I know several that have closed and many friends looking for work.
FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.