* Segher Boessenkool segher@chello.nl [020522 01:46]:
The biggest thing is, I need indirect-threaded code, to simplify interfacing with the OS (or make it possible, even). The fact that indirect-threaded code is faster than direct-threaded code on about any architecture (except intel x86) is a nice plus, but not really affecting this design. It will be fast enough *anyway*.
I see that indirect threading looks saner in some way and a lot easier to handle. The interpreter executing XTs has control over the situation after every atomic execution, so debugging and single stepping etc seem a lot easier to do than with subroutine threading. In which way is this an advantage for interfacing the OS, though?
Also, this needs to be as lightweight as possible (hint: we can run OF while the OS is loaded, as well).
This is my intention as well. feval, my not so nice implementation ;), runs all test programs and is a userspace program which should work on any system with an ANSI C compiler. As LinuxBIOS is capable of running ELF images after Dram setup, it is the perfect bootstrap for paflof. All that needs to be done is add some basic functions that are taken from libc when running in userspace (printf, strcpy, malloc,..) Testing should be possible with bochs, or soon on a running system that is supported by LinuxBIOS. Writing a null bootstrap for LinuxBIOS so it can run in Bochs as well, should not be too hard.
Read the spec :)
Also, I have a file (I hope I checked it into CVS) with all of the required words, and the paragraph in the spec where these words are defined.
It probably makes sense to grab a complete entity of similar/connected words and implement those together, like all words that have to do with properties i.e. This should in the beginning be enough to prevent work being done twice.
- implement the compiler (easy, really; it's designed, so not hard to
implement, and the interpreter is done, so it's just pure Forth).
- implement the fcode compiler. Not hard, either.
These two should be pretty similar, except the one takes plain text words, whereas the other works on FCode tokens?
Btw, I do _not_ want most of our "modules" to be FCode; I'd rather have them as Forth source. FCode is somewhat smaller (mostly because it doesn't contain comments ;) ), so our package loader should be transparent to file format.
As we have the tokenizer, it should not matter what is running in the system later on. FCode bytecode is tokenized from the forth source of the modules. It might be worth using FCode when a module is tested to safe space on the flash medium.
Also the existing tokenizer/detokenizer need a lot of testing, which I can only do little, as I am not a long time forth expert. ;)
The tokenizer is the more important of the two.
And I noticed I have some overflow bug in it. http://www.freiburg.linux.de/OpenBIOS/bin/AAPL-8250.4th gives me test.of:71: error: buffer overflow. test.of:158: error: buffer overflow. test.of:163: error: buffer overflow. test.of:173: error: buffer overflow. test.of:253: error: buffer overflow. [...] This seems to be introduced with some patches I made since end of march. I'll look into this asap.
If you want to start on some package not involving the "core" OF stuff itself, please do already! For example, you can write an ext2fs reading thingie, and even test it (by loading it into some other vendor's OF).
A PCI package would be extremely useful, as this would allow that all PCI device setup LinuxBIOS does now in native code can be done in Forth/FCode soon, thus stripping down LinuxBIOS and getting OpenBIOS take over this "highlevel initialization" as soon as paflof is ready for prime time.
I think it is a good idea not to keep this discussion secret, as there's enough to do for _a lot_ of developers ;)
Oh yes, there's millions of devices to support... sigh.
And many device specs are not available without NDA - BAD. But as soon as we have some basic things to show it can be done, there is a much better base for negotiaton.
Stefan