Interesting ARM compatibility - Procedure values?

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

I hadn't really considered having different call conventions, I imagined ARM64EC as using standard Microsoft conventions with a bit to cope with changing the return address by storing it in a saved register when entering ARM or putting space on the stack for saving it when doing a call from ARM. With that the natural thng to do would be pragmas to declare the calling convention if it is any different - and not bother with any special remapping software. Remapping can be a pain I think it's better to just have the compiler cope with the differences.
< Previous 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? 🍊