_argptr woes

[Sean Kelly]

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

Good point.  I think it would also be possible for the compiler to 
detect the addressing of varargs and generate code to push that data 
onto the stack.  This optimization wouldn't be much more difficult than 
codegen for direct-accessing varargs in registers (or so it seems).

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

I figured Walter would write it based on the AMD64 spec and feedback 
from the community.  It probably couldn't be set in stone, however, 
since some issues never seem to be discovered until implementation time.

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

Mine as well.  There is really no reason why the AMD64 spec for D 
shouldn't largely mirror the one for C in terms of parameter passing. 
The rules for register use do seem somewhat complicated, but doing so is 
more efficient than stack operations.  I can see it wreaking havoc with 
naked asm code however.  As it is, I don't use naked asm in extern (D) 
functions because of the optional use of EAX--I can't imagine trying to 
sort out what parameter is where under the new rules.


Sean