[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?

[dangus]

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]

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

[dangus]

The motivation is that die space on the chip is precious.

[wtallis]

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.

[dangus]

I don’t think that’s a very good comparison.

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.