* Klaus Seegebarth <kseege(a)t-online.de> [020613 12:52]:
From my knowledge about OpenFirmware i remember, that
OF is a
token threaded ANS-Forth with some extensions for the device-tree
and a number of tokens (roundabout 300?) have a predefined value.
about 360 words are defined with existing fcode token.
So i would expect OpenBios to use token threading
indirect threading. If OpenBios wants strict compatibility with
IEEE 1275, isn?t this necessary ?
There was a token threading approach that I wrote last year but it
showed up to be inflexible and it's a lot easier to have a sane forth
kernel with a seperated FCode evaluator written in Forth (Which is
similar to the normal interpreter, just reading tokens from a stream
instead of Forth source).
There are quite some words that dont have an FCode token, and those
cannot be supported without exceptions in a token threaded
The tokenizer/detokenizer for C-Code is a nice feature
for all those,
who are frightened by Forth, but isn?t it just a convenient add-on,
while the token threaded Forth is the heart of the whole thing ?
It's actually just a Forth tokenizer/detokenizer _written_ in C. It does
not allow you to write C code which is translated to bytecode. There
have been some efforts in this area, but it probably does not make sense
to spend a lot of developers' resources while not having the base system
working. It's a non trivial problem generating effective Forth Code from
C source due to Forth's stack based nature. There are some papers
available on optimizing stack machines, but I am not into this..
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
- free your system..