Greg Price wrote:
>
> Hi,
>
> The bias is only used in 64 bit mode, and it's part of the ABI (which
> Max had said).
>
> The bias is applied to the loads and stores that reference the stack
> and frame pointers, but not the instructions that adjust the
> stack/frame pointer (i.e. you won't see the bias in save or restore
> instructions).
>
> It's a not a bias area, but it's biasing the frame pointer to give you
> greater reach on one side. SPARC has fixed size instructions, and the
> offsets for the loads & stores are fixed at 13 bits (i.e. an 8K span).
> The stack/frame pointer is used to access the incoming args, local
> variables and outgoing args. If a bias were not used, the amount of
> memory that could be "reached" above or below the pointer would be
> equal (4KB each side). While the space available for incoming and
> outgoing args should be the same, local variables are kept in the
> stack frame, and are only ever accessed by the owning function itself.
> When we are going to pass args to a function, we store them in the
> callers frame, then after the function call happens, then callee
> accesses them from the callers frame.
>
> Because we only ever need to get arguments from the callers frame, we
> don't need to be able to reach very far on that side of the pointer,
> so to give us more space for local variables (which are in our own
> frame), we apply the bias (2KB) to all the loads and stores that
> access incoming args, outgoing args and local variables. This means
> we're limited to 2KB of incoming args, but about 6KB of outgoing args
> AND local variables.
>
> Make sense?
The stack pointer is initially set to the top of the stack plus the
bias. From this point,
the save instruction does not need to do anything as far as the bias is
concerned.
There are a few places where the stack pointer is initialized, depending
on the thread
being created. Take a look at the thread_load function, called when a
thread_create is
done to create a thread, specifically, line 189 in
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sparc/os/sundep.c#189
Also, you'll see that the code that saves register windows needs to be
bias aware.
Take a look at in sun4u/ml/trap_table.s for code that handles register
window spill/fill
traps.
Also, if the offset value in an instruction could be, for instance,
64-bits, the following would
work, and the bias would not be needed...
ld [%sp + 0x100000], %l0
Instead, because the offset is a signed, 13-bit value, this code needs
to look
something like:
sethi %hi(0x100000), %l0
or [%l0 + %lo(0x100000)], %l0
ld [%sp + %l0], %l0
(Of course, an optimization here would be to skip the middle instruction
because the low
order 13 bits in 0x100000 are 0).
Even if the offset value could be greater than 13 bits, the bias is
still useful
as it gives the window spill/fill code a quick way to see if the
spill/fill is 32 bit
or 64 bit (check the low order bit of the %sp, if 0 it is 32 bit, if 1,
it is 64 bit).
max
>
> Cheers,
> Greg
>
>
