Brian Xu - Sun Microsystems - Beijing China wrote: > max at bruningsystems.com ??: >> Brian Xu - Sun Microsystems - Beijing China wrote: >> >>> Greg Price ??: >>> >>>> >>> I still have the question that who produces those 'bias area' and when? >>> >>> >>> >> When the stack pointer is initialized for a thread when the thread is >> created, >> the bias is subtracted to get an initial stack pointer value. Again, >> see the code >> in thread_load() which is (at least) one place where the stack >> pointer is initialized. >> > I saw the code you referred. It is only about the thread init. then > how about the following calls in the thread? >>> It is obvious that before or just after the 'save' instruction, the >>> %sp has been moved to the bottom of the bias. so it must be the >>> 'call' or the 'save' instruction that does it. I want to know. >>> >>> >> No. The save instruction doesn't need to do anything with the stack >> pointer as far as the >> bias is concerned. The bias is already "in" the stack pointer when >> the save is executed. >> The call also does not need to do anything with the stack pointer. >> It is only when code >> needs to access/store data on the stack, and when the thread is >> initialized, that the >> bias value needs to be used. >> > I think it is only the case for the first call in the thread. For the > following calls, there must somewhere that implicitly modify the %sp. No. Let's say that several functions are called, each with save/restore, and each with minimum 64-bit frame size of 0xb0 bytes. So, a() calls b() which in turn calls c() which calls d(). Also assume that the stack starts at (highest address) 0x10000. The initial stack pointer is at 0x10000-0x7ff (beginning of stack minus bias). So, a() does a save %sp, -0xb0, %sp. The stack pointer is now at 0x10000-0x7ff-0xb0. If a() needs to access its' save area, it would use, for example, %sp+0x7ff to access the save area for %l0, %sp+7ff+8 to access %l1, %sp+7ff+0x10 to access %l2, etc. Now a() calls b(). b() executes a save %sp, -0xb0, %sp. The current stack pointer is now at 0x10000-7ff-b0-b0. For b() to access its' save area, it would use exactly the same offsets that a() used to access its' save area, i.e., %sp+7ff for %l0, %sp+7ff+8 for %l1, etc. If b() calls c(), the same thing occurs (again, assuming minimum stack size). When b() returns, the restore pops (i.e., adds) 0xb0 bytes to the stack pointer, and you are back to the (bias adjusted value) of a()'s stack pointer. In general, there is no need to implicitly (or explicitly except for the save instruction) modify the value of the %sp register itself. Code that is using %sp to access stack locations must take the bias into account.
A diagram would help here immensely... max
