On Fri, Feb 02, 2007 at 05:41:23PM +1000, leon zadorin wrote:
> yead - cool - thaks for that, although there is a little cloud in my
> head as to why one would have no store high 16bits of variable's
> address in the high 16bits of some register only to add them back to
> the low 16bits of the variables address... but I will "chew" on that
> one...

The immediate data in the instruction is only 16 bits.  So you can
only load 16 bits at a time.  You can also treat 16 bits as signed
(-32768 .. 32767) or unsigned (0 .. 65535).  If you're using an
register indirect with displacement load or store, the displacement
is a signed quantity.  If you're loading a 32-bit value directly,
you could do:
	lis	8, label@h
	ori	8, 8, label@l

In which case the immediate data in the 'ori' is unsigned.  So you
need to know how you're using the label to know how to assemble it.
If label@l is 0..32767, then label@h and label@ha are the same, but
you don't know the actual value of label, as a rule, until the code
is assembled and being linked.

> in the meantime... it would appear that when the code jumps from
> kernel back to openfirmware (i.e. that "blrl" call in the above posts)
> that perhaps the msr register gets reset and ends up generating the
> interrupts...

Yes.  But we should have stored the operating environment for
OpenFirmware to allow it to run with its exception handlers, etc.

Maybe there's a heartbeat that's not getting called and the
decrementer is being used as a watchdog timer for OFW.  I wonder
what would happen if we saved the decrementer and set it to some
higher value before the call into openfirmware and then restored
the value after the call.  We would lose some number of decrementer
ticks, but we could theoretically subtract those before restoring.

-allen

-- 
Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  briggs@ninthwonder.com