ARM64EC (and ARM64X) Explained(emulators.com)
emulators.com
ARM64EC (and ARM64X) Explained
http://www.emulators.com/docs/abc_arm64ec_explained.htm
41 comments
In-depth explanation how Windows 11 improves interoperability of x86_64 and arm64 code under emulation.
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...
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...
> 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.
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.
Do you have more information? I recall _rumors_ about Apple adding a feature for Windows apps on Mac in those days, but nothing concrete.
I'd love to hear if this was ever more than rumour!
I'd love to hear if this was ever more than rumour!
Was more than a rumor.
https://www.winehq.org/pipermail/wine-devel/2007-November/th... some remaining notes of that bizarre episode
https://www.winehq.org/pipermail/wine-devel/2007-November/th... some remaining notes of that bizarre episode
Are you sure your link isn’t broken?
This thread looks like it: https://www.winehq.org/pipermail/wine-devel/2007-November/06...
I use native ARM VS under MacOS just fine, although MS announced end of life for it this August.
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.
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.
> the Windows/Arm64 build of Visual Studio
There is no such thing. "Visual Studio for Mac" is a re-spin of MonoDevelop, and doesn't compare to the actual VS in any way, shape or form.
The closest you can get to VS-on-ARM-Mac right now is using a JetBrains IDE, but, as useful as these are, it's really no competition...
There is no such thing. "Visual Studio for Mac" is a re-spin of MonoDevelop, and doesn't compare to the actual VS in any way, shape or form.
The closest you can get to VS-on-ARM-Mac right now is using a JetBrains IDE, but, as useful as these are, it's really no competition...
Actually it started like that, but eventually they started sharing code with VS, not that it matters any longer, as VS4Mac has been killed.
No. The full-fat Visual Studio is native arm64 nowadays!
Do need to have Parallels and Windows installation on macOS. But other than that, can run a native version of Visual Studio on ARM64.
As they say on Wikipedia: [Citation needed]
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...
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...
The same place you download the x86 build: visualstudio.com
See: https://devblogs.microsoft.com/visualstudio/arm64-visual-stu...
See: https://devblogs.microsoft.com/visualstudio/arm64-visual-stu...
Right. And I run Windows for ARM64 (WoA64) in Parallels on my M3 Mac, and install VS in it (ARM64 version) and runs fine.
Thank you so much, as you can see, I truly didn't know that. Maybe tuning out Microsoft messaging to the max wasn't the best decision after all...
> 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...)
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.
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.
This was a rumour already in the mid-2000s already, either for Leopard or Snow Leopard.
I feel old for witnessing rumour cycles start over again.
I feel old for witnessing rumour cycles start over again.
Has a real Transmeta vibe. I wonder if Dave Ditzel is working for Arm these days.
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.
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.
Every reboot of WinRT tooling required a rewrite, and some tooling was left behind.
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.
Instead Microsoft locked down the entire platform iOS-style and nobody bothered.
That was the very first version, afterwards the choice was between plain Windows 10 on ARM, or Windows 10 S(ecure) mode.
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.
[deleted]
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.
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.
Hug of death. Anybody got a mirror?
This approach was exceptionally well thought-through and it shows.
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
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.
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.
The check can be done just once per {destination, sourceArch} pair and cached, so overall the amortized impact should be just one extra load
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 what Rosetta does IIRC
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.
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.
I hope Microsoft does not plan on violating LP64D[0] on its RISC-V port.
0. https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/ma...
0. https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/ma...