On 5/3/10, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2010-5-3 8:16 AM, Mark Cave-Ayland wrote:
Tarl Neustaedter wrote:
Those are all SPARC registers. What it's doing is copying the registers
to a buffer, presumably to be restored later.
It looks like the trap registers (%tstate, %tnpc, %tt) are prefixed by
%tl-c - which is presumably the trap-level pointer.
Another thought about this: surely the act of invoking normal functions
within OpenBIOS is enough to cause the register window to shift. Does that mean that the CIF needs to take a snapshot of the registers upon entry and then map this snapshot to forth words such as %g0, %g1 etc.? Otherwise it all seems a bit useless.
This all involves stuff from (assuming you have access to the open-sourced OBP sources) obp/cpu/sparc/fentry9.fth .
forth-entry is how Solaris calls into OBP's client-interface. Notice it stashing registers away on stack.
return-to-c is how forth returns from a client-interface call, restoring stuff.
The actual register definitions are in obp/cpu/sparc/register9.fth - notice it defines them with out-regs, local-regs, and global-regs, which are complex constructs allocating space from the heap and setting up use-actions for them referring to the cpu-state blocks. References to %o7 ect. refer to these variables rather than the live registers.
Unfortunately, this is black magic that I don't understand - I've not dived into the guts of our forth/c interface much before.
Maybe we could reuse our register context handling here (arch/sparc64/context.c). Client's context could be passed by start_elf, or just make the context global.