Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Variable Parameters
Message-ID: <1990Jan2.164437.25148@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1169@zip.eecs.umich.edu> <1989Dec31.013746.2349@utzoo.uucp> <363@sixhub.UUCP> <1990Jan1.004914.25006@utzoo.uucp> <366@sixhub.UUCP>
Date: Tue, 2 Jan 90 16:44:37 GMT

In article <366@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>| ... On some machines, the information can be deduced
>| from details of the stack frame or the calling sequence, but on many
>| modern systems, it has to be explicitly provided at significant cost.
>
>  As I mentioned, the original versions which with I worked in the 70's
>did have the caller provide the information, but the cost was only one
>word in the call sequence (no CPU overhead). As common as calls are in
>C, they are a very small % of the code...

They are not a small percentage of the time, however -- many C programs
can spend a *lot* of time calling and returning if the sequences are
inefficient.  (There are C programs, I'm told, which spend 50% of their
time in call/return on a VAX.)  Reserving a word somewhere to hold the
argument count is reasonable... but *where*?  The code may not be readable
at all (in fact, that was the reason why nargs() originally disappeared
from C).  Getting the value into data space, in general, takes run-time
overhead on calls, and there is generally a considerable performance win
in trimming every last unnecessary nanosecond out of calls.

With ANSI C requiring prototypes to be in scope for varargs calls, there
are now compilers that use different calling sequences for varargs and
non-varargs functions.  If everyone could be persuaded to do that, the
efficiency argument would be largely moot:  a bit of overhead in varargs
calls, and *only* varargs calls, is not a problem (indeed, there is often
considerable overhead there anyway).
-- 
1972: Saturn V #15 flight-ready|     Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu