torek@elf.ee.lbl.gov (Chris Torek) (03/24/91)
In article <7468@idunno.Princeton.EDU> pfalstad@lit.Princeton.EDU (Paul Falstad) writes: >With a SPARC, a procedure almost always creates a stack frame of 96 >bytes, plus whatever space for local variables it needs. This is done >because the window_overflow trap handler needs somewhere to dump your >register window if you run out of windows (96 bytes is the size of a >window). Actually, the size is 64 bytes (16 words): 8 `local' registers and 8 `in' registers. The remaining 8 words are due to Sun's (wrong) calling convention: 1 word for `structure return pointer'. (Compiler should pass structure return pointer in a register, as GCC does. The hairy `unimp' size magic does not belong in the runtime system. The compiler should pass and return small structures in the registers, which means the size-checking would fail anyway.) 6 words for `arg dump area'. This is a place where the callee can write the caller's `out' registers %o0 through %o5 (aka the calle's `in' registers %i0..%i5). This is sheer lunacy: if the callee needs to store its %i0 through %i5 for some reason, it can allocate its own space! (I suppose the argument here is that the callee might not use a new window. My counterargument is that if the callee needs to hold that many arguments, it is probably better off getting a new window anyway.) 1 or more words for `arguments past the sixth'. This should be `zero or more words' and should start at [%fp+64], not [%fp+92]. (Oops, I need to go change my kernel, I used 96. I guess I should clean up these magic constants.... Maybe after it boots :-) which will not occur until after it links :-p and then we need drivers and autoconfiguration code and . . . sigh.) >The sun compiler, I gather, puts the local variables at the >top of the stack frame, and the 96-byte buffer underneath. Right. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov