Ein Klein Forthmusik...

Here's how you read forth code by example:
Say you wanted to know everything about what the forth method "ls" did...
(hitting enter is shown as )

0 > ' ls  ok
1 > .  -7E2EE0 ok

-7E2EE0 is the forth execution token for "ls".  The execution token is actually
a 32-bit signed address of where in memory the fcode/machine-code lives.  It is
actually 0x100000000-7E2EE0 or FF81D120.  This is very reminiscent of AppleSoft
Basic, where you would memorize signed decimal 16-bit "CALL" ROM routines (like
the infamous CALL -151), only in hex, because the negative number is shorter,
since the ROM is towards the end of memory.  Get it?

OK.  Now, if you wanted to "see" the forth code for "ls", you'd do:

0 > see ls 

And you would see the forth code.
This is the equivalent of saying:
0 > -7e2ee0 (see)

or

0 > ff81d120 (see)

It's all the same thing.  Now, many methods are themselves made up of other
compiled fcode routines, which are indicated by a ^ followed by the negative
hex address.  You can use (see) to traverse nested fcode routines in this
manner.  If you are following a particular execution token (address), to 
another, to another, and end up simply with "code ^-12345678" (or whatever
address), this means that a machine code routine is being called at that
address.  Fcode routines are frequently combined with machine code routines
that handle the lower level device oriented stuff.

Given this, we have two problems:
1)  We don't appear to have a disassembler in OF!  Attempting to use the
"dis" method to disassemble a ppc machine code routine just lists it out
in HEX!  I'm assuming this unfortunate circumstance is what prompted the
creation of xmon.  We really got the short end of the stick with OF.
OK, you say, I know the address of a routine in ROM now, and I want to
boot up some OS and use my favorite debugger to disassemble the machine code
(let's say linux and xmon).  This leads to the second problem...

2) The OF PROM appears to be remapped after you boot!  It's probably just
a matter of figuring out TO WHERE, since the contents of a given address in
OF PROM doesn't match what you see when you look in linux or macos.  This is
what leads me to believe it's getting switched out or remapped.

I hope this sheds some info on the OF enigma.
Comments/insight welcome!

-Mark

Mark Abene wrote (in an excellent outline of disassembling Forth):

> 0 > ' ls  ok
> 1 > .  -7E2EE0 ok

Note: you can use u. instead of . if you want to print it as an
unsigned number (FF81D120 here).

> 2) The OF PROM appears to be remapped after you boot!  It's probably just
> a matter of figuring out TO WHERE, since the contents of a given address in
> OF PROM doesn't match what you see when you look in linux or macos.  This is
> what leads me to believe it's getting switched out or remapped.

Powermac/Linux reclaims the 1MB of RAM used by OF at a relatively
early stage in the startup process.  It's done in mem_init in
arch/ppc/mm/init.c, in the section starting with the comment
/* free the prom's memory */ and ending with the statement
prom_trashed = 1;.  You could put #if 0 ... #endif around this if you
wanted to look at OF's memory later.

Paul.