_argptr woes

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> 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.

I said "slightly" for a reason ;). But I do think this means it may be 
at least *possible* to do it without distinguishing arguments on 
anything other than .tsize() and argument position. Though I may be 
wrong when it comes to aggregate stack-based types, such as 
structs/unions and dynamic array references. If those are split up like 
in the amd64 version, we'd also need TypeInfo to communicate the 
TypeInfo for the fields for this to work.
Of course, for this to be usable in any portable way we'd also need some 
abstraction layer over this that uses TypeInfo instead of template 
arguments, and returns a pointer to memory storing the extracted data. 
That memory would of course have to be allocated somehow. Perhaps 
something like a "void* va_arg()(TypeInfo, inout va_list, void[] buffer 
= null)" overload? (following the idiom I've seen in Tango: an optional 
argument containing a buffer, that's re-allocated if empty or too small)

But a purely stack-based approach when it comes to varargs would seem to 
clearly be superior. At least, on architectures I know of.
If any future architecture (or a current one I'm unaware of) allows, for 
instance, register indexing (i.e. put the contents of register number N 
into r10, where N is the value of rax) then on that architecture it may 
be worth it to use register-based varargs. I don't know if that's likely 
to happen (though I rather doubt it) but for this sort of reason I don't 
think the spec should limit varargs to memory-based calling conventions.
Especially, as I've mentioned quite often by now, since you can't use 
the pointer directly anyway in a portable manner.

>> 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

I never said I didn't like it, just that register renaming seemed a bit 
strange to me. I only read about it today, so I have no idea how well 
this works (nor do I have an IA-64 computer to run benchmarks on :) ) so 
I don't have an opinion on it other than at first sight it looked a bit 
weird...

[snip]
> 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.

This may well be a good idea. But who would write it? If it's David it 
might just become GDC documentation, but if it's Walter or anyone else 
it might be flawed because of inexperience with GCC or general compiler 
internals and/or the amd64 CPU. (nothing personal, just speculating)
To make sure all aspects are thought of, you'd likely need to form a 
committee, but design-by-committee is often a bad idea...

Personally, my first instinct would be to just copy the 32-bit spec 
pretty closely for the data layout, but base the function calling 
convention on the amd64 C one (that GDC currently seems to use) with the 
exception that varargs are passed on the stack.
Though perhaps there could be some modifications made to data layout for 
classes while we're at it.
For one thing, field reordering can decrease space consumption by 
putting fields with larger .alignof at the front (on a per-class basis, 
but perhaps filling up 'holes' at the end of base classes as well).
Also, the implementation of interfaces may merit some thought.

And then there are of course all the areas not documented in the current 
ABI, like the names and signatures of internal functions, RTTI, static 
(~)this(), unit tests, etc.
(interfaces also fall into this category but were already mentioned above)

 > 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

LLVM has also been previously mentioned as an option.