GNAT parameter passing, C-style?

GNAT parameter passing, C-style?

[Luke A. Guest]

Hi,

I've just written a program to prove it, but am I correct in saying that
the GNAT procedure/function calling mechanism is to pass parameters from
right-to-left (C-style), rather than left-to-right (PASCAL-style)?

I was also wondering if there is an Ada standard way to changing the
mechanism? Or this compiler specific?

Thanks,
Luke.

Re: GNAT parameter passing, C-style?

[Marin David Condic]

You're talking about the ordering of parameters as they are pushed on 
the stack? I know of no mechanism to control that in the Ada standard 
and I doubt that the standard could possibly specify anything that is 
such a low level implementation detail. What about machines with large 
register sets? Compilers would want to optimize by putting parameters in 
registers and that might mess up the order you think you're getting. 
Different platforms will have different parameter passing mechanisms and 
conventions.

What you refer to as "C-Style" and "Pascal-Style" is probably misleading 
as well. What C compiler on what platform? Likewise for Pascal? AFAIK, 
there is no requirement in C or Pascal to use any particular mechanisms 
for parameter passing (beyond C allowing you to specify that something 
should live in a register.) If you had two different compiler writers 
working on two different platforms, you'd likely get two different 
mechanisms for parameter passing. Should the stack pointer increment or 
decrement as it puts items on the stack? It depends - what's the 
convention on the processor, OS, 
other-compilers-you-wish-to-be-compatible-with combinations? Does the 
machine even have a stack pointer?

If there is any such thing as an Ada mechanism, it would be through the 
pragmas for interfacing to other languages. Indicating that you are 
calling (or being called from) a C program should try to enforce C 
conventions. But there is no one, single "C-Style" anyway, so you'd have 
to know if your Ada compiler lined up with a particular C compiler. With 
Gnat, it is both an Ada and a C compiler, so it is likely to be 
consistent with itself. But Gnat couldn't promise you compatibility with 
someone else's C compiler.

MDC


Luke A. Guest wrote:
> Hi,
> 
> I've just written a program to prove it, but am I correct in saying that
> the GNAT procedure/function calling mechanism is to pass parameters from
> right-to-left (C-style), rather than left-to-right (PASCAL-style)?
> 
> I was also wondering if there is an Ada standard way to changing the
> mechanism? Or this compiler specific?
> 
> Thanks,
> Luke.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Marin David Condic wrote:
> What you refer to as "C-Style" and "Pascal-Style" is probably misleading 
> as well.

In an older, simpler world, Pascal pushed its arguments left-to-right and
the called routine popped the stack, while C pushed its arguments right-to-
left and the calling routine popped the stack. The C way allows for easy
handling of variable sized argument lists, and for the caller not to care
how many arguments the called routine expects and for the called routine
not to care how many arguments it was actually called with.

Re: GNAT parameter passing, C-style?

[Marin David Condic]

My point is that there isn't such a thing as "Pascal" or "C" in this 
respect. There's only some specific *implementation* of Pascal or C. If 
you had a Pascal interpreter, it might not be doing anything with 
pushing and popping parameters on a stack - at least not in any way that 
the programmer could hope to control. Someone could write a C compiler 
that wrote its parameters out to paper tape starting from the middle and 
alternating left and right - why? Maybe just to prove it could be done. 
Implementations on unusual architectures might do unusual things and it 
is an error in thinking that C or Pascal or Ada passes parameters in any 
specific way when there is nothing in the language definition to give 
one reason to think so.

We often seem to see this kind of misunderstanding - that someone's 
experience with one specific implementation (or even several common 
implementations) starts becoming "Ada does this..." or "C does that..." 
when in reality it is "This particular version of this particular 
compiler for this particular language on this particular platform - does 
this..." There is no rule that I know of that dictates that C, Pascal or 
Ada must evaluate and stack up parameters in some specific order, nor, 
AFAIK, was there ever any validation suite to insure that they did. Any 
presumption that it will be done one way or another is thus quite 
misleading.

MDC


Hyman Rosen wrote:
> 
> In an older, simpler world, Pascal pushed its arguments left-to-right and
> the called routine popped the stack, while C pushed its arguments right-to-
> left and the calling routine popped the stack. The C way allows for easy
> handling of variable sized argument lists, and for the caller not to care
> how many arguments the called routine expects and for the called routine
> not to care how many arguments it was actually called with.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Fri, 26 Dec 2003 15:07:03 +0000, Marin David Condic wrote:

> We often seem to see this kind of misunderstanding - that someone's 
> experience with one specific implementation (or even several common 
> implementations) starts becoming "Ada does this..." or "C does that..." 

It's not a misunderstanding, it's part of the C standard spec and
compilers still do it. Some compilers do put their parameters into
registers, on some machines with some compilers, they start in registers
and then carry on into the stack. The only platform I ever saw that always
used registers (unless it ran out of them) was the AmigaOS and any
compiler that could take in the #?.fd files and make direct calls to the
libraries based on these specs.

Now, with that in mind, I have found it in the Ada RM and you can use the
convention pragma to control it, although with GNAT under Linux it's
generated code doesn't seem to change. This is also probably due to the
fact that it's part of GCC and maybe the backend always tries to generate
C-like calling convention. Under different Ada compilers this might be
different, I don't know.

