David.Steere@CS.CMU.EDU (07/18/90)
BACKGROUND: I'm porting a file system to the Dec 3100. Our code is mostly written in C++, which gets precompiled (as it were) into standard C. The pmax C compiler is standard C (pcc), so for the most part, this isn't a problem. However, we are having a problem with procedures with a variable number of arguments (like printf). Typically, when such a procedure is called, the parameters are read off the stack, using a pointer to the first argument to reference the other arguments. This assumes that the arguments are written to the stack. Syntactically, variable length procedure headers can be declared by including <varargs.h>, and having the last argument be va_alist. varargs.h declares various macros which basically handle the referencing to the stack. In the Pmax compiler, the first several arguments are not written onto the stack automatically. So they are not found when the procedure is called. It turns out that the compiler looks for the symbol "va_alist" in the procedure header, and if it is found forces all the arguments to be written to the stack. Okay, this seems like a hack and it seems to work fine, except that we use C++, which during preprocessing renames all the variables, prepending things like au0_ on the front of variable names. So va_alist is now au0_va_alist. Since that isn't the same as va_alist, the compiler does not force all the arguments to the stack. QUESTION: Is there a way to tell the compiler to force arguments to the stack for a particular routine? thanks, david.
mod@masscomp.ccur.com (2915) (07/19/90)
In article <Uad7TRa00XMV43XHQF@cs.cmu.edu> David.Steere@CS.CMU.EDU writes: ...<stuff deleted>... > It turns out that the compiler looks for the symbol "va_alist" in >the procedure header, and if it is found forces all the arguments to be >written to the stack. Okay, this seems like a hack and it seems to work I'm pretty sure this isn't quite true. My observation is that the generated code writes all register-based argument values to the stack frame any time it sees a reference to the ADDRESS of any of them. Another MIPS vararg gotcha is the inability to pass a float or double as the FIRST item in a variable argument list - try it and see... (The explanation has been provided here before - the integer registers get copied into the stack frame instead of the float registers - Ouch! ) ---------------------------------------------------------------------------- Michael O'Donnell (508)392-2915 home(508)251-7576 fax(508)692-8307 ___________ / ________/__ ...!{harvard,uunet,petsd}!masscomp!mod /__/_______/ / mod@westford.ccur.com Concurrent /__________/ Computer Corporation 1 Technology Way Westford, MA 01886 DISCLAIMER: My opinions only coincidentally resemble those of my employer. ----------------------------------------------------------------------------
sah@gumby (Steve Hanson) (07/20/90)
In article <Uad7TRa00XMV43XHQF@cs.cmu.edu>, David.Steere@CS writes: >BACKGROUND: > >I'm porting a file system to the Dec 3100. Our code is mostly written in >C++, which gets precompiled (as it were) into standard C. >The pmax C compiler is standard C (pcc), so for the most part, this >isn't a problem. > >However, we are having a problem with procedures with a variable >number of arguments (like printf). Typically, when such a procedure is >called, the parameters are read off the stack, using a pointer to the >first argument to reference the other arguments. This assumes that >the arguments are written to the stack. Syntactically, variable length >procedure headers can be declared by including <varargs.h>, and having >the last argument be va_alist. varargs.h declares various macros >which basically handle the referencing to the stack. > >In the Pmax compiler, the first several arguments are not written onto >the stack automatically. So they are not found when the procedure is >called. It turns out that the compiler looks for the symbol "va_alist" in >the procedure header, and if it is found forces all the arguments to be >written to the stack. Okay, this seems like a hack and it seems to work >fine, except that we use C++, which during preprocessing renames all the >variables, prepending things like au0_ on the front of variable names. >So va_alist is now au0_va_alist. Since that isn't the same as va_alist, >the compiler does not force all the arguments to the stack. > >QUESTION: >Is there a way to tell the compiler to force arguments to the stack for >a >particular routine? > >thanks, > >david. Two suggestions: 1) Bypass the name problem by declaring these functions with ellipsis notation: void foo(int c, ...) {} and ask your translator to produce ANSI C syntax, e.g. /* <<AT&T C++ Translator 2.00 06/30/89>> */ CC +a1 foo.c 2) Use the native cpp to give you your name back, e.g. CC -Wp,-D__0va_alist=va_alist foo.c or in your case CC -Wp,-Dau0_va_alist=va_alist foo.c -- -- UUCP: {ames,decwrl,prls,pyramid}!mips!sah USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086