For the lulz: ddmd vs libdparse lexer timings

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 6 07:42:30 PST 2015


"David Nadlinger"  wrote in message 
news:qzodhfgpknmlbjtnwmqc at forum.dlang.org...

> I'd suggest you have a look at Posix x86_64 first before finalizing the 
> "easy" x86 implementation. The former comes with two extra niceties 
> compared to the simple "pointer to stack-allocated arguments" model:

I know, I had a read of the ABI.  x86 certainly is easy mode.

>   1) You need to copy the registers to the stack on function entry (in 
> case the arguments are later accessed using va_arg, they are just regular 
> functions on the caller side), and then be able to access the address of 
> this area in va_start. This is what va_argsave is currently used for in 
> DMD.

Yes, but __va_argsave is declared in the frontend, which is unnecessary.  It 
was easy enough to make the glue layer reserve the right number of bytes for 
varargs functions.

>   2) The issue with passing va_list as a parameter (especially regarding C 
> ABI compatibility) vs. allocating the struct storage allocation. If you 
> simply make it a pointer on x86_64, it's hard to implement va_copy 
> correctly. The DMD implementation of the latter is currently broken, which 
> is the reason for some of the vararg-related version(X86_64) blocks.

I made it a magic compiler type, and I'll make it automagically pass by ref 
when used as a function argument on X86_64 posix.  That should do it.

> Yes. Some parts might need a bit of rework, though. This job would be 
> quite a bit easier if we could finally ditch the old vararg-based 
> std.format stuff before.
>
> Be sure to let me know if you have any specific questions.

How does LDC currently handle it?  Does llvm have an easy way to handle the 
implementation of va_* for you? 



More information about the Digitalmars-d mailing list