This doesn't seem to mention the overhead that ARM64EC imposes on indirect calls. Indirect calls are required by the ARM64EC ABI to use a CFG-like check against the architecture bitmap, adding overhead to both function pointers and virtual calls:
https://gcc.godbolt.org/z/8aT793GMf
> Call checkers are optional on all other Windows ABIs, but mandatory on Arm64EC. On Arm64EC, call checkers accumulate the task of verifying the architecture of the function being called. They verify whether the call is another EC (“Emulation Compatible”) function or an x64 function that must be executed under emulation. In many cases, this can only be verified at runtime.
I'm wondering why you couldn't rely on pages containing non-native code being marked "no execute" instead. Trapping into kernel mode might be slower, but for binaries that are mostly ARM, the expected case would be that the bitmap check always succeeds - and it there was such a fallback method of switching to emulated code, the compiler would then be free to either omit the check or leave it in, based on profiling information?
This is pretty cool: basically, recent ARM extensions make emulation of just about anything a lot easier.
Which got me to wonder: what if Apple were able to introduce a "MacOS subsystem for Windows", which could run most x64 binaries for the latter platform?
The only app that keeps me from switching to my M3 MacBook full-time is Visual Studio (and Mikrotik WinBox, to some extent, but that runs just fine under Wine).
If I could run VS without tanking battery life, that would be sort-of huge...
> what if Apple were able to introduce a "MacOS subsystem for Windows”
Where would they get the ‘for Windows’ part? They would eiher have to use Wine (which isn’t 100% compatible), license Windows from Microsoft ($$$), or write their own Wine (takes time)
> If I could run VS without tanking battery life
There’s no guarantee emulating Windows would be as energy-efficient as running MacOS.
Also, if it did, that would open the door for third parties abandoning MacOS (it runs fine "MacOS subsystem for Windows”, so why would we spend time on a Mac port?), just as happened with “OS/2 subsystem for Windows” (https://en.wikipedia.org/wiki/OS/2#OS/2_2.1_and_Windows_comp...)
> They would eiher have to use Wine (which isn’t 100% compatible)
If anything, Apple can afford to shove a few millions onto Wine. Most of the heavy lifting has already been done, you can run a lot of Windows apps with just a few issues.
The nasty exceptions tend to be anything involving DRM and anti-cheat, as well as stuff requiring interfacing with external hardware directly.
Two approaches that spring to mind would be to run VSCode on the Mac rather than Visual Studio - you might find it's decent enough and does what you need.
If you need the full Visual Studio experience, then another option would be the Windows/Arm64 build of Visual Studio, and run that on a virtual box.
Where can I get this 'full fat' ARM build of VS? I'll settle for a Win64-ARM release, but I'll personally provision a botnet to upvote you to Mars in case you point me to an Apple-Silicon-on-MacOS DMG...
> Which got me to wonder: what if Apple were able to introduce a "MacOS subsystem for Windows", which could run most x64 binaries for the latter platform?
Was attempted by Apple but abandoned ages ago, around Leopard times.
What they do nowadays is to keep good enough platform support to be able to use Wine.
That's clever trick but I think it is a mistake in the long run. It removes incentives from putting effort into compiling all libraries as native code, instead effectively fossilizing x86_64 as another weird vestigal part of Windows applications.
Microsoft tried a hard break before (Windows RT), and developers didn't show up. They need this so people are willing to buy the platform and increase the market enough for developers to start doing bespoke ports.
I don't buy it. The problem with Windows RT is that they made it impossible to run ARM binaries on Windows. If they had just allowed, as an example, Mozilla to make an ARM build of Firefox for Windows they'd have done it. And it would have spread to all the small utilities and eventually to larger apps.
Instead Microsoft locked down the entire platform iOS-style and nobody bothered.
The break was too hard, because not only it was a hard break, they kept messing the development experience, to this day now with WinUI 3.0/WinAppSDK, still quite far from Win32/Forms/WPF/MFC.
Every reboot of WinRT tooling required a rewrite, and some tooling was left behind.
ARM has so much momentum everywhere but Windows that I don't think a soft transition will stall any transition, as ARM-Window demand increases.
But it would be nice to have reciprocal ARM emulation on Intel. That would reduce a lot of friction for such a transition. Both forward and backward CPU compatibility.
yes, this sounds pretty messy and I am wondering how they deal with the different memory consistencies of the two architectures. IIRC apple CPUs have HW support for the stricter x86 model.
The hybrid approach is interesting. But to me the author is more. How can one work for office 98 is still around as a program lead for such low level programming job. Had he been kicked upstairs becomes a manager and how is the salary compensation work. Just wonder for such in depth and occasional history chip in work.
After reading the end I found the answer … you do have issue for such long career. God blessed.
“ When I was still at Microsoft in 2022 I was arguing the case that it was time to implement AVX and AVX2 across the board, but I failed to convince management or my peers of the urgency of this proposal.”
Anyhow, the dance around of code and directories make me think of the different in philosophy and trade off of time and space a lot. Once again good read.
This is explained in the docs: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi
> Call checkers are optional on all other Windows ABIs, but mandatory on Arm64EC. On Arm64EC, call checkers accumulate the task of verifying the architecture of the function being called. They verify whether the call is another EC (“Emulation Compatible”) function or an x64 function that must be executed under emulation. In many cases, this can only be verified at runtime.