NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/c/18257

Text File | 1992-12-12 | 3.4 KB | 76 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!taumet!steve
From: [e-mail] (Steve Clamage)
Subject: Re: Calling convention: C vs PASCAL
Message-ID: <[e-mail]>
Organization: TauMetric Corporation
References: <[e-mail]>
Distribution: usa
Date: Sat, 12 Dec 1992 17:11:37 GMT
Lines: 64

[e-mail] (zzang) writes:

>the C pushs the args from right to left onto the stack when calling a function.
>the PASCAL pushs the args from left to right.
>I was told that the C convention results in larger as well as slower program.
>(due to some cleanup work of the stack after call??)

>can someone tell me why?

A partially correct answer was posted to this question.

Neither the C nor Pascal language specifications require the parameter
ordering mentioned, but they are common implementation techniques.

C allows a function to be called with more parameters than were declared
for it.  The called function can't in general know how many parameters
were passed, or their sizes.  The simplest way around this is to
pass parameters in reverse order.  The leftmost (first) parameter
is always in a known location, and the remainder of the declared
parameters can be reliably found by the called function.  (Other
techniques are of course possible; this is a popular solution.)

Pascal requires that all function calls match the declaration, so the
called function always knows the number and type of each parameter.
It is easier for a compiler to process the actual arguments in the
order they are encountered, so Pascal compilers typically pass
parameters from left to right.  (To pass them in reverse order means
the compiler has to save up all the parameter expressions first.
Passing them in order means you don't have to save up the expressions.)

A Pascal compiler designed to be compatible with a C compiler, or on a
system where calling sequences were standardized, would use the same
parameter passing scheme as the C compiler.

When parameters are passed on the stack, the stack must be restored at
some point (pop off the parameters).  If the called function does not
know the number or size of passed parameters, it can't do the job.
In that case, the caller must pop the stack.  If the caller restores
the stack after each function call, you have code to pop the stack
at each place a function is called.  If the called function restores
the stack, you have such code once per function.  There is no difference
(necessarily) in speed, but the code size is larger if the caller pops.

Some compilers generate faster code by not popping the stack after every
function call, but only when absolutely necessary.  This reduces the
discrepancy in code size between caller popping versus callee popping.
Example:
    foo(1,2,3);
    bar(2,3,4)
    baz(3,4,5);
    return;
It is not necessary to pop the stack after the calls to foo and bar
unless you are worried about total stack size.  It is sufficient to
pop the stack at the return, when the stack must look like it did
when the function was called.

Finally, some machines have a pop-and-return instruction.  The callee
can pop the stack simultaneously with the return, needing no extra
instruction.  When the callee doesn't know how much to pop, it can't
take advantage of this.  In this case, the usual C technique would
result in larger and slower code than the usual Pascal technique.
--

Steve Clamage, TauMetric Corp, [e-mail]