* GNAT parameter passing, C-style? @ 2003-12-26 10:37 Luke A. Guest 2003-12-26 14:20 ` Marin David Condic 0 siblings, 1 reply; 47+ messages in thread From: Luke A. Guest @ 2003-12-26 10:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 10:37 GNAT parameter passing, C-style? Luke A. Guest @ 2003-12-26 14:20 ` Marin David Condic 2003-12-26 14:51 ` Hyman Rosen 2003-12-26 18:01 ` Georg Bauhaus 0 siblings, 2 replies; 47+ messages in thread From: Marin David Condic @ 2003-12-26 14:20 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 14:20 ` Marin David Condic @ 2003-12-26 14:51 ` Hyman Rosen 2003-12-26 15:07 ` Marin David Condic 2003-12-26 18:01 ` Georg Bauhaus 1 sibling, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2003-12-26 14:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 14:51 ` Hyman Rosen @ 2003-12-26 15:07 ` Marin David Condic 2003-12-26 15:39 ` Luke A. Guest 0 siblings, 1 reply; 47+ messages in thread From: Marin David Condic @ 2003-12-26 15:07 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 15:07 ` Marin David Condic @ 2003-12-26 15:39 ` Luke A. Guest 2003-12-26 17:03 ` Hyman Rosen 2003-12-26 17:10 ` Martin Krischik 0 siblings, 2 replies; 47+ messages in thread From: Luke A. Guest @ 2003-12-26 15:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 15:39 ` Luke A. Guest @ 2003-12-26 17:03 ` Hyman Rosen 2003-12-26 17:08 ` Luke A. Guest 2003-12-26 17:10 ` Martin Krischik 1 sibling, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2003-12-26 17:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 17:03 ` Hyman Rosen @ 2003-12-26 17:08 ` Luke A. Guest 2003-12-26 17:27 ` Luke A. Guest 2003-12-27 14:22 ` Marin David Condic 0 siblings, 2 replies; 47+ messages in thread From: Luke A. Guest @ 2003-12-26 17:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 17:08 ` Luke A. Guest @ 2003-12-26 17:27 ` Luke A. Guest 2003-12-26 18:21 ` Frank J. Lhota 2003-12-27 14:22 ` Marin David Condic 1 sibling, 1 reply; 47+ messages in thread From: Luke A. Guest @ 2003-12-26 17:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 17:27 ` Luke A. Guest @ 2003-12-26 18:21 ` Frank J. Lhota 2003-12-26 19:06 ` Frank J. Lhota 2003-12-31 10:23 ` Keith Thompson 0 siblings, 2 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-26 18:21 UTC (permalink / raw) "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++. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 18:21 ` Frank J. Lhota @ 2003-12-26 19:06 ` Frank J. Lhota 2003-12-31 10:23 ` Keith Thompson 1 sibling, 0 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-26 19:06 UTC (permalink / raw) "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++. > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 18:21 ` Frank J. Lhota 2003-12-26 19:06 ` Frank J. Lhota @ 2003-12-31 10:23 ` Keith Thompson 2003-12-31 14:45 ` Frank J. Lhota 1 sibling, 1 reply; 47+ messages in thread From: Keith Thompson @ 2003-12-31 10:23 UTC (permalink / raw) "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) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 10:23 ` Keith Thompson @ 2003-12-31 14:45 ` Frank J. Lhota 2003-12-31 15:05 ` Hyman Rosen 2004-01-05 21:06 ` Keith Thompson 0 siblings, 2 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-31 14:45 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 14:45 ` Frank J. Lhota @ 2003-12-31 15:05 ` Hyman Rosen 2003-12-31 16:30 ` Frank J. Lhota 2004-01-01 3:38 ` Marin David Condic 2004-01-05 21:06 ` Keith Thompson 1 sibling, 2 replies; 47+ messages in thread From: Hyman Rosen @ 2003-12-31 15:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 15:05 ` Hyman Rosen @ 2003-12-31 16:30 ` Frank J. Lhota 2003-12-31 17:24 ` Hyman Rosen 2004-01-07 6:37 ` Dave Thompson 2004-01-01 3:38 ` Marin David Condic 1 sibling, 2 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-31 16:30 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 16:30 ` Frank J. Lhota @ 2003-12-31 17:24 ` Hyman Rosen 2003-12-31 19:05 ` Frank J. Lhota 2004-01-07 6:37 ` Dave Thompson 1 sibling, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2003-12-31 17:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 17:24 ` Hyman Rosen @ 2003-12-31 19:05 ` Frank J. Lhota 2003-12-31 19:38 ` Hyman Rosen 0 siblings, 1 reply; 47+ messages in thread From: Frank J. Lhota @ 2003-12-31 19:05 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 19:05 ` Frank J. Lhota @ 2003-12-31 19:38 ` Hyman Rosen 2003-12-31 20:47 ` Frank J. Lhota 0 siblings, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2003-12-31 19:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 19:38 ` Hyman Rosen @ 2003-12-31 20:47 ` Frank J. Lhota 2003-12-31 21:35 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-31 20:47 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 20:47 ` Frank J. Lhota @ 2003-12-31 21:35 ` Hyman Rosen 2004-01-01 2:50 ` Frank J. Lhota 2004-01-01 5:17 ` Luke A. Guest 2004-01-01 5:09 ` Luke A. Guest 2004-01-01 17:18 ` Jano 2 siblings, 2 replies; 47+ messages in thread From: Hyman Rosen @ 2003-12-31 21:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 21:35 ` Hyman Rosen @ 2004-01-01 2:50 ` Frank J. Lhota 2004-01-01 5:20 ` Luke A. Guest 2004-01-01 5:17 ` Luke A. Guest 1 sibling, 1 reply; 47+ messages in thread From: Frank J. Lhota @ 2004-01-01 2:50 UTC (permalink / raw) "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>. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 2:50 ` Frank J. Lhota @ 2004-01-01 5:20 ` Luke A. Guest 2004-01-01 16:06 ` Hyman Rosen 0 siblings, 1 reply; 47+ messages in thread From: Luke A. Guest @ 2004-01-01 5:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 5:20 ` Luke A. Guest @ 2004-01-01 16:06 ` Hyman Rosen 2004-01-01 16:32 ` Frank J. Lhota 0 siblings, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2004-01-01 16:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 16:06 ` Hyman Rosen @ 2004-01-01 16:32 ` Frank J. Lhota 2004-01-01 16:43 ` Hyman Rosen 0 siblings, 1 reply; 47+ messages in thread From: Frank J. Lhota @ 2004-01-01 16:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 16:32 ` Frank J. Lhota @ 2004-01-01 16:43 ` Hyman Rosen 2004-01-02 0:24 ` Frank J. Lhota 0 siblings, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2004-01-01 16:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 16:43 ` Hyman Rosen @ 2004-01-02 0:24 ` Frank J. Lhota 2004-01-02 4:09 ` Hyman Rosen 0 siblings, 1 reply; 47+ messages in thread From: Frank J. Lhota @ 2004-01-02 0:24 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-02 0:24 ` Frank J. Lhota @ 2004-01-02 4:09 ` Hyman Rosen 2004-01-02 13:29 ` Frank J. Lhota 0 siblings, 1 reply; 47+ messages in thread From: Hyman Rosen @ 2004-01-02 4:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-02 4:09 ` Hyman Rosen @ 2004-01-02 13:29 ` Frank J. Lhota 0 siblings, 0 replies; 47+ messages in thread From: Frank J. Lhota @ 2004-01-02 13:29 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 21:35 ` Hyman Rosen 2004-01-01 2:50 ` Frank J. Lhota @ 2004-01-01 5:17 ` Luke A. Guest 1 sibling, 0 replies; 47+ messages in thread From: Luke A. Guest @ 2004-01-01 5:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 20:47 ` Frank J. Lhota 2003-12-31 21:35 ` Hyman Rosen @ 2004-01-01 5:09 ` Luke A. Guest 2004-01-02 1:17 ` tmoran 2004-01-01 17:18 ` Jano 2 siblings, 1 reply; 47+ messages in thread From: Luke A. Guest @ 2004-01-01 5:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 5:09 ` Luke A. Guest @ 2004-01-02 1:17 ` tmoran 0 siblings, 0 replies; 47+ messages in thread From: tmoran @ 2004-01-02 1:17 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 20:47 ` Frank J. Lhota 2003-12-31 21:35 ` Hyman Rosen 2004-01-01 5:09 ` Luke A. Guest @ 2004-01-01 17:18 ` Jano 2004-01-02 0:25 ` Frank J. Lhota 2 siblings, 1 reply; 47+ messages in thread From: Jano @ 2004-01-01 17:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 17:18 ` Jano @ 2004-01-02 0:25 ` Frank J. Lhota 0 siblings, 0 replies; 47+ messages in thread From: Frank J. Lhota @ 2004-01-02 0:25 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 16:30 ` Frank J. Lhota 2003-12-31 17:24 ` Hyman Rosen @ 2004-01-07 6:37 ` Dave Thompson 1 sibling, 0 replies; 47+ messages in thread From: Dave Thompson @ 2004-01-07 6:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 15:05 ` Hyman Rosen 2003-12-31 16:30 ` Frank J. Lhota @ 2004-01-01 3:38 ` Marin David Condic 2004-01-01 5:28 ` Luke A. Guest 1 sibling, 1 reply; 47+ messages in thread From: Marin David Condic @ 2004-01-01 3:38 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 3:38 ` Marin David Condic @ 2004-01-01 5:28 ` Luke A. Guest 2004-01-01 14:17 ` Marin David Condic 0 siblings, 1 reply; 47+ messages in thread From: Luke A. Guest @ 2004-01-01 5:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 5:28 ` Luke A. Guest @ 2004-01-01 14:17 ` Marin David Condic 2004-01-01 16:20 ` Jeff C, 0 siblings, 1 reply; 47+ messages in thread From: Marin David Condic @ 2004-01-01 14:17 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 14:17 ` Marin David Condic @ 2004-01-01 16:20 ` Jeff C, 2004-01-02 13:47 ` Marin David Condic 0 siblings, 1 reply; 47+ messages in thread From: Jeff C, @ 2004-01-01 16:20 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-01 16:20 ` Jeff C, @ 2004-01-02 13:47 ` Marin David Condic 0 siblings, 0 replies; 47+ messages in thread From: Marin David Condic @ 2004-01-02 13:47 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-31 14:45 ` Frank J. Lhota 2003-12-31 15:05 ` Hyman Rosen @ 2004-01-05 21:06 ` Keith Thompson 2004-01-06 3:42 ` Robert I. Eachus 2004-01-06 13:46 ` Frank J. Lhota 1 sibling, 2 replies; 47+ messages in thread From: Keith Thompson @ 2004-01-05 21:06 UTC (permalink / raw) "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" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-05 21:06 ` Keith Thompson @ 2004-01-06 3:42 ` Robert I. Eachus 2004-01-06 20:54 ` Keith Thompson 2004-01-06 13:46 ` Frank J. Lhota 1 sibling, 1 reply; 47+ messages in thread From: Robert I. Eachus @ 2004-01-06 3:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-06 3:42 ` Robert I. Eachus @ 2004-01-06 20:54 ` Keith Thompson 2004-01-06 23:45 ` Robert I. Eachus 0 siblings, 1 reply; 47+ messages in thread From: Keith Thompson @ 2004-01-06 20:54 UTC (permalink / raw) "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" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-06 20:54 ` Keith Thompson @ 2004-01-06 23:45 ` Robert I. Eachus 0 siblings, 0 replies; 47+ messages in thread From: Robert I. Eachus @ 2004-01-06 23:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2004-01-05 21:06 ` Keith Thompson 2004-01-06 3:42 ` Robert I. Eachus @ 2004-01-06 13:46 ` Frank J. Lhota 1 sibling, 0 replies; 47+ messages in thread From: Frank J. Lhota @ 2004-01-06 13:46 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 17:08 ` Luke A. Guest 2003-12-26 17:27 ` Luke A. Guest @ 2003-12-27 14:22 ` Marin David Condic 1 sibling, 0 replies; 47+ messages in thread From: Marin David Condic @ 2003-12-27 14:22 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 15:39 ` Luke A. Guest 2003-12-26 17:03 ` Hyman Rosen @ 2003-12-26 17:10 ` Martin Krischik 2003-12-26 19:04 ` Frank J. Lhota 1 sibling, 1 reply; 47+ messages in thread From: Martin Krischik @ 2003-12-26 17:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 17:10 ` Martin Krischik @ 2003-12-26 19:04 ` Frank J. Lhota 0 siblings, 0 replies; 47+ messages in thread From: Frank J. Lhota @ 2003-12-26 19:04 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: GNAT parameter passing, C-style? 2003-12-26 14:20 ` Marin David Condic 2003-12-26 14:51 ` Hyman Rosen @ 2003-12-26 18:01 ` Georg Bauhaus 1 sibling, 0 replies; 47+ messages in thread From: Georg Bauhaus @ 2003-12-26 18:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2004-01-07 6:37 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-12-26 10:37 GNAT parameter passing, C-style? Luke A. Guest 2003-12-26 14:20 ` Marin David Condic 2003-12-26 14:51 ` Hyman Rosen 2003-12-26 15:07 ` Marin David Condic 2003-12-26 15:39 ` Luke A. Guest 2003-12-26 17:03 ` Hyman Rosen 2003-12-26 17:08 ` Luke A. Guest 2003-12-26 17:27 ` Luke A. Guest 2003-12-26 18:21 ` Frank J. Lhota 2003-12-26 19:06 ` Frank J. Lhota 2003-12-31 10:23 ` Keith Thompson 2003-12-31 14:45 ` Frank J. Lhota 2003-12-31 15:05 ` Hyman Rosen 2003-12-31 16:30 ` Frank J. Lhota 2003-12-31 17:24 ` Hyman Rosen 2003-12-31 19:05 ` Frank J. Lhota 2003-12-31 19:38 ` Hyman Rosen 2003-12-31 20:47 ` Frank J. Lhota 2003-12-31 21:35 ` Hyman Rosen 2004-01-01 2:50 ` Frank J. Lhota 2004-01-01 5:20 ` Luke A. Guest 2004-01-01 16:06 ` Hyman Rosen 2004-01-01 16:32 ` Frank J. Lhota 2004-01-01 16:43 ` Hyman Rosen 2004-01-02 0:24 ` Frank J. Lhota 2004-01-02 4:09 ` Hyman Rosen 2004-01-02 13:29 ` Frank J. Lhota 2004-01-01 5:17 ` Luke A. Guest 2004-01-01 5:09 ` Luke A. Guest 2004-01-02 1:17 ` tmoran 2004-01-01 17:18 ` Jano 2004-01-02 0:25 ` Frank J. Lhota 2004-01-07 6:37 ` Dave Thompson 2004-01-01 3:38 ` Marin David Condic 2004-01-01 5:28 ` Luke A. Guest 2004-01-01 14:17 ` Marin David Condic 2004-01-01 16:20 ` Jeff C, 2004-01-02 13:47 ` Marin David Condic 2004-01-05 21:06 ` Keith Thompson 2004-01-06 3:42 ` Robert I. Eachus 2004-01-06 20:54 ` Keith Thompson 2004-01-06 23:45 ` Robert I. Eachus 2004-01-06 13:46 ` Frank J. Lhota 2003-12-27 14:22 ` Marin David Condic 2003-12-26 17:10 ` Martin Krischik 2003-12-26 19:04 ` Frank J. Lhota 2003-12-26 18:01 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox