On 5/15/10, Mark Cave-Ayland mark.cave-ayland@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.