Luke.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Luke A. Guest wrote:
> It's not a misunderstanding, it's part of the C standard spec

What is "the C standard spec"? It's definitely not the C standard,
which is much too high-level to talk about parameter passing mechanisms.
But it may be part of many platform ABIs.

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Fri, 26 Dec 2003 12:03:19 -0500, Hyman Rosen wrote:

> Luke A. Guest wrote:
>> It's not a misunderstanding, it's part of the C standard spec
> 
> What is "the C standard spec"? It's definitely not the C standard,
> which is much too high-level to talk about parameter passing mechanisms.
> But it may be part of many platform ABIs.

Just going by the K&R book. As I remember it, it's in there.

Luke.

Re: GNAT parameter passing, C-style?

[Martin Krischik]

Luke A. Guest wrote:

> On Fri, 26 Dec 2003 15:07:03 +0000, Marin David Condic wrote:
> 
>> We often seem to see this kind of misunderstanding - that someone's
>> experience with one specific implementation (or even several common
>> implementations) starts becoming "Ada does this..." or "C does that..."
> 
> It's not a misunderstanding, it's part of the C standard spec and
> compilers still do it.

No. IBM and Microsoft for example went to what you call "Pascal" convention
when moving from 16bit to 32bit for OS and Compiler. They only use "C"
convention when you explicitly request it. Or when a variable parameter
list is used.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Fri, 26 Dec 2003 17:08:27 +0000, Luke A. Guest wrote:

> On Fri, 26 Dec 2003 12:03:19 -0500, Hyman Rosen wrote:
> 
>> Luke A. Guest wrote:
>>> It's not a misunderstanding, it's part of the C standard spec
>> 
>> What is "the C standard spec"? It's definitely not the C standard,
>> which is much too high-level to talk about parameter passing mechanisms.
>> But it may be part of many platform ABIs.
> 
> Just going by the K&R book. As I remember it, it's in there.

Just checked in there, but couldn't see it. Can't remember where I saw it
then. Maybe it was a compiler book?

Luke.

Re: GNAT parameter passing, C-style?

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
:  With 
: Gnat, it is both an Ada and a C compiler, so it is likely to be 
: consistent with itself. But Gnat couldn't promise you compatibility with 
: someone else's C compiler.

However, the GNAT User's Guide has something to say about
calling conventions and the stack at least wrt the different
calling conventions on Windows systems.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote
in message
news:pan.2003.12.26.17.27.26.494317@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk...
> On Fri, 26 Dec 2003 17:08:27 +0000, Luke A. Guest wrote:
> Just checked in there, but couldn't see it. Can't remember where I saw it
> then. Maybe it was a compiler book?

I don't believe it was stated explicitly, but the standard C calling
convention (arguments pushed on the stack in reverse order, and popped off
by the callee) is implied by the requirements for variable argument
functions. Even with C++, the C calling convention is still used for any
function / method that takes a variable list of arguments, i.e. with "..."
in its parameter list. Of course, it is also strongly recommended that you
avoid variable argument lists in C++.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1083935.L00VuFytUj@linux1.krischik.com...
> Luke A. Guest wrote:
>
> No. IBM and Microsoft for example went to what you call "Pascal"
convention
> when moving from 16bit to 32bit for OS and Compiler. They only use "C"
> convention when you explicitly request it. Or when a variable parameter
> list is used.

That's not quite correct. The 16-bit Windows API used the Pascal calling
convention for every function that did not have a variable parameter list.
In the Win32 API, Microsoft used the STDCALL calling convention for all
functions that did not have a variable parameter list. The STDCALL
convention was a mix of the Pascal and C conventions: the parameters were
pushed on the stack in reverse order (i.e. the C order), but they were
popped by the called function (as in Pascal).

As to the compiler, there are command line options that specify what calling
convention is used for a function when no convention is indicated in the
code. In the absense of said command line parameters and any specification
of calling conventions in the code, the default convention is C (parameters
pushed in reverse order, and popped by the caller).

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> wrote in message
news:3fec7c21$0$4764$61fed72c@news.rcn.com...
> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote
> in message
>
news:pan.2003.12.26.17.27.26.494317@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk...
> > On Fri, 26 Dec 2003 17:08:27 +0000, Luke A. Guest wrote:
> > Just checked in there, but couldn't see it. Can't remember where I saw
it
> > then. Maybe it was a compiler book?
>
> I don't believe it was stated explicitly, but the standard C calling
> convention (arguments pushed on the stack in reverse order, and popped off
> by the callee) is implied by the requirements for variable argument

I should have said "... and popped off by the caller". My mistake, and I
cannot blame my spell checker for this one.

> functions. Even with C++, the C calling convention is still used for any
> function / method that takes a variable list of arguments, i.e. with "..."
> in its parameter list. Of course, it is also strongly recommended that you
> avoid variable argument lists in C++.
>
>

Re: GNAT parameter passing, C-style?

[Marin David Condic]

I don't recall seeing it in K&R - but I'll take your word for it since I 
don't have a copy handy to check. Its still not the same as "The 
language defines you *must* do it this way and there is a validation 
suite to prove you did it..." It would almost have to fall under the 
category of "Implementation Advice" since there may be architectures or 
OS's or needs to interface with other compiler's outputs that might make 
any given mechanism difficult or impossible.

MDC


