_argptr woes

[Sean Kelly]

Frits van Bommel wrote:
> Sean Kelly wrote:
>>
>> So they define an ABI for C to facilitate interoperability across 
>> compilers.  This is laudable, but it has nothing to do with calling D 
>> functions.
> 
> At the moment it does, since GDC 0.23 seems to follow it on amd64...
> (IIRC GDC just passes he context/this pointer (if any) as a hidden first 
> argument, ensuring it'll always be in a register)
> I would wholly support using a slight variation when it comes to varargs 
> though, to put them in a contiguous area on the stack.

Same here.  I'm actually fine with the calling convention otherwise, and 
the D spec doesn't address AMD64 anyway.  A naive translation might be 
to require the first argument in RAX and the rest on the stack, just as 
in x86, but given that there are so many new registers available it does 
seem reasonable to use them.

> It's slightly better in that only one set of registers is used for 
> vararg parameters (vararg floats & doubles are passed in general-purpose 
> registers) but that's about it. This may fix the immediate problem[2] 
> though: parameter location is not so much dependent on type anymore, as 
> long as D's value types remain free of non-trivial copy constructors & 
> destructors. That means it may be possible to determine an argument 
> location based solely on its size and position in the list.

But the argument would still not be addressable, assuming it's a vararg. 
  For D functions, I think it makes sense to follow the AMD64/C calling 
convention for normal function parameters but to always pass varargs on 
the stack.  The alternatives are just too messy from a user perspective.

> Oh, but in order to be able to use this for amd64 you'd also have to 
> define a new register mapping. (Note that IA-64 has *way* more registers 
> than amd64, and seems to do some funky magic with them to rename most of 
> them on calls)

I actually like the IA-64 spec--it has a well-defined memory model and 
seems well considered overall.  But experience has shown that it was too 
big a move for the market.  Still, Intel has retaken control of the 
market with Core, and it seems to be moving towards IA-64 in terms of 
how it works.  But things are interesting everywhere.  SSE128 is even 
coming soon, which should restore high-precision floating point as a 
solid option on new PCs.  FWIW, there is a pretty good discussion of 
upcoming CPU features here:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939

> [2]: At least, I presume this discussion was brought on by the 
> non-portable code in tango.text.convert.Layout?

It was.  That code is correct according to the D spec, but obviously 
doesn't work on GDC/AMD64.  The only reasonable option right now is to 
perform two passes across the vararg list--the first to compute the 
required size for a dynamic buffer, and the second to copy all vararg 
data into that buffer.  This isn't terrible as a temporary fix (perhaps 
wrapped in a version(GCC) block), but it isn't something we really want 
to do as a long-term solution.

I'm beginning to think that some time should be spent on an AMD64 
version of the D ABI, even if GDC is the only compiler it matters for at 
the moment.  In fact, the more I think about this the more I feel that D 
needs another compiler in development for comparison.  I'm starting to 
really wish I had time to play with Microsoft's Phoenix.  Maybe once 
Tango goes 1.0 :-p


Sean