varargs

[Eric Black]

Yes, this is slightly to the side of the original question as
to whether it is POSSIBLE to write a varargs() handler (a la 4.2 manpage)
for any given machine architecture, but the discussion is legitimately
moving around that target...

In article <2694 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) writes:
>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?

[I guess I answered a slightly different question here:]

>>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
>>    [... description of register stack machine ...]
>>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);
>	}
>-- 

Yup.  This is legal, and is permitted.  This machine DOES allow you
to take the address of a register, but it's an expensive feature
to support, and we'd like to get rid of it.  Other systems take care
of this at the compiler level, and it crops up with register variables,
not just arguments -- if you take the address of a variable, it can't
reside in a register, but must be copied into memory.  Possible
aliasing with pointer arithmetic gets quite hairy, but that's a
dangerous [and generally non-portable] thing to do in an undisciplined
manner.

This brings me back to my point (sort of).  This is the same problem that
other machines have with register variables and getting at them in
two different ways (by name and at the other end of a pointer).  In
the case of varargs, the "by name" is as a formal parameter, the pointer
is the usual varargs method.  Accessing varargs directly is just as
sloppy as doing something like this:
	foo()
	{
	    int a, b, *intp;

	    intp = &a;
	    *intp = 1;		/* set a to 1 */
	    intp++;
	    *intp = 2;		/* of course, this sets b to 2, doesn't it? */
	}
If you think this is good coding practice, I don't want you working
for me!  If you object to this technique, why is direct accessing of
varargs items OK?

Again, I realize this is not answering the precise question in the
original posting, but it's worth discussing.  Thanks for putting up
with me...

-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric