Stefan Reinauer wrote:
basically one of the problems we see before we can
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
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
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
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
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
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
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
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(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
- free your system..