Tango 0.96 beta2 released

kris foo at bar.com
Fri Mar 16 15:33:04 PDT 2007


Frits van Bommel wrote:
[snip]

Thanks for digging into this, Frits

> [Fair warning: this seems to have become a pretty big post]
> Unfortunately, that doesn't work. Specifically because of how Arg is 
> used in "public final uint convert (Sink sink, TypeInfo[] arguments, Arg 
> args, T[] formatStr)":
> -----
> Arg[64] arglist = void;
> foreach (i, arg; arguments)
>     {
>     arglist[i] = args;
>     args += (arg.tsize + int.sizeof - 1) & ~ (int.sizeof - 1);
>     }
> 
> return parse (formatStr, arguments, arglist, sink);
> -----
> Here it looks like it tries to manually extract the arguments, assuming 
> they all lie (on the stack) at int.sizeof boundaries. While this may 
> work on (32-bit?) platforms where varargs are all passed on the stack 
> like x86 with C or D calling convention[1], on amd64 this is not the 
> case: va_list isn't a pointer and the variable arguments aren't 
> necessarily all on the stack.

Aye, it is intended to make each argument indexable. Only works on 
32-bit platform, making the same assumptions as the code in std.stdarg

> 
> Since it seems GDC basically uses the C calling convention, I'll give a 
> short description of the problems I see with it:
> The C(++?) calling convention on amd64[2] passes the first several 
> parameters in registers, and it seems not to deviate from this in case 
> of varargs. Worse, it uses different sets of registers for different 
> types of arguments (6 general-purpose registers for integer types & 
> pointers etc., 8 SSE regs for float/double, and the rest in memory). 
> Aggregates are potentially split up(!) if certain conditions are met (< 
> 16 bytes, all members are naturally aligned, fits entirely into 
> registers, and a few more).

stdarg.d would fail also. That is not good :(

[snip]



More information about the Digitalmars-d-announce mailing list