>> > I know the caller's %o will be the callee's %i after the 'save', but I > don't think they are saved on the stack when the 'call' or 'save' > executes. Just as what I mean, these acres are just reserved for > traps, those registers are saved by the trap handler or the resume(). Correct, they "saved" (by means of spill handlers) to the stack, when we context switch, execute a flushw instruction, or when a register window is about to be overwritten (i.e. the window rotates all the way around, which is about 6 function deep IIRC for the old UltraSPARC processors, so the save could trigger a spill for a different register window (and saved into that register windows frame on the stack), and the restore instruction would load them back into the hardware)... nwindows = 8, (there is an overlap window), and probably some other circumstances.
The bottom line is that when a thread is executing, the current contents aren't necessarily there. >>> 3. the callee reserve area for the Locals and temps and outgoing >>> args past 6. together with the caller's bias area(I don't know how >>> to express this area, so just name as is), can be accessed by the >>> callee for its private use. >>> >> We have a minimum stack frame which is large enough to hold the >> registers + the frame is extended to hold the local variables. The >> bias isn't an area, think of it like calibrating the steering on a >> car or remote control boat. i.e. the default position is always >> offset by a particular amount. >> > I know the answer. From the doc you sent to me, I got: > > /The SPARC V9 ABI defines the stack pointer to have bias subtracted. > This means that stack pointer for 64-bit program normally contains an > misaligned value,but load and store instructions generated by the com- > piler subtract the required bias to generate the correct address. > > /so it is just a definition of the %sp, nothing else. I think "specifies" or "convention" would be better words, but yes. Cheers, Greg
