Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!bbn!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.c
Subject: Re: Variable argument lists.
Message-ID: <5485@aw.sei.cmu.edu>
Date: 17 May 88 13:09:45 GMT
References: <14139@brl-adm.ARPA> <504@sas.UUCP> <1777@rpp386.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 25

In article <1777@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:

[ why can't functions with variable numbers of arguments determine the
  number of arguments they were called with? ]

>could someone please present an example of an architecture were this
>CAN'T be done?  and does anyone actually have timings for a system where
>this has been done versus not to support the claim that doing this is
>very expensive?

Glad to.  The BCPL codegenerator I wrote for the MIPS M/500 passes the
first N parameters in registers and the rest on the stack.  The called
function stores the registers (if necessary) into the correct place on
the stack.

A function has to know the maximum number of arguments it will be passed,
since it must allocate its local space above them, but it does not know
how many it has actually been passed, and cannot find out (not least
because motion of the stack pointer across successive calls is optimised).

If we consider the average function has two parameters, then the extra
cost is a (hidden) third parameter.  That raises the full call/entry/
exit/return sequence from ~10 instructions to ~12, ie an overhead of 20%.

No, I do not want to pay that price.