Luke A. Guest wrote:
> 
> Just going by the K&R book. As I remember it, it's in there.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Keith Thompson]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote
> in message
> news:pan.2003.12.26.17.27.26.494317@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk...
> > On Fri, 26 Dec 2003 17:08:27 +0000, Luke A. Guest wrote:
> > Just checked in there, but couldn't see it. Can't remember where I saw it
> > then. Maybe it was a compiler book?
> 
> I don't believe it was stated explicitly, but the standard C calling
> convention (arguments pushed on the stack in reverse order, and popped off
> by the callee) is implied by the requirements for variable argument
> functions.
[...]

No, it isn't.  In standard C, functions with variable argument lists
have a special syntax ("..."), and don't have to use the same calling
conventions as other functions.  In the body of such a function, it
accesses its arguments using special macros defined in the header
<stdarg.h>; these macros can do whatever compile-specific magic is
necessary.

In pre-standard "K&R" C, it was permissible to call a function with a
variable argument list with no visible declaration of the function;
making this work properly did place some constraints on the callng
conventions.  The ISO C standard was designed to remove these
constraints.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnekul8ewd.fsf@nuthaus.mib.org...
> "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> > I don't believe it was stated explicitly, but the standard C calling
> > convention (arguments pushed on the stack in reverse order, and popped
off
> > by the callee) is implied by the requirements for variable argument
> > functions.
> [...]
>
> No, it isn't.  In standard C, functions with variable argument lists
> have a special syntax ("..."), and don't have to use the same calling
> conventions as other functions.  In the body of such a function, it
> accesses its arguments using special macros defined in the header
> <stdarg.h>; these macros can do whatever compile-specific magic is
> necessary.

In vanilla (i.e. original K&R) C, there are no argument lists in function
declarations. For that matter, vanilla C does NOT even require functions
declarations. If an undeclared function is called in vanilla C, the
unconverted argument list is assumed to be OK, the calling convention is
assumed to be C, and it is assumed that the function returns an int.

ANSI C depreciates this loose approach to functions. ANSI C strongly
encourages the full declaration of all functions used, including argument
lists. For compatability, however, ANSI C accepts function declarations with
no argument lists (e.g. "double sin();"), as well as the calling of
undeclared functions. Since there is no requirement that the user will
declare a function's argument list (or the function for that matter), a C
compiler may not be able to tell whether a function accepts a variable
argument list or not. For that reason, C compilers have to assume the C
calling convention, unless the user indicates via declaration or command
line options.

Every C compiler that I have worked with uses the C calling convention by
default when compiling C (as opposed to C++) code. If you know of a C
compiler that works differently, please post the details. I'm not saying
this because out of fondness for the C calling convention. Although this
convention is required to handle variable argument lists, it is less
efficient for the vast majority of cases where the function has a fixed
parameter list.

Fortunately, C++ has resolved this problem by making a clean break from
vanilla C. They do require that functions must be declared, including its
parameter list, for it to be used. The compiler can always determine if a
function has a variable argument list, and hence can (and does) reserve the
C calling conventions for only those functions that require it.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
> For that reason, C compilers have to assume the C calling convention,
 > unless the user indicates via declaration or command line options.

No, this is false. The C Standard essentially says that when you call a
function without a prototype, the compiler constructs one for you based
on the parameters you are supplying in the call. If this constructed
prototype is not compatible with the definition of the function, then the
program has undefined behavior.

(This is jokingly referred to as the Miranda rule: You are entitled to a
prototype. If you do not supply one, one will be provided for you.)

Functions with variable argument lists must be prototyped before they are
called, or again the results are undefined.

The upshot is that even when calling a function without a prototype, the
compiler may pass arguments any way it likes, and it is absolutely not
required to "push" them onto a "stack" in any particular order.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072883131.278899@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
> The upshot is that even when calling a function without a prototype, the
> compiler may pass arguments any way it likes, and it is absolutely not
> required to "push" them onto a "stack" in any particular order.

It may not be required by the standard, but it is required to support legacy
code. Certainly any C code written after ANSI C became widely available
should use prototypes, but for many years there was plenty of maintained K&R
C code written like this:

    extern int futz();
    {
        ...
        if ( futz( name, count ) ) ...
    }

where there is no indication as to whether or not the function takes a
variable argument list. You can argue all you want that a compiler is not
required to generate correct code for such a program, but the sheer weight
of legacy code forces the compiler manufactures to not break code like this.

I go back to my original question: does anyone know of a C compiler which,
when compiling C (not C++) does not default to the C calling convention
(i.e. arguments pushed on the stack in reverse order, and popped off by
calling function) in the absence of any indication of another convention?
The two C compilers I am currently using (GCC version 3.3.1, MSVC Version 6)
both default to the C convention. I recall that every Borland compiler up to
4.0 defaulted to the C convention as well, as did the early Zortech /
Symantec compilers.

Again, I am not saying this out of fondness for the C calling convention.
The original K&R specification, unfortunately, forced the undesirable use of
this convention for many years. The C++ people should be congraduated for
making a bold enough break from the past to eliminate almost all need for
this convention.

I should also note that this has never been an issue in Ada. (This is an Ada
newsgroup, after all).

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
> I go back to my original question: does anyone know of a C compiler which,
> when compiling C (not C++) does not default to the C calling convention
> (i.e. arguments pushed on the stack in reverse order, and popped off by
> calling function) in the absence of any indication of another convention?

