[OpenBIOS] forth kernel and dictionary dumping
segher at koffie.nl
Sat Oct 19 01:27:53 CEST 2002
Stefan Reinauer wrote:
> 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
Unreadable?! It's almost straight Forth! ;)
> 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
It can already do this, or I don't understand what you mean?
> * the c core can be developed seperately from the forth code running
> on top of it.
You have to link in the Forth dictionaries anyway (the base dict + what
you need to read from disk, at least), so having to compile them too isn't
a huge burden, /me thinks. Also, the kernel is already finished, it just
needs some minor cleanups.
> * 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.
You need the base to be able to compile the base. Chicken egg. You
need a crosscompiler to be able to generate your first base dictionary;
it just so happens that our crosscompiler is ref.pl + gcc.
> * it will be easy to change the amount of packages/features that
> will be flashed.
That is the case for any setup.
> 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.
You only need to run FCode from plugin cards, so that's not exactly
> 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)
It's less than 1kB.
> 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.
ELF won't work cross-platform. I'd rather have the only distinction
be 32/64/BE/LE, so we only have 4 different binaries per dictionary,
and we even can generate them all from one build only. There is _no_
binary relocatable format that's supported by most people's binutils,
> 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.)
This makes me think your dumper/loader doesn't implement vocabularies...
> 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.
Better relocate by name; that solves that problem, and reduces the number
of relocation types to just one.
> I also managed to write a new prim word to the dictionary, using
> 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)
This happens to be right on 64-bit formats, too ;)
> ' DUP @ , \ fetch old prim CFA
> DUP \ update LAST/LATEST to the beginning of the new word DUP
> LAST !
> LATEST !
Also note that the internal dictionary format can change at any time, so
please don't have anything rely on it.
> 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
I'll take a look.
To unsubscribe: send mail to majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..
More information about the openbios