[OpenBIOS] forth kernel and dictionary dumping

[Segher Boessenkool]

Stefan Reinauer wrote:
> 
> Hi,..
> 

Howdy,

> 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.

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
"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)

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,
sorry :(

> 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
> 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)

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
> 
> http://www.freiburg.linux.de/OpenBIOS/bin/paflof-dump-20021016.tar.gz

I'll take a look.


Cheers,

Segher

-
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..