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