http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #10 from Fawzi Mohamed <fawzi@gmx.ch> 2010-11-29 23:33:33 PST ---
I don't understand why an ldc like approach (caller has to prepare marshalled
array, vararg function is equivalent to (void*,TypeInfo[])) would not work if
typeinfo has align info.

The use of the C ABI is the reason gdc is broken, using it is not possible to loop on arbitrary arguments, all possible arguments should be accounted for at compile time, which defeats much of the purpose of varargs...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #11 from Fawzi Mohamed <fawzi@gmx.ch> 2010-11-30 00:05:15 PST ---
This discussion might be relevant

http://dsource.org/projects/tango/ticket/1042

should the C ABI be used, then one is better off using compile time varargs (maybe using an explicit extra tuple) to build an "old-style" vararg call. Thus I would see no point in doing it, deprecating it would be better.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #12 from nfxjfg@gmail.com 2010-11-30 01:09:11 PST ---
(In reply to comment #9)
> We can revisit this and look into making it more efficient later, but for now I just want to get it working.

It's about ease of use, not efficiency. The C ABI is indeed "disastrously complex". Just look at the code here:

http://www.dsource.org/projects/druntime/browser/trunk/src/core/stdc/stdarg.d

The user has to duplicate that code, if he wants to use TypeInfos to unpack the arguments, instead of using compile time types (that va_start) would require. Now think how that would look like on 64 bits.

If you're going to use the 64 C ABI for D variadics, you may as well completely remove them from D1 and D2.

I don't understand what's so hard about just creating a void*[] on the stack, whose items points to local variables containing the actual argument data. I've done something similar before, when I changed the associative array ABI for by precise GC scanning patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #13 from nfxjfg@gmail.com 2010-11-30 01:19:50 PST ---
PS: passing a void[]* instead of void* would also allow users to build varargs at on the call site.

Backward compatibility with the old way (for D1) can be achieved by naming the void*[] _argarray, and by setting _argptr to _argarray[0], and making the compiler write all arguments in a linear array. (That would be done for transition. The "old" way of traversing args would be declared deprecated.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #14 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-30 07:50:14 PST ---
Should we close this then? Again, for D2 the vararg problem is settled, and I see little reason to put much work on improving D1's varargs only.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #15 from Fawzi Mohamed <fawzi@gmx.ch> 2010-12-02 05:51:36 PST ---
To keep backward compatibility and a working D1 compiler at least for D1, if marshalling is too difficult with the current compiler I would evaluate the effort of creating a hidden variadic template function for each variadic function, that (using a tuple) would pass the stuff following the old convention to the real variadic function defined as taking void*,TypeInfo[]. Then at each calling point after the overload resolution, if the match is for the variadic function one would call the corresponding variadic template function.

As the differences between variadic functions and template functions are just small overloading differences (maybe not any more in D2, I did not check the details), and the possibility to override variadic functions, and those would still work correctly, with such an approach one can keep D1 working also on 64 bit architectures.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #16 from nfxjfg@gmail.com 2010-12-21 20:10:23 PST ---
Here we can see the result of the "old" varargs being ported to 64 bits: http://dsource.org/projects/phobos/changeset/2229

The compiler got more complicated too. Good job, Walter.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #17 from Walter Bright <bugzilla@digitalmars.com> 2010-12-21 20:25:56 PST ---
(In reply to comment #16)
> Here we can see the result of the "old" varargs being ported to 64 bits:
> http://dsource.org/projects/phobos/changeset/2229
> The compiler got more complicated too. Good job, Walter.

It's not even the "old" varargs. I don't think it's possible to support the C varargs correctly with the 64 bit ABI. (Note that gcc does not implement the 64 bit varargs ABI correctly - I had to do a lot of experiments to figure out how it *really* worked.)

We could invent our own ABI for varargs, and it would be simple. But then, we're screwed trying to interoperate with C code that uses varargs.

The 64 bit varargs works tolerably ok, though I'm not thrilled with it. The reason for that changeset is I wished to avoid the varargs-style copying of the argument in order to access it. Much better to point to whereever it is, so the code has to dip under the hood to the dirty underbelly of varargs. Avoiding the copy not only speeds things up, it avoids issues like where/when does the destructor happen on the copy?

To me, the 64 bit varargs ABI looks like a giant mistake that was codified instead of fixed in order to preserve backwards compatibility. (It suggests the original designer tried to do some clever optimizations, but failed to think it through and the result is an inefficient mess.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #18 from nfxjfg@gmail.com 2010-12-21 20:41:46 PST ---
(In reply to comment #17)
> We could invent our own ABI for varargs, and it would be simple. But then, we're screwed trying to interoperate with C code that uses varargs.

The D ABI doesn't need to follow the C ABI, and that includes varargs. Of course the compiler still needs to implement the C ABI for extern(C) functions, but that is nothing a D programmer needs to care about. This issue wasn't about the C ABI at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------