Interesting ARM compatibility - Procedure values?

By: --- (---.delete@this.redheron.com), July 4, 2021 9:42 am
Room: Moderated Discussions
dmcq (dmcq.delete@this.fano.co.uk) on July 4, 2021 3:49 am wrote:
> --- (---.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.

That is essentially correct.
Mac on PPC was essentially a 68K emulator that was capable of executing PPC code fast. ie, like you state, the hosted code could successfully imagine that it was on a 68K, with all the 68K entry points available, and those entry points might then rapidly switch to PPC code for the bulk of the execution.

The reason for the complicated descriptions (the RoutineDescriptors) is that there were multiple different calling conventions on the Mac, and the RoutineDescriptor had to say how to move the registers around to match the calling conventions. This sort of nonsense was common in the 80s, when so much code was written in assembly. There were the obvious Pascal and C conventions, but then groups writing some part of the low-level OS would, for whatever reason, sometimes good sometimes less so, adopt their own idiosyncratic conventions. Some of these were specific to various types of plugins -- perhaps the obvious cases like an interrupt handler or driver, but also less obvious cases like a fragment of code that acted to draw menus or window chrome.
I think in total the RoutineDescriptors covered around 11 different calling conventions, tough it's a long time ago so don't trust that number much!

My guess is that with the Win95 transition already most of the worst of this disappeared from "mainstream" windows, and the rest disappeared with the full 32- and 64-bit transitions. How much of it (ie weird calling convention nonsense) MS has to support depends on how aggressively they want to make these ARM PCs able to run *anything* that currently runs on x86.
I don't know the extent to which MS still supports these weird ideas from the early days of GUIs, like allowing 3rd party apps to provide plugins that draw their own menus or their own window chrome.THAT is what all the complexity is about. There's a second (much less drastic) level of complexity that allows large apps to use third party plugins (the components I discussed earlier, or Photoshop plugins or whatever) but for the most part these use standard calling mechanisms, I assume either COM or some DLL scheme. And of course simplest of all is you have an emulator that just runs the foreign ISA, with no claim that, at any random call, it could switch calling conventions, switch to the native ISA, or other shenanigans.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Interesting ARM compatibility shim for Windows 11Beastian2021/07/01 02:48 PM
  Interesting ARM compatibility shim for Windows 11Groo2021/07/01 03:44 PM
  Interesting ARM compatibility shim for Windows 11Doug S2021/07/01 08:20 PM
    Interesting ARM compatibility shim for Windows 11Mark Roulo2021/07/01 08:28 PM
      Interesting ARM compatibility shim for Windows 11Beastian2021/07/01 09:38 PM
        Interesting ARM compatibility shim for Windows 11Brett2021/07/02 02:45 AM
          Interesting ARM compatibility shim for Windows 11James2021/07/02 05:25 AM
          Interesting ARM compatibility shim for Windows 11dmcq2021/07/02 05:34 AM
          Interesting ARM compatibility shim for Windows 11Gabriele Svelto2021/07/02 09:02 AM
            Interesting ARM compatibility shim for Windows 11Kester L2021/07/02 09:33 AM
              Interesting ARM compatibility shim for Windows 11Jukka Larja2021/07/02 11:36 PM
                Interesting ARM compatibility shim for Windows 11Gabriele Svelto2021/07/03 05:37 AM
                  Interesting ARM compatibility shim for Windows 11Jukka Larja2021/07/03 10:38 AM
                    Interesting ARM compatibility shim for Windows 11Gabriele Svelto2021/07/03 02:07 PM
                Interesting ARM compatibility shim for Windows 11Kester L2021/07/06 07:48 AM
                  Interesting ARM compatibility shim for Windows 11Jukka Larja2021/07/06 10:46 PM
          Don't compare manufacturing unit cost with sales priceMark Roulo2021/07/02 10:07 AM
            Don't compare manufacturing unit cost with sales price---2021/07/02 11:22 AM
              Don't compare manufacturing unit cost with sales priceme2021/07/02 11:32 AM
              Don't compare manufacturing unit cost with sales priceDummond D. Slow2021/07/03 02:11 PM
          Interesting ARM compatibility shim for Windows 11anon2021/07/02 11:26 AM
            Interesting ARM compatibility shim for Windows 11Beastian2021/07/02 12:47 PM
              Interesting ARM compatibility shim for Windows 11Linus Torvalds2021/07/02 02:10 PM
                Optimized local call conventionsanon22021/07/02 07:49 PM
                  Optimized local call conventionsAdrian2021/07/02 10:03 PM
                    Optimized local call conventionsanon22021/07/03 12:10 AM
                      Optimized local call conventionsAdrian2021/07/03 10:04 PM
                  Optimized local call conventionsrwessel2021/07/02 11:44 PM
                    Optimized local call conventionsdmcq2021/07/03 01:47 PM
                  Optimized local call conventionsCarson2021/07/03 06:13 PM
                    Optimized local call conventionsanon22021/07/03 09:18 PM
                      Optimized local call conventionsCarson2021/07/04 01:23 PM
                Interesting ARM compatibility shim for Windows 11---2021/07/03 08:59 AM
                  Interesting ARM compatibility shim for Windows 11joema2021/07/03 10:37 AM
                    Interesting ARM compatibility shim for Windows 11Doug S2021/07/03 12:05 PM
                      Interesting ARM compatibility shim for Windows 11Linus Torvalds2021/07/03 12:26 PM
                        Interesting ARM compatibility shim for Windows 11Doug S2021/07/03 03:45 PM
                          Interesting ARM compatibility shim for Windows 11Michael S2021/07/03 04:54 PM
                          Interesting ARM compatibility shim for Windows 11-.-2021/07/04 06:57 AM
                            Interesting ARM compatibility shim for Windows 11---2021/07/04 09:25 AM
                            Interesting ARM compatibility shim for Windows 11Doug S2021/07/05 09:34 AM
                      Interesting ARM compatibility shim for Windows 11Foo_2021/07/04 02:25 AM
                        Interesting ARM compatibility shim for Windows 11Doug S2021/07/04 05:18 AM
                          Interesting ARM compatibility shim for Windows 11Jukka Larja2021/07/04 05:47 AM
                            Ongoing Windows 16 bit supportJames2021/07/05 02:17 AM
                              Ongoing Windows 16 bit supportgai2021/07/05 08:35 AM
                                Ongoing Windows 16 bit supportJukka Larja2021/07/05 11:11 PM
                          Interesting ARM compatibility shim for Windows 11Foo_2021/07/04 06:31 AM
                          Microsoft should drop x86 thinking...Dummond D. Slow2021/07/04 07:40 AM
                            Microsoft should drop x86 thinking...Doug S2021/07/05 09:56 AM
                              Microsoft should drop x86 thinking...Brett2021/07/05 01:47 PM
                                "DOOMED"Anon2021/07/06 01:01 AM
                                  "DOOMED"Michael S2021/07/06 03:15 AM
                                    "DOOMED"dmcq2021/07/06 04:08 AM
                                      "DOOMED"me2021/07/06 04:57 AM
                                      "DOOMED"Michael S2021/07/06 05:09 AM
                                        "DOOMED"Anon2021/07/06 05:50 AM
                                          "DOOMED"Michael S2021/07/06 06:29 AM
                                  "DOOMED"Doug S2021/07/06 08:41 AM
                                    "DOOMED"Jukka Larja2021/07/06 10:55 PM
                                      "DOOMED"Doug S2021/07/07 12:21 AM
                                Forgot about AMD?Chester2021/07/06 08:51 AM
                                dumb terminalsanonymous22021/07/06 10:51 AM
                              Microsoft should drop x86 thinking...Dummond D. Slow2021/07/06 06:40 AM
                  Interesting ARM compatibility - Procedure values?dmcq2021/07/04 03:49 AM
                    Interesting ARM compatibility - Procedure values?dmcq2021/07/04 04:18 AM
                      Interesting ARM compatibility - Procedure values?Etienne Lorrain2021/07/05 01:21 AM
                        Interesting ARM compatibility - Procedure values?dmcq2021/07/06 03:20 AM
                    Interesting ARM compatibility - Procedure values?---2021/07/04 09:42 AM
                      Interesting ARM compatibility - Procedure values?dmcq2021/07/04 02:44 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell tangerine? 🍊