Andreas Färber wrote:
No, not yet. I did some of the cleanups I announced
first and ppc64 is
not in a booting state yet. It hangs after "Trying cd:,\\:tbxi".
Right now I'm trying to figure out why Blue is having troubles compiling.
I've also been investigating why Haiku hangs again.
It hangs while setting up the segment registers (mtsrin).
Hmmm that's probably going to require more PPC-fu than I have.
I noticed that Haiku uses the set-callback ciface
method shortly before,
but it appears that we only save the callback-function in
forth/system/ciface.fs and - according to grep - never use it elsewhere.
Shouldn't every ofmem function check if we have a non-zero
callback-function (how? Cf. below) and then call that instead?
: set-callback ( newfunc -- oldfunc )
AIUI the callback function provides a way for open firmware to call a
function within the client image, e.g. allow a Forth function to invoke
a "named" C function within the kernel image. I don't believe it is
related to OFMEM at all.
For AIX I'm looking into the machine support:
I noticed there's provisions for the PReP machine but that errors out in
QEMU so I couldn't test. I'm pretty sure that enabling AAPL stuff on
PReP would be wrong though (is_apple() == 1). Also, a new IBM PReP
machine may get contributed to QEMU, requiring adjustments in OpenBIOS.
To emulate an IBM CHRP machine I need to fix ofmem and PCI code to
handle 64-bit addresses.
Once that is done I'll probably get back to my RTAS investigations for AIX.
So, quite a long list ahead still. Which is why I'm a little impatient
to get the next obvious bugs fixed while avoiding bikeshed discussions
about possible cleanups. ;)
Yes, I remember experiencing similar things with SPARC where 1 TODO item
would end up becoming 3-4 TODO items as I found more dependent bugs :)
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs