* Klaus Seegebarth kseege@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 instead of 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 implementation.
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..
Best regards, Stefan Reinauer