Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!mordor!styx!lll-lcc!pyramid!prls!mips!hansen
From: hansen@mips.UUCP
Newsgroups: comp.arch
Subject: Re: Aliasing, etc. in C
Message-ID: <940@mips.UUCP>
Date: Tue, 3-Feb-87 03:11:33 EST
Article-I.D.: mips.940
Posted: Tue Feb  3 03:11:33 1987
Date-Received: Wed, 4-Feb-87 03:37:55 EST
References: <7803@decwrl.DEC.COM> <5230@mimsy.UUCP> <12570@sun.uucp>
Lines: 22
Summary: how MIPS compilers treat varargs

In article <12570@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> >Nor is Pyramid's implementation, which is considerably more complex and
> >does *not* rely upon `ptr = &a; ptr++;' pointing to `b' (which is
> >only sometimes the case).
> 
> I presume this is because it's a register-window machine, and some
> parameters may be passed in registers, so that not all of the
> parameters are necessarily stored in memory?

The MIPS compiler, which passes four arguments in registers, will recognise
the use of the <varargs.h> constructs in the argument list and push the
registers back out to memory when required. This permits printf-line
routines to work, which is a more severe constraint than <varargs.h> itself,
as the argument list is normally passed onto routines such as _doprnt by the
address of the format string argument. It certainly makes porting code
easier than rewriting everything to use the formal varargs interface as
strictly defined, and for that I'm already grateful to our compiler team.
-- 

Craig Hansen			|	 "Evahthun' tastes
MIPS Computer Systems		|	 bettah when it
...decwrl!mips!hansen		|	 sits on a RISC"