.. moving an offline discussion between me and Gerardo Richarte onto the SqueakNOS mailing list in case others are interested too. We're talking about bringing up SqueakNOS (and NOSen in general) on top of the OLPC XO's Openfirmware (a small Forth OS).
2008/9/21 Gerardo Richarte gera@corest.com:
My ugly (http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131609...) implementation of the callout mechanism is working!
I can do "interpret"("nand:") for example, and it works :)
Cool :-)
now, I ran into another problem, and I think this is a real problem: I have two (actually three) different memory managers at this point:
Is there an easy way that when starting Squeak you can allocate all the memory you will ever need (e.g. 95% of system memory) for the Squeak heap and runtime system -- and then keep all your own memory allocations inside that and make OFW happy with the leftover 5% that it can keep for itself? (Just an idea.)
I've been reading over the C "client interface" towards Openfirmware. The Firmworks manuals are not freely available (and I'm having some trouble buying them) but it turns out to be documented in the IEEE Openfirmware specification -- I didn't think IEEE docs would be on the 'net but happily this one is: http://www.complang.tuwien.ac.at/forth/1275.ps.gz
The client interface offers a well-defined interface for opening devices and making calls into their drivers' methods. That's probably just a bit neater than calling into INTERPRET with fragments of Forth source code (and if you want to use custom Forth code you can always load some new methods on the devices presumably).
More later :-)
Squeak's (Garbage collection, for which I "allocate" all available memory starting at 1MB) SqueakNOS' native memory mamanger (nothing really, just a static pointer that's incremented on avery alloc() and never decremented)
and now, Forth's (OFW's) allocator, which I think, interferes and clashes with the Garbage collector (it returns objects inside the Object Memory, but this objects are not allocated from Squeak, so the memory is actually used independently by both at the same time). This will very easily crash the system (and does as soon as I want to open a file).
So, this is a problem I have. Not sure if you'll have it (for example, you could directly relay EVERY memory allocation to OFW, and let it manage the memory for you... at least to start with).
richie
Luke Gorrie wrote:
I can do "interpret"("nand:") for example, and it works :)
Cool :-)
More accurately, what I did is:
OFW_callout("interpret",1, 0, "dir nand:\") and then OFW_callout("interpret",1, 0, "dir disk:\")
from Squeak. What I wanted to test is if the USB (disk:) and the internal filesystem (nand:) was working from within Squeak, and it is. With those two commands I saw a directory listing of both devices! But it was just for testing.
Is there an easy way that when starting Squeak you can allocate all the memory you will ever need (e.g. 95% of system memory) for the Squeak heap and runtime system -- and then keep all your own memory allocations inside that and make OFW happy with the leftover 5% that it can keep for itself? (Just an idea.)
That's a good idea. I think that some solution like what you propose will probably be the easies. However, I want to give Squeak most of the available memory so the Object Memory can grow as needed by the Smalltalk applications. My approach is to give Squeak everything for a certain address and up. When nothing else is running underneath, it's ok. But with OpenFirmware the story is a little bit different...
Building on your suggestion I may actually do something like:
allocate a big buffer before booting SqueakNOS boot SqueakNOS release the buffer.
This way I expect to create a hole in OFW's memory map, but, on one side, it's too much implementation dependent, and on the other side, I'm not sure it's going to work.
I've been reading over the C "client interface" towards Openfirmware. http://www.complang.tuwien.ac.at/forth/1275.ps.gz
That's a good pointer! tx.
I was getting ideas from the svn repository. There are a few client examples, and just yesterday Mitch Bradely told me to get a full implementation of emacs (in C) from the SVN, so I updated and it was just there! Emacs needs, of course, access to the services provided by OFW, so everything needed is actually there.
There is, in fact, a small libc-like library wrapping the services.
I've done a few tests, trying to open files, all of the unsuccessful so far :(
("open", 1, 1, "nand:\etc\passwd", 0)
is what I tested.
It returns -1 (error), but does change 0 to some pointer. So I'm not really sure if it's failing or not. I any case, I kept going ignoring the error, and tried to read from the file, but it didn't work. I'll keep trying, my fear right now is that the memory sections are clashing, and Forth objects get mangled with Smalltalk objects.
I'll keep trying. Do you have any idea what "open" is supposed to return? (a number?, a pointer?)
richie
squeaknos@lists.squeakfoundation.org
-
Gerardo Richarte -
Luke Gorrie