varargs

[eric at chronon]

In article <129 at drilex.UUCP> dricej at drilex.UUCP writes:
>
>rb at ccird2 (Rex Ballard) wonders what kind of systems would not be able to
>handle varargs. ...
>... Therefore, a more proper question would be: is there any
>architecture which is suitable for a C compiler, but not for varargs?

Yes!  I can think of an example close to home... An architecture with
a large (LARGE) number of registers, a sliding window to allow reference
to a smaller register set locally within a procedure, and OS support
for using the register set as a stack (handling overflow/underflow).
The first <n> arguments are passed in registers via the overlapped
sliding window, remaining have to be passed in memory.  The problem
is that no choice of <n> will be correct; you can only make arbitrarily
small the probability of it not being big enough...  and at the cost of
additional expense elsewhere...
I assert that this architecture, and the rest of what goes with this
particular feature, is particularly well-suited for efficient execution
of programs written in C.

>P.S. Microcomputers pass things in registers, rather than on the stack,
>because stack operations are slow relative to register operations.  This
>is also typical of assembly language programming, rather than C language
>programming.
>Not everybody is willing to pay the high-level language penalty.
>
>Craig Jackson
>UUCP: {harvard,linus}!axiom!drilex!dricej

Microcomputers aren't the only ones interested in the fact that using
registers is faster than using memory.  Does this argument sound RISC-y?

Note that nothing in the C language requires this particular high-level
language penalty (passing args in memory rather than in registers).
The varargs kludge is for convenience only (yes, I like it, too, and
would chafe at Pascal-like restrictiveness!).
-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric
WELL:        eblack
BIX:         eblack