> If Microsoft releases an equivalent of Rosetta at the same level of quality it will be a different story.

Microsoft has had their own Rosetta equivalent for a few years now. In theory application compatibility is more comprehensive than Rosetta as it supports much older applications, including 32-bit applications. In practice (likely as a result of trying to support so much more stuff) application compatibility isn't as rock solid as Rosetta for every application.

https://learn.microsoft.com/en-us/windows/arm/apps-on-arm-x8...

Apple's Rosetta uses some special hardware in the M1 and later chips to make some x86/x64 translated instructions much faster. I believe it was the load and store instructions.

Microsoft doesn't have access to these instructions for their own implementation (because they are not ARM standard), but theoretically they could have qualcomm or other SoC providers add some custom hardware that does the same. But in a fragmented landscape that can be hard, some windows laptop SoCs might have it, some might not.

Microsoft could still work with their partners to implement this. Yes, the PC market tend to be fragmented, but what I assume would happen is that some ARM PCs will have the hardware acceleration, and for those it would lead to a much better performance. But, for the ones without hardware acceleration, it would just fallback to software emulation.

And as time goes on, more and more OEMs would probably favor adding the hardware support because people would prefer to buy the ones with faster x86 emulation.

Rosetta on the M1 enables the total store ordering from x86, which has a stronger memory model than that of ARM. It also can compute the parity flag in hardware <https://bytecellar.com/2022/11/16/a-secret-apple-silicon-ext...>.

If I remember right, total store ordering is actually a standard ARM extension, and not something Apple came up with on its own. I'm not sure about the flag computations, I suppose those are custom?

I think it’s slightly more complex than that. Apple included in their processor design custom extensions to ARM that alter things like memory order to make emulation easier [1]. It’s not just control over the software stack that makes Rosetta so performant.

[1] https://github.com/saagarjha/TSOEnabler

Nvidia could do the same

Which would only help them if they'd roll their own emulation layer instead of relying on what Microsoft has.

Nvidia is a software company, but i doubt they want to deal with making decades of windows binaries work.

Microsoft and NVidia have a history of collaborating to adapt Windows APIs to NVidia hardware. DirectX 10 was practically designed to NVidia's next-gen hardware spec.

If Microsoft is serious about ARM, there's no reason they couldn't work together to ensure the CPU is optimized for Microsoft's emulation layer.

In general Microsoft are in favour of doing anything that sells more copies of Windows and I have no doubt supporting an extremely fast Nvidia CPU on ARM is possible. It might never run software as well as x86 but maybe if it ends up being faster for games (which could be possible with MS and NVDA support) then people will buy it.

> Nvidia is a software company, but i doubt they want to deal with making decades of windows binaries work.

Isn't Nvidia already doing this with their drivers? Games are notorious for suboptimal or downright incorrect graphics API calls that get patched in the graphics driver on a per-game basis - at least for the AA games in the past.

Apple doesn't have (tight) control over the whole software stack. This is something people say and probably believe.

They don't write Haskell, Postgres, Rust, Java, Scala, Firefox, Spotify, VS Code, Postico or any number of the other software that I run.

They (Apple) released _their_ software and the necessary tools to make it possible for all the software vendors to port all their code in their time, basically. But it all ran (runs!) on both Intel and ARM, still.

Most of the software mentioned was working fine on ARM based SBC-s long before Apple switched to it.

I know! And it was not under Apple's control in any sense. This is my point!

Why has this been downvoted? Who is upset by this?

I think it might be interesting though.

Microsoft is a software company. Nvidia is a hardware company.

Although they don't have the tight integration that Apple has, there might not be the limitations apple adds.

What do you call the surface line and the Xbox?

Also Rosetta isn't perfect. Apple doesn't have gaming. Windows does. Even if ms was to release Rosetta one of their core market uses will be crippled.

This is where close partnering helps. Microsoft can lead the way in building all their games(a considerable library, especially after the Activision acquisition) with universal binaries, and provide great tools to third parties to build games the same way.

The games that aren't recompiled will (after 2 years or so) fall far enough behind in requirements compared to the state of the art, that the emulation will be fast enough to play those older games.

I doubt Starfield will ever be emulatable on current gen hardware.

HOWEVER MS does have an ace -- they can make the next xbox an ARM machine. This will guarantee that all game devs either migrate to ARM or face being on an emulator with reduced capabilities. That will create the needed tech. But it will also help Apple... so MS is likely to try to avoid it.

This person got Overwatch 2 working at a decent framerate(100+FPS) on an M1 Pro:

https://www.reddit.com/r/macgaming/comments/129jzv4/overwatc...

Starfield should be barely playable if someone manages to get it to run(game requires x86 instructions rosetta doesn't currently support). With M3 around the corner it should be very playable, which falls in line with the 2 year timeline.

Apple has fat binaries, and made Xcode produce them by default, with seamless cross-compilation. AFAIK Windows has nothing like that. There are no fat binaries. Cross-compilation is fiddly and needs to be done manually.

There is a massive difference between developers just needing to press the "Build" button again (with no code or config changes), and requiring developers to manually add support for both architectures the hard way.