cdecl keyword ( re: C Decl ...

[carroll at snail.CS.UIUC.EDU]

/* Written  6:58 am  Apr  5, 1988 by greg at csanta.UUCP in snail:comp.lang.c */
/* ---------- "Re: cdecl keyword ( re: C Decl ..." ---------- */
In article <2521 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
(...) Because C builds the stack with the
current arguments every time it goes to do a subsroutine call and it
does not know or care how may arguments there actually is.  Pascal does.
So?  Well this means that the overhead for pascal function calls during
execution is faster because pascal type functions can clean up the
stack when they are finished with a 'ret #bytes' instruction.  With the
"standard" C calling concentions, the caller usually does the cleaning
up with an increment (decrement?) of the sp *after* the call to the function.

Result is: faster & smaller code.  Not too often that you can kill them two
birds with the same stone.
/* End of text from snail:comp.lang.c */

	I must strongly disagree. You are forgetting that there are
different processors with different stack semantics around. Whether
C or Pascal calling conventions are faster/smaller depends very strongly
on the chip architecture. What if there is no "ret #bytes" instruction?
A lot of processors don't have that. You are also ignoring the fact
that Pascal need displays (since there can be static nesting), while C
doesn't.  And you can't even say, a priori, that the "ret #byte" is
faster than "ret" -- "add #byte,%sp".
    For example : on the BellMac (WE32100, 3bX chip) C is faster.
The CALL/RET instructions implicitly clean up the args on the stack. So
C calls have NO extra overhead. So keep in mind that things like this
are *very* hardware dependent.

Alan M. Carroll		amc at woodshop.cs.uiuc.edu	carroll at s.cs.uiuc.edu
Grad Student (TA) / U of Ill - Urbana ...{ihnp4,convex}!uiucdcs!woodshop!amc
Quote of the day :
	"Touch my soul, catch the very light
	 Hide the moment, from my eager eyes"