What is the reason that D uses a different ordering (left->right, right->left)
of parameters for
   - functions/methods having fixed parameter lists (e.g. func(i,j))
   - functions/methods having variable parameter lists (e. g. func(fmt,...)
?

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3E9848DB.BB70783@chello.at...
> What is the reason that D uses a different ordering (left->right,
right->left)
> of parameters for
>    - functions/methods having fixed parameter lists (e.g. func(i,j))

It varies depending on the function type (C, Windows, D, etc.). It's best not to rely on a particular order.

>    - functions/methods having variable parameter lists (e. g.
func(fmt,...)
> ?

For compatibility with C, and the normal way C accesses variable arguments.

On Sat, 12 Apr 2003 13:08:03 -0700, Walter <walter@digitalmars.com> wrote:

> It varies depending on the function type (C, Windows, D, etc.). It's best
> not to rely on a particular order.
>
but when interfacing with separate assembler files, this is critical knowledge in most cases.  after a quick look through the specs, i don't see if it's documented anywhere, which IMHO, is a problem.  if i were to write a snippet of ASM code and needed to call a D function with parameters, how would i do this?

-- 
Charles "grey wolf" Banas

Walter wrote:
> 
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3E9848DB.BB70783@chello.at...
> > What is the reason that D uses a different ordering (left->right,
> right->left)
> > of parameters for
> >    - functions/methods having fixed parameter lists (e.g. func(i,j))
>
> It varies depending on the function type (C, Windows, D, etc.). It's best not to rely on a particular order.

Well, yes, I know.

> >    - functions/methods having variable parameter lists (e. g.
> func(fmt,...)
> > ?
> 
> For compatibility with C, and the normal way C accesses variable arguments.

I understand this.

Still I do not understand the need to have two different orderings within D itself. If there is a single cycle of performance you get out of this, ok.

But otherwise I would refer to Occam's racor not to deviate from C ordering and not to introduce a piece of complexity unneeded.

The way it is makes general fp / dg call interfaces more difficult to construct.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

You certainly can declare your D func as extern(C) and interface it from ASM
as usual C function (BTW, no mangling weirdness and other).
I think it is possible in most cases.

Nic Tiger.

"Charles Banas" <greywolf@greyfade.net> ???????/???????? ? ???????? ?????????: news:oprnj09xca8ctebf@news.digitalmars.com...
> On Sat, 12 Apr 2003 13:08:03 -0700, Walter <walter@digitalmars.com> wrote:
>
> > It varies depending on the function type (C, Windows, D, etc.). It's
best
> > not to rely on a particular order.
> >
> but when interfacing with separate assembler files, this is critical knowledge in most cases.  after a quick look through the specs, i don't
see
> if it's documented anywhere, which IMHO, is a problem.  if i were to write a snippet of ASM code and needed to call a D function with parameters, how would i do this?
>
> --
> Charles "grey wolf" Banas

Helmut Leitner wrote:
> I understand this.
> 
> Still I do not understand the need to have two different orderings
> within D itself. If there is a single cycle of performance you get
> out of this, ok.

Sure, in current mode (if i understood it correctly), when varargs are
used, D uses C calling convention, and when not, a Pascal-like
convention, where the called function cleans up the stack, as opposed to
C, where the caller does. This results in faster calls and less object
code size.

The D calling convention is also subject to change to allow for further
optimisation. To get a well-defined calling convention, use "extern" C
or Pascal option.

-i.

Ilya Minkov wrote:
> 
> Helmut Leitner wrote:
> > I understand this.
> >
> > Still I do not understand the need to have two different orderings within D itself. If there is a single cycle of performance you get out of this, ok.
> 
> Sure, in current mode (if i understood it correctly), when varargs are used, D uses C calling convention, and when not, a Pascal-like convention, where the called function cleans up the stack, as opposed to C, where the caller does. This results in faster calls and less object code size.

I hope to understand the advantage of Pascal calling conventions under certain circumstances. But I think the advantage comes from having a fixed size parameter list, not from ordering the parameters (a,b,c) instead of (c,b,a).

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Charles Banas" <greywolf@greyfade.net> wrote in message news:oprnj09xca8ctebf@news.digitalmars.com...
> On Sat, 12 Apr 2003 13:08:03 -0700, Walter <walter@digitalmars.com> wrote:
>
> > It varies depending on the function type (C, Windows, D, etc.). It's
best
> > not to rely on a particular order.
> >
> but when interfacing with separate assembler files, this is critical knowledge in most cases.  after a quick look through the specs, i don't
see
> if it's documented anywhere, which IMHO, is a problem.  if i were to write a snippet of ASM code and needed to call a D function with parameters, how would i do this?

Two choices:

1) declare the function as extern (C) and write your asm function like it
was connecting to a C function.

2) use the inline assembler, which will get the right stack offsets for the parameters automatically.

On Sun, 13 Apr 2003 14:13:27 -0700, Walter <walter@digitalmars.com> wrote:

>
> Two choices:
>
> 1) declare the function as extern (C) and write your asm function like it
> was connecting to a C function.
>
thank you.  i really should learn to think more in depth.

> 2) use the inline assembler, which will get the right stack offsets for the
> parameters automatically.
>
there are a handful of (obscure) cases where this is neither preferable nor desirable.  though, if the compiler properly inlines, helpful.


-- 
Charles "grey wolf" Banas