Hi,..
basically one of the problems we see before we can ever push OpenBIOS to flash is that we need a way of getting Forth code executed that is not part of paflof's unreadable preprocessor magic. I've started writing code to dump a dictionary from within paflof and read it back in. This gives several advantages:
* paflof can be used to bootstrap openbios forth code * the c core can be developed seperately from the forth code running on top of it. * the base engine can be changed easily as it will be rewritten in forth instead of generating a binary dictionary with the C preprocessor as it is done now. * it will be easy to change the amount of packages/features that will be flashed.
This is needed because we don't want to feed forth source to the C core while running from flash, but rather compiled forth and FCode. Before we can run fcode, we need a way of making the evaluator I wrote accessible from paflof during early bootup.
One of the nice side effects is that the C kernel can be reduced in size (it is now 17k, most of it being debugging information)
How does the thing work?
Currently there's a word DUMP-DICTIONARY which will dump the current dictionary to a relocatable ELF file dict.dump, that will be loaded automatically when paflof is started the next time. There is one minor glitch left to fix, but it can be worked around manually: LAST/LATEST is not set correctly after bootup (well, it is, but it's overwritten again.) When loading, it will tell you "LAST/LATEST=0xDEADBEEF" shortly before the ok prompt. then do a "DEADBEEF DUP LAST ! LATEST !" to make the loaded words actually visible. after that all should work as usual, just with a loaded dictionary.
Maybe this glitch can be worked around when moving the engine.in to engine.fs as there will be a new LAST/LATEST. (which will not be used until :, VARIABLE, CONSTANT etc are redefines. It might be enough to just set this to a valid value just before : etc are defined (which would require the dict.dump to be the only dictionary, with no other dictionary left)
There's currently three kinds of relocations in the ELF file: Internal, external and CFA relocations.
* Internal relocs are just references within the dictionary. To fix these up, the old start address of the dictionary is subtracted and on load, the new address is added. * external relocs. These reference an external word in the dictionary. if you use DUP, for example, it will relocate against that word, no matter whether it's moved around in the dictionary. * CFA relocations are used to relocate against native prim words (code) paflof keeps a list of prim words and relocates them by a list index. This means a dictionary has to be redumped when the number of prim words changes.
I also managed to write a new prim word to the dictionary, using HERE LAST @ , \ backlink 0 C, \ flags 3 C, 44 C, 55 C, 50 C, 0 C, 0 C, 0 C, \ 0 padded name (only on 32bit machines) ' DUP @ , \ fetch old prim CFA DUP \ update LAST/LATEST to the beginning of the new word DUP LAST ! LATEST !
What will be the next step in development?
We need to finish the engine.fs (a rewrite of engine.in in pure forth) that I already started. this is going to be the next bigger goal in development. After that dictionary scopes will be a lot easier to implement as it does not have to be done in preprocessor macros.
Last but not least, get the code at
http://www.freiburg.linux.de/OpenBIOS/bin/paflof-dump-20021016.tar.gz
Any comments, flames, tests, etc are heavily welcome.
Best regards, Stefan Reinauer