[OpenBIOS] Missing portid properties

Blue Swirl blauwirbel at gmail.com
Sat May 15 15:52:41 CEST 2010


On 5/15/10, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> wrote:
> Tarl Neustaedter wrote:
>
>
> > 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.
> >
>
>  After quite a bit of time studying the obp code, I think I see what's
> happening here. On the surface, it looks as if obp/cpu/sparc/registers9.fth
> only saves/restores the globals. However, if you look deeper, it looks as if
> the default simple trap handler in OpenBOOT references a global state area
> (indexed by window pointer) to store the current state before invoking the
> handler. This area can then be accessed from Forth using the standard
> functions.
>
>  So I believe the correct thing to do is to alter the window fill/spill trap
> handlers so that they store the current CPU state in the global area, and
> then add some code to OpenBIOS to allow this code to be accessed from C and
> Forth. Does this sound right to everyone? If this is the approach required,
> any ideas/help would be appreciated since SPARC is not my native ASM ;)

I don't think so, window fill/spill is triggered also inside OpenBIOS
when the call stack exceeds 8 at the latest.

I'd enhance the context handling, it's used during client interface
entry. The CPU state is also stored in a global area which could be
accessed.



More information about the OpenBIOS mailing list