[OpenBIOS] Missing portid properties

[Blue Swirl]

On 5/3/10, Tarl Neustaedter <tarl-b2 at 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.