I'm currently working on a few codegen issues in LDC, where I'm not quite sure if I understood the intended ABI for extern(D) on x86_64 correctly:

 - What is the exact specification for returning static arrays by value?

 - What is the ABI for D vararg functions? (extern(D) void foo(…);)

 - What was the reason of explicitly exposing __va_argsave_t instead of going for compiler magic in vararg functions? The latter is what we do in LDC (LLVM provides va_* intrinsics), and it seems to work fine. We obviously try to be compatible to DMD, but I don't quite see why we should move towards an (at least subjectively) worse design: With the DMD implementation, the API is different from C _and_ requires annoying special casing of code for x86_64. Sure, code that relied on directly manipulating the argument pointer on x86 obviously can't work, but a program just using va_start/va_arg/va_end should compile fine on either platform without changes. With DMD, it doesn't.

By the way, http://dlang.org/abi.html seems to be quite outdated, as it still mentions static arrays being passed by reference.

Also related to my current LDC pre-release work, name mangling on OS X: http://d.puremagic.com/issues/show_bug.cgi?id=8207

Thanks,
David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I can't even figure out the ABI on all platforms for IA32, let alone AMD64. Good luck to you, sir.

On 8 June 2012 11:42, David Nadlinger <code@klickverbot.at> wrote:

> I'm currently working on a few codegen issues in LDC, where I'm not quite sure if I understood the intended ABI for extern(D) on x86_64 correctly:
>
>  - What is the exact specification for returning static arrays by value?
>
>  - What is the ABI for D vararg functions? (extern(D) void foo(…);)
>
>  - What was the reason of explicitly exposing __va_argsave_t instead of
> going for compiler magic in vararg functions? The latter is what we do in
> LDC (LLVM provides va_* intrinsics), and it seems to work fine. We
> obviously try to be compatible to DMD, but I don't quite see why we should
> move towards an (at least subjectively) worse design: With the DMD
> implementation, the API is different from C _and_ requires annoying special
> casing of code for x86_64. Sure, code that relied on directly manipulating
> the argument pointer on x86 obviously can't work, but a program just using
> va_start/va_arg/va_end should compile fine on either platform without
> changes. With DMD, it doesn't.
>
> By the way, http://dlang.org/abi.html seems to be quite outdated, as it still mentions static arrays being passed by reference.
>
> Also related to my current LDC pre-release work, name mangling on OS X: http://d.puremagic.com/issues/show_bug.cgi?id=8207
>
> Thanks,
> David
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 8 Jun 2012, at 1:42, David Nadlinger wrote:
> - What is the ABI for D vararg functions? (extern(D) void foo(…);)

From a cursory look at the generated assembly for a few cases, it seems like on x86_64, they are rewritten to a normal (c-style) variadic function with the TypeInfo of the argument type tuple as fixed parameter (the elements of which are later accessible by _arguments) - correct?

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 6/7/2012 4:42 PM, David Nadlinger wrote:
> I'm currently working on a few codegen issues in LDC, where I'm not quite sure if I understood the intended ABI for extern(D) on x86_64 correctly:
>
>  - What is the exact specification for returning static arrays by value?

My intention is to have it work exactly as if it were an equivalent struct, i.e. int[3] would behave as if it were struct S { int a,b,c;}.

>
>  - What is the ABI for D vararg functions? (extern(D) void foo(…);)
>
>  - What was the reason of explicitly exposing __va_argsave_t instead of going for compiler magic in vararg functions? The latter is what we do in LDC (LLVM provides va_* intrinsics), and it seems to work fine. We obviously try to be compatible to DMD, but I don't quite see why we should move towards an (at least subjectively) worse design: With the DMD implementation, the API is different from C _and_ requires annoying special casing of code for x86_64. Sure, code that relied on directly manipulating the argument pointer on x86 obviously can't work, but a program just using va_start/va_arg/va_end should compile fine on either platform without changes. With DMD, it doesn't.

I agree with you, but when I did that I was just trying to get something that worked at all.

>
> By the way, http://dlang.org/abi.html seems to be quite outdated, as it still mentions static arrays being passed by reference.

Yes, more work needs to be done on that.

>
> Also related to my current LDC pre-release work, name mangling on OS X: http://d.puremagic.com/issues/show_bug.cgi?id=8207
>
> Thanks,
> David
>
>
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 8 June 2012 00:42, David Nadlinger <code@klickverbot.at> wrote:
> I'm currently working on a few codegen issues in LDC, where I'm not quite sure if I understood the intended ABI for extern(D) on x86_64 correctly:
>
>  - What is the exact specification for returning static arrays by value?
>
>  - What is the ABI for D vararg functions? (extern(D) void foo(…);)
>
>  - What was the reason of explicitly exposing __va_argsave_t instead of going for compiler magic in vararg functions? The latter is what we do in LDC (LLVM provides va_* intrinsics), and it seems to work fine. We obviously try to be compatible to DMD, but I don't quite see why we should move towards an (at least subjectively) worse design: With the DMD implementation, the API is different from C _and_ requires annoying special casing of code for x86_64. Sure, code that relied on directly manipulating the argument pointer on x86 obviously can't work, but a program just using va_start/va_arg/va_end should compile fine on either platform without changes. With DMD, it doesn't.
>

I chose to put a finger to the system and remove __va_argsave_t from the D frontend completely in gdc (via #ifndef IN_GCC).  Similarly for the va_list type too (which might be void*, but then again for the most popular architechtures, it's not), at the end of the day I'm forced to use the type that the backend defines as the va type, as if I change it everything gets broken in all aspects of backend code generation and backend code checking.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals