[HN Gopher] ARM64EC (and ARM64X) Explained
___________________________________________________________________
ARM64EC (and ARM64X) Explained
Author : kohlschuetter
Score : 75 points
Date : 2024-03-24 12:16 UTC (10 hours ago)
(HTM) web link (www.emulators.com)
(TXT) w3m dump (www.emulators.com)
| kohlschuetter wrote:
| In-depth explanation how Windows 11 improves interoperability of
| x86_64 and arm64 code under emulation.
| PreInternet01 wrote:
| 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...
| my123 wrote:
| > 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.
| flyinglizard wrote:
| I use native ARM VS under MacOS just fine, although MS
| announced end of life for it this August.
| TillE wrote:
| "Visual Studio for Mac" never had any relation to Visual
| Studio proper, it was just a rebranded Xamarin Studio. It
| didn't support C++ at all.
| pjmlp wrote:
| Eventually they started sharing some .NET infrastructure,
| until they decided to kill it.
| cesaref wrote:
| 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.
| PreInternet01 wrote:
| > 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...
| my123 wrote:
| No. The full-fat Visual Studio is native arm64 nowadays!
| vardump wrote:
| Do need to have Parallels and Windows installation on
| macOS. But other than that, can run a native version of
| Visual Studio on ARM64.
| PreInternet01 wrote:
| 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...
| hyperrail wrote:
| The same place you download the x86 build:
| visualstudio.com
|
| See:
| https://devblogs.microsoft.com/visualstudio/arm64-visual-
| stu...
| billti wrote:
| Right. And I run Windows for ARM64 (WoA64) in Parallels
| on my M3 Mac, and install VS in it (ARM64 version) and
| runs fine.
| pjmlp wrote:
| Actually it started like that, but eventually they started
| sharing code with VS, not that it matters any longer, as
| VS4Mac has been killed.
| Someone wrote:
| > 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/wik
| i/OS/2#OS/2_2.1_and_Windows_comp...)
| garaetjjte wrote:
| 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.
| Uvix wrote:
| 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.
| pjmlp wrote:
| 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.
| muth02446 wrote:
| 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.
| freeqaz wrote:
| Hug of death. Anybody got a mirror?
| rusabd wrote:
| https://web.archive.org/web/20240324161517/http://www.emulat...
| dmitrygr wrote:
| This approach was exceptionally well thought-through and it
| shows.
| ack_complete wrote:
| 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.
| dmitrygr wrote:
| The check can be done just once per {destination, sourceArch}
| pair and cached, so overall the amortized impact should be just
| one extra load
___________________________________________________________________
(page generated 2024-03-24 23:00 UTC)