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:
<a href="https://gcc.godbolt.org/z/8aT793GMf" rel="nofollow">https://gcc.godbolt.org/z/8aT793GMf</a><p>This is explained in the docs:
<a href="https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi" rel="nofollow">https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi</a><p>> 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 pretty cool: basically, recent ARM extensions make emulation of just about anything <i>a lot</i> easier.<p>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?<p>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).<p>If I could run VS without tanking battery life, that would be sort-of huge...
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.
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.<p>After reading the end I found the answer … you do have issue for such long career. God blessed.<p>“ 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.”<p>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.<p>0. <a href="https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc">https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/ma...</a>