llvm dev - Aug 2018 - Fwd: 32-bit pointers and calls from 64-bit code

Resending to the real mailing list address...

---------- Forwarded message ----------
From: Charles Davis <cdavis5x at gmail.com>
Date: Thu, Aug 2, 2018 at 5:58 PM
Subject: 32-bit pointers and calls from 64-bit code
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>


Hello,

With Apple's impending 32-bit deprecation, my new employer is having a bit
of an existential crisis. We think we've found a way forward, but we need a
little help from the compiler to accomplish this.

Basically, what we want to do is have code that is technically x86-64 but
that can use 32-bit pointers and that can make calls to 32-bit code--a bit
like x32, but with the ability to interoperate with real 32-bit code.* So,
here's what we need:

   - An address space for 32-bit pointers. (I wanted to use #32, but I
   suspect that's right out due to the first 256 being reserved for the
user.)
   - A way to make calls and define functions using a 32-bit calling
   convention. And yes, we need to support all of the C, stdcall, fastcall,
   and thiscall conventions. (And maybe vectorcall, too.) I think I should be
   able to reuse the llvm::CallingConv enumerants for real 32-bit code, but
   I'll probably need to define a new one for the 32-bit C convention.
I'll
   then need to implement these for x86-64--this is complicated by the
   differing stack slot sizes between 32-bit and 64-bit code.
   (Understatement...)
   - A way to make a far call--yes, a far call, as in a call with a segment
   and an offset. We need this in order to be able to transition to a 32-bit
   code segment. We may even need to be able to define an arbitrary segment
   selector to use for the call. I'm really not sure how I'm going to do
   this--I'm currently considering a target-specific attribute giving the
   segment base, which should be enough for our purposes.

Questions? Comments? Insinuations that I'm off my rocker? We understand if
you don't want any of this, but note that a large chunk of my employer's
revenue depends on this, so if need be, we'll maintain our own fork. We
would prefer, however, that this be upstreamed.

(I will send a similar mail to cfe-dev to discuss C language extensions for
this.)

Chip

* Yes, we're aware that macOS 10.15 won't even have a 32-bit code
segment.
We've figured out a way around that, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180806/9a30572e/attachment.html>