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. http://dev.haiku-os.org/ticket/6071#comment:3 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?
variable callback-function
: set-callback ( newfunc -- oldfunc ) callback-function @ swap callback-function ! ;
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 :)
ATB,
Mark.