varargs

[Gregory Smith]

In article <236 at chronon.chronon.UUCP> eric at chronon.UUCP (Eric Black) writes:
>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.
>
I agree with your assertion. If this machine supports pointers to registers,
you could write a varargs. va_arg() would have to bump a pointer to the last
register arg to a pointer to memory, maybe by calling a 'va_bump' function.
If it doesn't support pointers to register args, then it is in a bit of
trouble with C because this is supposed to be legal:

	f(a) int a;
	{	wombat(&a);
	}
-- 
"For every action there is an equal and opposite malfunction"
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg