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).
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)
the compiler (easy, really; it's designed, so not hard to
implement, and the interpreter is done, so it's just pure Forth).
4) implement the fcode compiler. Not hard,
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
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,
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
Go ahead, I won't stop you :)
I think it is a good idea not to keep this discussion
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 :)
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
- free your system..