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?
It makes a clear separation between code and data memory (executable/ non-executable and read-only/read-write memory).
This also takes care of code<->data synchronization, as we don't need any. (Except while booting a binary file).
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.
Paflof can run _before_ the OS boots, _while_ the OS boots, _after_ the OS boots, and both in kernel or user space :)
Well right now, it only runs in user space, of course ;)
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,..)
All of these are handled by Forth. The only thing that current Paflof needs from "BIOS" (as there are no devices implemented yet) is getchar() and putchar() or the equivalent. These are somewhat hardcoded right now but should be DEFER'ed.
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.
Testing of all non-device-driver and non-system-critical-device-driver stuff can be done from userland Paflof :)
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.
The list I mentioned is sorted as it is in the OF spec, so that's (somewhat) topical.
- 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?
The FCode parser is mainly just a loop that creates a list of :NONAME and "real" words, converting one FCode token at a time (via a big table, mostly :) ), and executing all of these in order. Maybe executing them while they are parsed, even.
The biggest difference between the FCode parser and the Forth compiler is, the Forth compiler can switch back and forth between compiling and interpreting, while the FCode parser is a lot less complicated.
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.
Yes. Loading the modules from source, from the fs, is somewhat more flexible, though :)
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.
Go ahead, I won't stop you :)
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.
We also van run binary-only modules; that's the great thing about FCode :)
Cheers,
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..