Certainly. Here's partial output of such code compiled on a Sun
with the simple invocation 'cc -S g.c'. As you can see, arguments
are passed in registers and processed left-to-right.

main:
     save    %sp,-104,%sp
.L15:
! File g.c:
!    1  extern int f();
!    2  int main()
!    3  {
!    4      return f(1, 2.0, 3, 4.0);
     mov 1,%o0
     sethi   %hi(.L_cseg0),%l0
     or  %l0,%lo(.L_cseg0),%l0
     ldd [%l0+0],%f2
     mov 3,%o3
     ldd [%l0+8],%f4
     std %f2,[%sp+88]
     ld  [%sp+88],%o1
     ld  [%sp+92],%o2
     std %f4,[%sp+88]
     call    f
     ldd [%sp+88],%o4
     ba  .L14
     mov %o0,%l0

     ! block 2
.L14:
     mov %l0,%i0
     jmp %i7+8
     restore

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072891494.595791@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
> > I go back to my original question: does anyone know of a C compiler
which,
> > when compiling C (not C++) does not default to the C calling convention
> > (i.e. arguments pushed on the stack in reverse order, and popped off by
> > calling function) in the absence of any indication of another
convention?
>
> Certainly. Here's partial output of such code compiled on a Sun
> with the simple invocation 'cc -S g.c'. As you can see, arguments
> are passed in registers and processed left-to-right.

Thanks for the example. This is a case where I'm glad to be proved wrong,
for it always seemed wasteful to force the C calling convention when it is
not necessary.

Does the Sun compiler have a command line option for compiling vanilla C
programs? This would an ideal solution to handling both legacy and ANSI C
code.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
> Does the Sun compiler have a command line option for compiling vanilla C
> programs? This would an ideal solution to handling both legacy and ANSI C
> code.

This is vanilla C for that platform. Varargs functions are called the
same way. The function itself will then muck about with the registers as
needed to make things work.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072899508.453543@master.nyc.kbcfp.com...
> This is vanilla C for that platform. Varargs functions are called the
> same way. The function itself will then muck about with the registers as
> needed to make things work.

Now I get it! The problem is that I have spent most of my career with the
Intel architecture, where the paucity of registers preclude any extensive
use of registers for parameter passing. Of course, passing parameters by
registers avoids all of these issues, since nothing is pushed onto or popped
off the stack.

Thanks for the clarification.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
 > Of course, passing parameters by registers avoids all of these issues,
 > since nothing is pushed onto or popped off the stack.

On the contrary, using registers exacerbates these issues, since
there can never be enough registers to hold all possible arguments.
If you call a function with enough parameters, eventually there will
be too many to fit, and the remaining arguments will be passed on the
stack. The "stdarg.h" header is meant to be implementation magic; the
compiler knows all about the particular paramater passing scheme, and
will fix things up as needed to make it all work.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072906542.723974@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
>  > Of course, passing parameters by registers avoids all of these issues,
>  > since nothing is pushed onto or popped off the stack.
>
> On the contrary, using registers exacerbates these issues, since
> there can never be enough registers to hold all possible arguments.
> If you call a function with enough parameters, eventually there will
> be too many to fit, and the remaining arguments will be passed on the
> stack. The "stdarg.h" header is meant to be implementation magic; the
> compiler knows all about the particular paramater passing scheme, and
> will fix things up as needed to make it all work.

To be more precise, for functions with only a few arguments, these issues do
not arise. I am curious, however, as to how the Sun compiler handles
parameter lists long enough to exhaust available registers. My guess is that
those parameters not passed via registers are pushed on the stack in reverse
order, and are popped off by the calling function.

I'm also curious as to how the Sun version of <stdarg.h> handles a
combination of register and stack parameters. I imagine that they must use
some implementation-specific extension to implement <stdarg.h>.

Re: GNAT parameter passing, C-style?

[Marin David Condic]

This was my original point. AFAIK, there is no *requirement* that the 
parameters be put on a stack in any particular order - or even that 
there must be a "stack". A given machine might scrawl its parameters on 
a piece of paper with a pen plotter in Chinese characters from bottom to 
top and read them back in via scanner & OCR program reading right to 
left. So long as the parameters end up in the subroutine, the *standard* 
doesn't care how they got there. Hence no reason to believe there is a 
"C Method" or a "Pascal Method" of passing parameters.

We need to remember this or we muddy the waters when discussing what is 
required for Ada vs any other language.

MDC


Hyman Rosen wrote:
> 
> The upshot is that even when calling a function without a prototype, the
> compiler may pass arguments any way it likes, and it is absolutely not
> required to "push" them onto a "stack" in any particular order.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Wed, 31 Dec 2003 20:47:02 +0000, Frank J. Lhota wrote:

> Now I get it! The problem is that I have spent most of my career with the
> Intel architecture, where the paucity of registers preclude any extensive
> use of registers for parameter passing. Of course, passing parameters by
> registers avoids all of these issues, since nothing is pushed onto or popped
> off the stack.

Yes, and if platforms such as the Amiga had prevailed, the braindead x86
with their crap register(s &) usage would've made the future of CPU's a
nicer place to work in (more registers that just made sense).

Anyone familiar with the Amiga or any decent modern CPU knows what I'm
talking about. I like having functions where a minimal (if at all) stack
is allocated.

Luke.

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Wed, 31 Dec 2003 16:35:42 -0500, Hyman Rosen wrote:

> On the contrary, using registers exacerbates these issues, since
> there can never be enough registers to hold all possible arguments.
> If you call a function with enough parameters, eventually there will
> be too many to fit, and the remaining arguments will be passed on the
> stack. The "stdarg.h" header is meant to be implementation magic; the
> compiler knows all about the particular paramater passing scheme, and
> will fix things up as needed to make it all work.

Although you *can* have functions with the right number of arguments that
fit to a small number of registers, but as time goes by, management
dictates what is a good programming standard (these idiots know nothing
and this is why we still have to deal with CPU's with a possible 4
available registers at any one point! On x86 crap anyways!)

Plus the as the size of software (that hasn't been designed properly)
grows the fact that the number of registers is reduced it true :-(

Luke.

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Wed, 31 Dec 2003 21:50:59 -0500, Frank J. Lhota wrote:


> To be more precise, for functions with only a few arguments, these issues do
> not arise. I am curious, however, as to how the Sun compiler handles
> parameter lists long enough to exhaust available registers. My guess is that
> those parameters not passed via registers are pushed on the stack in reverse
> order, and are popped off by the calling function.
> 
> I'm also curious as to how the Sun version of <stdarg.h> handles a
> combination of register and stack parameters. I imagine that they must use
> some implementation-specific extension to implement <stdarg.h>.

This is interesting considering the SPARC's register windows (at any one
point there is 32 register available to a function, FPU registers are not
even considered). But as I remember, it's ther same again, if the
registers run out the stack is used in reverse as usual.

Luke.

Re: GNAT parameter passing, C-style?

[Luke A. Guest]

On Thu, 01 Jan 2004 03:38:13 +0000, Marin David Condic wrote:

> doesn't care how they got there. Hence no reason to believe there is a 
> "C Method" or a "Pascal Method" of passing parameters.

Well, for every processor that I have used there is a similar (or same)
method of allocating space for parameters. I have noticed as time goes by
that more registers were used, but when we talk of the (braindead) x86 we
need to step back 20 years, as the CPU's of the time were more advanced and
the conventions that were being proposed were also becoming irrelevant as
the x86 was becoming more accepted.

I worked originally on the Amiga where the convention was to use the
registers (and hence not to create a new stack frame on every call), we
have stepped back 20 years (wrt x86) by having to provide a limited set of
parameters in registers (4 or 5 - if not less) and then to provide
everything else in stack.

So, as far as I am concerned there is still a C & PASCAL convention, it's
just a matter of how the compiler works I suppose.

Luke.

Re: GNAT parameter passing, C-style?

[Marin David Condic]

It may very well be the common way it is done on most - or even all - 
implementations of C and Pascal. But that is saying something very 
different from a claim that it is part of the language. And if it is not 
a defined part of the language, it means an implementation is free to do 
it any way they want. Hence it cannot be counted on as *always* being 
true of a conforming implementation - and programmers are often mislead 
by that sort of misunderstanding.

I remember many years ago discussing Ada and portability with another 
programmer. She said that she was going to recommend to her boss that 
the next development be done in C because Ada's I/O wasn't portable. I 
wanted to know why she thought that was true and she showed me the code 
they were working on. Their project was making use of Digital Equipment 
Corporation's "Starlet" package for I/O and she was concluding from this 
fact that Ada didn't have portable I/O. I hauled out the RM and showed 
her Text_IO, etc., and found the C interface to Starlet and tried to 
explain that Ada *did* have portable I/O - just that her project wasn't 
making use of it and it was no different for C. I think she understood 
at that point, but she looked a little unconvinced.

Lots of programmers travel on bad or misleading information about 
programming languages. Most of them are not exactly Rocket Scientists 
(I'll be glad to help them in that respect! :-) and all they know is 
what they see in their day-to-day work with one specific implementation 
of a language. (Experiment: Pick some feature of the MFC that is not 
part of C++ and is unique to MFC. Ask a dozen programmers who use MSVC++ 
"Does C++ have feature X?" Bet money most will say "Yes") It is exactly 
this sort of misunderstanding that leads your garden variety programmer 
to conclude "Ada is inherently slow because all implementations I've 
seen are slow..." or "Ada isn't able to do civilian programming since it 
was built for the military" That's why I get overly cautious with claims 
like "C passes parameters this way..." when there isn't any such 
requirement in the C standard.

MDC



Luke A. Guest wrote:
> 
> So, as far as I am concerned there is still a C & PASCAL convention, it's
> just a matter of how the compiler works I suppose.
> 
> Luke.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Luke A. Guest wrote:
> But as I remember, it's ther same again, if the
> registers run out the stack is used in reverse as usual.

Even if parameters are passed on the stack, there is no need
to process the arguments from right to left. You can just
subtract the appropriate amount from the stack pointer and
then fill in that space by processing the arguments from left
to right.

Re: GNAT parameter passing, C-style?

[Jeff C,]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3FF42BE4.6080607@noplace.com...
>
> Lots of programmers travel on bad or misleading information about
> programming languages. Most of them are not exactly Rocket Scientists
> (I'll be glad to help them in that respect! :-) and all they know is
> what they see in their day-to-day work with one specific implementation
> of a language. (Experiment: Pick some feature of the MFC that is not
> part of C++ and is unique to MFC. Ask a dozen programmers who use MSVC++
> "Does C++ have feature X?" Bet money most will say "Yes") It is exactly

It is also worth pointing out that if you monitor the c++ newsgroups these
same topics
come up there all the time with people confusing what some particular
implementation
of some language does with what is required or even common in the language.

By the way, Rocket Scientists are no better in this respect then the rest of
the population.
Trust me.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:bAXIb.28439$tY5.3073@nwrdny01.gnilink.net...
> Even if parameters are passed on the stack, there is no need
> to process the arguments from right to left. You can just
> subtract the appropriate amount from the stack pointer and
> then fill in that space by processing the arguments from left
> to right.

The problem, again, is with variable argument lists. For functions with
variable argument lists, such as like printf and fprintf , the "appropriate
amount" will vary from call to call. In any such function, there are one or
more fixed parameters, from which one can the number and type of the
remaining parameters. Before we can determine the size of the argument
block, we must be able to retrieve the first few arguments. Given the "Last
in, First out" nature of a stack, the easiest way to do that is to push the
parameters on the stack in reverse order. With printf, for example, the
format string is the last parameter pushed on the stack. Within printf, the
format string is at the top of the stack, and it can be used to determine
the rest of the parameters.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
> For functions with variable argument lists the "appropriate amount"
 > will vary from call to call.

Cetainly, but the caller always knows how much that is. For a call like
     f(1, 2, 3)
the caller can do (on the COBOL Processor(tm) :-)
     subtract 3 from stack_pointer
     move 1 to stack_pointer[1]
     move 2 to stack_pointer[2]
     move 3 to stack_pointer[3]
     call f
     add 3 to stack_pointer
There's no need at all to process the parmeters from right to left.

Re: GNAT parameter passing, C-style?

[Jano]

Frank J. Lhota dice...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1072899508.453543@master.nyc.kbcfp.com...
> > This is vanilla C for that platform. Varargs functions are called the
> > same way. The function itself will then muck about with the registers as
> > needed to make things work.
> 
> Now I get it! The problem is that I have spent most of my career with the
> Intel architecture, where the paucity of registers preclude any extensive
> use of registers for parameter passing. Of course, passing parameters by
> registers avoids all of these issues, since nothing is pushed onto or popped
> off the stack.

I remember from my days of assembler of some compiler which used 
frequently the AX register for the first parameter and function results. 
Though it was maybe a Pascal compiler %-)

Just a curiosity.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:o6YIb.8353$x34.4946@nwrdny02.gnilink.net...
> Frank J. Lhota wrote:
> > For functions with variable argument lists the "appropriate amount"
>  > will vary from call to call.
>
> Cetainly, but the caller always knows how much that is. For a call like
>      f(1, 2, 3)
> the caller can do (on the COBOL Processor(tm) :-)
>      subtract 3 from stack_pointer
>      move 1 to stack_pointer[1]
>      move 2 to stack_pointer[2]
>      move 3 to stack_pointer[3]
>      call f
>      add 3 to stack_pointer
> There's no need at all to process the parmeters from right to left.

Yes, but what about the callee?

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.1a5e7497a07ca7709897ad@News.CIS.DFN.DE...
> Frank J. Lhota dice...
> > "Hyman Rosen" <hyrosen@mail.com> wrote in message
> > news:1072899508.453543@master.nyc.kbcfp.com...
> > > This is vanilla C for that platform. Varargs functions are called the
> > > same way. The function itself will then muck about with the registers
as
> > > needed to make things work.
> >
> > Now I get it! The problem is that I have spent most of my career with
the
> > Intel architecture, where the paucity of registers preclude any
extensive
> > use of registers for parameter passing. Of course, passing parameters by
> > registers avoids all of these issues, since nothing is pushed onto or
popped
> > off the stack.
>
> I remember from my days of assembler of some compiler which used
> frequently the AX register for the first parameter and function results.
> Though it was maybe a Pascal compiler %-)
>
> Just a curiosity.

There is still a x86 convention that functions returning integers return
them in AX / EAX.

Re: GNAT parameter passing, C-style?

[tmoran]

>Yes, and if platforms such as the Amiga had prevailed, the braindead x86
>with their crap register(s &) usage would've made the future of CPU's a
>nicer place to work in (more registers that just made sense).
  Yes, and if platforms such as the B5500 had prevailed, we wouldn't be
worrying about assembly language programming.
  If you have memory bandwidth to burn, but few CPU transistors, you
should make the compiler or programmer decide what to put in which
temporary storage for how long, and give them extra address bits to
specify that storage (ie, registers).  OTOH, if memory bandwidth is tight,
but CPU transistors are cheap, you should make your addressing as short as
possible (eg, implied registers and stack) and let the CPU cache etc
control the movement of stuff in the storage heirarchy.

Re: GNAT parameter passing, C-style?

[Hyman Rosen]

Frank J. Lhota wrote:
> Yes, but what about the callee?

What *about* the calee? It sees the arguments the same
way, with the first at the top of the stack and the others
lower down. Come on, work it out for yourself. There's no
difference between pushing from right to left, or reserving
space then filling from left to right. The resulting picture
in memory is the same.

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:G96Jb.30096$tY5.28719@nwrdny01.gnilink.net...
> Frank J. Lhota wrote:
> > Yes, but what about the callee?
>
> What *about* the calee? It sees the arguments the same
> way, with the first at the top of the stack and the others
> lower down. Come on, work it out for yourself. There's no
> difference between pushing from right to left, or reserving
> space then filling from left to right. The resulting picture
> in memory is the same.

OK, I get the picture. We're beyond the discussion of the convention, and
are now discussing how the implementation is implemented. Basically what
you're saying is that one can "process" arguments from left to right and get
the same effect as pushing the argurments from right to left. On that point,
I totally agree.

Re: GNAT parameter passing, C-style?

[Marin David Condic]

Being one (at least part time these days!) I'd agree. Rocket Science 
isn't exactly Brain Surgery. :-)

MDC

Jeff C, wrote:

> By the way, Rocket Scientists are no better in this respect then the rest of
> the population.
> Trust me.
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GNAT parameter passing, C-style?

[Keith Thompson]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
[...]
> In vanilla (i.e. original K&R) C, there are no argument lists in function
> declarations. For that matter, vanilla C does NOT even require functions
> declarations. If an undeclared function is called in vanilla C, the
> unconverted argument list is assumed to be OK, the calling convention is
> assumed to be C, and it is assumed that the function returns an int.

The term "vanilla" implies that the original K&R C is the default
version of the language.  It isn't.  The 1990 ISO C standard is almost
universally implemented these days (though not always perfectly); it's
difficult to find a C compiler that doesn't implement prototypes, for
example.  (My ancient SunOS 4.1.3 box has a K&R C compiler, but I
rarely use it, since I've also installed gcc.)

> ANSI C depreciates this loose approach to functions. ANSI C strongly
> encourages the full declaration of all functions used, including argument
> lists. For compatability, however, ANSI C accepts function declarations with
> no argument lists (e.g. "double sin();"), as well as the calling of
> undeclared functions. Since there is no requirement that the user will
> declare a function's argument list (or the function for that matter), a C
> compiler may not be able to tell whether a function accepts a variable
> argument list or not. For that reason, C compilers have to assume the C
> calling convention, unless the user indicates via declaration or command
> line options.

Nitpick: it's "deprecates".

The latest ISO C standard, C99, requires full declarations for
functions, but it's not widely implemented yet; so far, it's not
catching on as quickly as C90 did.  (C90, the 1990 ISO C standard, is
essentially identical to C89, the 1989 ANSI C standard.)

If a function takes a variable number of arguments, any call to that
function without a prototype in scope invokes undefined behavior.
That means the implementation isn't required to diagnose the problem,
but the standard places no constraints on the program's behavior.
(Over in comp.lang.c, we traditionally say that it's allowed to make
demons fly out your nose.)

One of the biggest advantages of Ada over C is that it has far fewer
instances of undefined behavior.  An advantage of C over Ada is that
it uses the straightforward term "undefined behavior" rather than
"erroneous execution".

> Every C compiler that I have worked with uses the C calling convention by
> default when compiling C (as opposed to C++) code.
[...]

There is no such thing as "the C calling convention", though some
implementations may (misleadingly) use the phrase to refer to the
default calling convention used by a particular C compiler on a
particular system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: GNAT parameter passing, C-style?

[Robert I. Eachus]

Keith Thompson wrote:

> One of the biggest advantages of Ada over C is that it has far fewer
> instances of undefined behavior.  An advantage of C over Ada is that
> it uses the straightforward term "undefined behavior" rather than
> "erroneous execution".

No, no, you are thinking of Ada 83.  In the brave new world of Ada 95, 
we have "bounded errors" as well. ;-)  I don't think I have ever seen 
any difference in practice, but apparently it makes some users more 
comfortable.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: GNAT parameter passing, C-style?

[Frank J. Lhota]

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnd69ym7ga.fsf@nuthaus.mib.org...
> The term "vanilla" implies that the original K&R C is the default
> version of the language.  It isn't.  The 1990 ISO C standard is almost
> universally implemented these days (though not always perfectly); it's
> difficult to find a C compiler that doesn't implement prototypes, for
> example.  (My ancient SunOS 4.1.3 box has a K&R C compiler, but I
> rarely use it, since I've also installed gcc.)

I used the term "vanilla" because of its common usage in the C community. I
did not mean to imply that K&R C is the most common version of C. Certainly
ANSI C is available for every current platform that I am aware of, and the
vast majority of the C code written in the last few years has been written
in ANSI C.

> Nitpick: it's "deprecates".

My apologies. This is the type of mistake that my spell checker will not
protect me from!

> The latest ISO C standard, C99, requires full declarations for
> functions, but it's not widely implemented yet; so far, it's not
> catching on as quickly as C90 did.  (C90, the 1990 ISO C standard, is
> essentially identical to C89, the 1989 ANSI C standard.)

One of the reasons that C99 is not catching on as quickly as C89 / C90 is
that so much of the C market has transitioned to C++, where again full
declarations are required. So all of this is quickly becoming a moot point.

Re: GNAT parameter passing, C-style?

[Keith Thompson]

"Robert I. Eachus" <rieachus@comcast.net> writes:
> Keith Thompson wrote:
> 
> > One of the biggest advantages of Ada over C is that it has far fewer
> > instances of undefined behavior.  An advantage of C over Ada is that
> > it uses the straightforward term "undefined behavior" rather than
> > "erroneous execution".
> 
> No, no, you are thinking of Ada 83.  In the brave new world of Ada 95,
> we have "bounded errors" as well. ;-)  I don't think I have ever seen
> any difference in practice, but apparently it makes some users more
> comfortable.

For Ada, there's not much difference *to the user* between a bounded
error and erroneous execution; they're both to be avoided.  It's an
important distinction to implementers, though.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: GNAT parameter passing, C-style?

[Robert I. Eachus]

Keith Thompson wrote:

> For Ada, there's not much difference *to the user* between a bounded
> error and erroneous execution; they're both to be avoided.  It's an
> important distinction to implementers, though.

I know that.  I was just saying that in cases where an Ada 83 erroneous 
execution has been changed to a bounded error, I have not--and I think 
that any sane programmer would not--say "That's all right then, as long 
as the behaviour is bounded, I don't have to worry."  The same thing 
holds for implementation dependent as well.  An implementor is going to 
have to document what happens, but whether something is implementation 
dependent, a bounded error, or results in erroneous execution, the user 
sees it all the same way.  "Don't do this if you want to write 
trustworthy and portable programs."

And of course, that is the real distinction between C and Ada.  I can 
write portable C, but it is significantly harder than just programming 
in C.  In Ada I don't have to work hard to write portable code.  In 
fact, the only times I use implementation dependent code of any kind is 
when I am testing a compiler, or writing something that really is 
implementation dependent, such as an interface to a hardware register. 
Even there, only the register location (and layout) is implementation 
dependent.  The rest of the code doesn't have to be.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: GNAT parameter passing, C-style?

[Dave Thompson]

On Wed, 31 Dec 2003 16:30:17 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1072883131.278899@master.nyc.kbcfp.com...
> > Frank J. Lhota wrote:
> > The upshot is that even when calling a function without a prototype, the
> > compiler may pass arguments any way it likes, and it is absolutely not
> > required to "push" them onto a "stack" in any particular order.
> 
> It may not be required by the standard, but it is required to support legacy
> code. Certainly any C code written after ANSI C became widely available
> should use prototypes, but for many years there was plenty of maintained K&R
> C code written like this:
> 
>     extern int futz();
>     {
>         ...
>         if ( futz( name, count ) ) ...
>     }
> 
(Well, not exactly like that, the call needs to be within a body. <G>
Unless you're putting the declaration and the (redundantly) compound
statement both within a body, which is rarely done or useful.)

> where there is no indication as to whether or not the function takes a
> variable argument list. You can argue all you want that a compiler is not
> required to generate correct code for such a program, but the sheer weight
> of legacy code forces the compiler manufactures to not break code like this.
> 
It did for a while and to an extent, but that was over a decade ago.
Anyone who has code today that uses varargs and doesn't properly
declare them (with prototypes) is in pretty bad shape.

> I go back to my original question: does anyone know of a C compiler which,
> when compiling C (not C++) does not default to the C calling convention
> (i.e. arguments pushed on the stack in reverse order, and popped off by
> calling function) in the absence of any indication of another convention?
> The two C compilers I am currently using (GCC version 3.3.1, MSVC Version 6)
> both default to the C convention. I recall that every Borland compiler up to
> 4.0 defaulted to the C convention as well, as did the early Zortech /
> Symantec compilers.
> 
Aha -- as developed downthread, if you limit yourself to x86,
especially when you trace back to 286 or earlier, with their limited
registers and hardware downward stack (used by call and ret), there is
an obvious convention that everyone uses, even though/if not formally
mandated. This is not true across all (other) architectures, and it is
precisely because pre-Standard non-flagged varargs was a nonportable
and unreliable hack that the Standard changed it.

F.ex. my hobbyhorse the "classic" Tandem (later Compaq and HP) NonStop
CPUs had/have? in "hardware" an *upward* stack, and a convention used
by all (other) languages and the OS that arguments are pushed (upward)
left to right and accessed by callee at fixed small negative offsets
from the framepointer, for which a special addressing mode exists. C
on this architecture conforms to this convention for non-vararg
routines to allow interop especially with the OS; but this doesn't
work for vararg because the fixed arguments (and vararg-start) would
not be at known/fixed offsets, so vararg pushes (upward) right to left
and are accessed going downwards. As an obvious result, calls that
should be vararg and aren't or vice versa fail horribly. The last ~2.5
generations of Tandem systems, called TNS/R to distinguish, actually
use (MIPS) RISC CPUs with the more common downward stacks, but still
run TNS code in emulation; and since Tandem systems were (sold and)
bought mostly for mission-critical applications in large conservative
businesses I'd estimate a fair chunk of running code is emulated TNS.

> Again, I am not saying this out of fondness for the C calling convention.
> The original K&R specification, unfortunately, forced the undesirable use of
> this convention for many years. The C++ people should be congraduated for
> making a bold enough break from the past to eliminate almost all need for
> this convention.
> 
The original K&R left it out, basically leaving *printf, *scanf, and
such as implementation magic. It didn't *require* it be done badly,
but didn't help at all in doing it well either.

> I should also note that this has never been an issue in Ada. (This is an Ada
> newsgroup, after all).
> 

- David.Thompson1 at worldnet.att.net