mash@mips.UUCP (John Mashey) (10/07/87)
In article <29935@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >> Lose#4: Some programs (particularly Unix's "printf" ) want their parameter >> list to be at an address. >> What ways have been used around lose#4 ? >Our "printf" uses the "varargs" package, our "varargs.h" include file maps >"va_alist" into "__builtin_va_alist" on SPARC machines... >you'd better not just use any "varargs"-like technique, you'd better use >"varargs". (ANSI C contains a similar facility, and mandates its use in this >case.) MIPSco does this too, and we second Guy: use varargs, or you will be increasingly sorry. >Note that this is a lose of any implementation where arguments are passed in >registers; it can either be supported by requiring this sort of code to be >written using higher-level primitives such as "varargs" rather than low-level >fiddling, or by having the compiler somehow detect that the low-level tricks >are being used (as I believe MIPSco's compiler for their non-register-window >machine does). I can't remember the exact rule, but in general, if you take the address of an argument, and stick it in a pointer, and if you store something thru that pointer (but not if you just fetch from it) the compiler gets suspicious and homes the variables to memory. Note: 1) All of this is much more complicated to get right than it looks, for reasons shown below. 2) However, at least several independent groups [Pyramid, HP, MIPS, Sun, at least] have done so, and have running UNIXes with plenty of software that lives thru this. Now, why is it more complicated? a) Most of the machines have 2 register sets: integer and FP, and I think at least one of the register-window machines (SPARC) does NOT register-window the FP regs (which is OK). b) Consider what happens when, in C: You mix floating-point arguments (which would be pleased to be passed thru FP regs) with integer ones. You invoke a function that returns a struct (hidden argument!) with an argument list that uses varargs and has both int and float arguments. c) Side-observation: if you have simple compiler systems, some of the trickery around this could be painful. If you're using high-powered global optimization technology (at least 3 of the 4 above are: I don't know about Pyramid, they be also.) then a lot of the information-gathering needed to generate good code for the argument passing falls out of technology. d) Nevertheless, there is room for error :-) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086