<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Resending to the real mailing list address...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Charles Davis</b> <span dir="ltr"><<a href="mailto:cdavis5x@gmail.com">cdavis5x@gmail.com</a>></span><br>Date: Thu, Aug 2, 2018 at 5:58 PM<br>Subject: 32-bit pointers and calls from 64-bit code<br>To: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br><br><br><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hello,</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">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.</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">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:</div><div><ul><li><font face="arial, helvetica, sans-serif">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.)</font></li><li><font face="arial, helvetica, sans-serif">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 </font><font face="monospace, monospace">llvm::CallingConv</font><font face="arial, helvetica, sans-serif"> 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...)</font></li><li><font face="arial, helvetica, sans-serif">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.</font></li></ul></div><div style="font-family:arial,helvetica,sans-serif">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.</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">(I will send a similar mail to cfe-dev to discuss C language extensions for this.)</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">Chip</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">* 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.</div></div>
</div><br></div>