Xref: utzoo comp.lang.c:8876 comp.sys.ibm.pc:14081
Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!uw-beaver!tikal!amc!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: cdecl keyword
Message-ID: <1521@dataio.Data-IO.COM>
Date: 4 Apr 88 18:10:42 GMT
References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <7595@brl-smoke.ARPA> <2521@bsu-cs.UUCP> <3867@super.upenn.edu> <18733@think.UUCP>
Reply-To: bright@dataio.UUCP (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 39
Keywords: cdecl MicroSoft C

In article <18733@think.UUCP> barmar@fafnir.think.com.UUCP (Barry Margolin) writes:
>In article <3867@super.upenn.edu> shirono@grasp.cis.upenn.edu (Roberto Shironoshita) writes:
>>I am of the belief that most languages have their own calling
>>conventions.
>Yes, but that doesn't preclude them all using the same internal
>mechanism to actually make the call.

In the quest for ever more performance, this isn't done, because the
semantics of a language are taken advantage of to minimize function call
overhead, which is frequently THE major cost in a program. For example,
in Pascal the callee knows how many parameters there were on the stack,
so the callee can do the stack cleanup (on the 8086 there is a special
instruction for this). For C, the callee doesn't know how many parameters
there are, so the caller must clean up the stack.

I presume that uSoft chose Pascal calling sequences for OS/2 and Windows
to take advantage of the improved function call efficiency possible.

>Another possibility is for the caller to pass a flag indicating
>whether the arguments are values or references.

No compiler vendor would ever implement this unless it is done in hardware.
There are too many benchmark wars. As a programmer, I also wouldn't want
the overhead of this, my programs are too slow anyway (they take a finite
time!).

There is a hidden gem in the ANSI C spec. That is, all functions are
presumed to have a fixed number of parameters unless they are specifically
prototyped as having variable args, and that prototype must appear before
any use of the function. The big advantage here is that now the compiler
can select the most efficient function call sequence on a case-by-case
basis. This can be a big win, and would eliminate a major reason for
coding in assembly (arguments could be passed in registers!). The only
problem would be backwards compatibility with programs that don't prototype
their varargs functions and/or don't #include the proper .h files.

By the way, when are the unix compilers going to be updated to support
function prototyping? Unix compilers are starting to look primitive compared
to PC compilers... :-)