--- (---.delete@this.redheron.com) on July 3, 2021 8:59 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 2, 2021 2:10 pm wrote:
> > Beastian (no.email.delete@this.aol.com) on July 2, 2021 12:47 pm wrote:
> > >
> > > Perhaps the ARM64EC ABI makes it faster and easier to remap parts of the OS to get it
> > > working on different pieces of hardware.
> >
> > I don't follow Windows that closely (maybe not a big surprise), but I'm actually surprised by this
> > news - not because I'd be surprised by the new ARM64EC model, but because I'm surprised by the old
> > WARM model where the ARM64 code was apparently not compatible with the old Windows code.
> >
> > To me it sounds like ARM64EC is what MS should have done from the very start.
> >
> > The whole strength of Windows has always been backwards compatibility. It's
> > hard to overstate how important that has been for Microsoft, from even before
> > Windows existed. That is pretty much the reason to run Windows, after all.
> >
> > So I find it surprising that apparently WARM threw out all the backwards compatibility support and started
> > from a clean fresh slate. I understand the appeal of that, of course, but when your whole business model
> > for decades has been all about backwards compatibility, it's a rather strange decision.
> >
> > And yes, the x86-64 ABI may not be a perfect fit for ARM64,
> > with things like limited register arguments (the
> > Linux x86-64 ABI uses 6 registers, but the MS one uses only
> > 4 - and in both cases the hidden 'this' parameter
> > from C++ code uses the first of those, so you might only see the first three "real" arguments in registers).
> >
> > So on ARM64, there's a natural wish to maybe use more registers for argument passing etc.
> > But particularly if you use LTO, you can still use a more limited "official" calling convention,
> > and then do something else for local calls that aren't externally visible.
> >
> > It's not just the calling convention, of course. The really big thing is things like
> > structure layout etc, so that when you pass pointers around, the data they point to
> > is in the exact same format. It's not just the traditional byte order thing (not an
> > issue), it's very much things like exact alignment rules (and bitfield layout etc).
> >
> > But most of that should be ok in x86-64. The big legacy issue tended to be that 32-bit x86 laid out 64-bit
> > fields as only 32-bit aligned, and it's possible that you see signs of that in the x64 WABI, but not only
> > does ARM64 do ok on unaligned data, I think MS ended up fixing that in the 64-bit x86 ABI.
> >
> > So while perhaps not a perfect fit, I don't think matching the x86-64 ABI
> > should really be all that bad. So making the ARM64 ABI be compatible with
> > it - to make it easy to mix and match - sounds like a no-brainer for MS.
> >
> > So it sounds like ARM64EC really is a good thing. Make it easy
> > to mix and match legacy code, without having to have e
> >
> > (Honesty in advertising: Linux did do a clean slate switch,
> > so it may sound odd that I say that MS should use
> > some compatible ABI - but the difference is that we don't
> > expect to run tons of legacy and mixed apps on ARM
> > in the Linux world, since we generally have source code and thus the legacy ABI is much less of an issue).
> >
> > Linus
>
> When Apple transitioned from 68K to PPC they tried to do the
> same sort of thing. The buzzwords include things like
> Code Fragments (pieces of 68K or PPC code)
> Mixed Mode Manager (handled transitions from one to the other)
> Routine Descriptors and GlobalProcPointers (that could be passed to either type of code
> and knew how to "do the right thing" including different sorts of calling conventions)
>
> This is all covered here:
> https://developer.apple.com/library/archive/documentation/mac/pdf/PPC_System_Software/Intro_to_PowerPC.pdf

Thanks very much for that link. I had been wondering how it would deal with procedure values and callbacks. When doing user mode emulation signal needs a bit of work for instance. However Microsoft are wanting to do something far more ambitious where that should not be a special case - but luckily they're in charge of generating the code.

As far as I can make out the ARM64EC code would have to have every externally visible entry points lead to x64 code - which can then switch to ARM mode. Any use of a procedure variable in the ARM code would have to call a routine that would by default switch to x64 code, or if there is some recognizable descriptor beside the entry point it could enter the ARM code directly without needing two switches. Probably by just seeing that the code there is a call to the switch to ARM routine though it looks like Apple used some more complicated description for some reason.