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