On 26 September 2012 16:25, David Nadlinger <s...@klickverbot.at> wrote: > On Wednesday, 26 September 2012 at 12:29:38 UTC, Iain Buclaw wrote: >> >> On 26 September 2012 13:07, monarch_dodra <monarchdo...@gmail.com> wrote: >>> >>> I don't see how the "extern(C)" is involved here, since it is the D >>> compiler >>> that first evaluates A(), B() and C() before passing the making the C >>> function call. Or did I miss something? >>> >> >> There is no physical code generation from the frontend that says >> "evaluate this". What it passes to be backend for this operation is a >> function call. So the backend determines the order of evaluation >> depending on the order of parameters. > > > I'm not quite sure what you are trying to say here; I guess it depends on > the definition of "backend". monarch_dodra is right in so far as the effects > of "extern(C)" are an implementation detail coming from the particular way > your compiler "glue code" is written; there is no fundamental reason why it > should be important for parameter evaluation at all. >
Yes, this is what's done in GDC. All parameters with side effects have their result evaluated and saved before calling the extern(D) functions. > Speaking of it, what is the reason that the actual order of formal > parameters (in terms of register allocation/stack layout) is reversed in the > D calling convention, compared to extern (C) (e.g. on *nix x86_64)? > DMD pushes arguments on the stack in reverse order to that of x86/x86_64. So it gives the *impression* of LTR evaluation, however, the parameters themselves aren't actually explicitly evaluated / saved in temporaries prior to calling. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';