* John R. Hogerhuis jhogerhuis@yahoo.com [020521 07:14]:
Ok, I downloaded paflof, got it building. I think you're right, Segher's code looks pretty clean. Just out of curiosity, I think there are forth-in-Cs already implemented under GPL, why not use one of them?
Most of what I've looked at is nice, but uses a different approach than what we really want. Either they compile to native code, which is nice, but not really needed and it makes the thing bigger and more complex than needed. Others try to care for lots of system interoperation issues which we don't really need. Starting from scratch normally looks like a not too smart idea, but in this case i think it is, as we know exactly that we have no overhead whatsoever. Even with lots of optimazation it might be hard to get gforth or alikes down to the size paflof has, or will have, when it's done. Every byte we safe here, means we have more space for the packages that will live on top of paflof, be it the debugging facilities, drivers, ...
How do I know which words still need implementation? How do I take ownership (make sure no duplication of work).
The only source is the code, and probably Segher ;) None of the highlevel words, like package handling, properties, exceptions, have been touched in connection with paflof. It probably makes sense to push these forward until paflof is far enough to be able to execute fcode. 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. ;)
For taking ownership for a certain task just drop a note to this list about what your ideas are. This list has been low or rather zero traffic for a while; As far as I know only Segher and me are looking at the code currently so chances that you do duplicate work are naturally pretty low.
I've started reading the IEEE 1275 spec, I should be done soon.
For anyone interested, this is the main information source that should be used for implementation - A lot of information is available in the Docs section of the OpenBIOS homepage: http://www.freiburg.linux.de/OpenBIOS/docs/
Feel free to respond to me on the list rather than directly. I'm subscribed now, but I wasn't sure how basic of information you wanted showing up on the list.
I think it is a good idea not to keep this discussion secret, as there's enough to do for _a lot_ of developers ;)
Stefan
Hi John, Stepan, everyone else,
Stefan Reinauer wrote:
- John R. Hogerhuis jhogerhuis@yahoo.com [020521 07:14]:
Ok, I downloaded paflof, got it building. I think you're right, Segher's code looks pretty clean. Just out of curiosity, I think there are forth-in-Cs already implemented under GPL, why not use one of them?
I actually looked into doing just that. I decided I didn't like them for this purpose (i.e., a generic OF for *anything* that runs linux).
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*.
Most of what I've looked at is nice, but uses a different approach than what we really want. Either they compile to native code, which is nice, but not really needed and it makes the thing bigger and more complex than needed.
I assume you mean "subroutine threaded", which is just a funky kind of direct-threaded (namely, with machine insns for tokens ;) )
Others try to care for lots of system interoperation issues which we don't really need. Starting from scratch normally looks like a not too smart idea, but in this case i think it is, as we know exactly that we have no overhead whatsoever.
Also, we need to implement _almost_ strict ANS, and a lot of extra stuff.
Also, this needs to be as lightweight as possible (hint: we can run OF while the OS is loaded, as well).
Even with lots of optimazation it might be hard to get gforth or alikes down to the size paflof has, or will have, when it's done. Every byte we safe here, means we have more space for the packages that will live on top of paflof, be it the debugging facilities, drivers, ...
How do I know which words still need implementation?
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.
How do I take ownership (make sure no duplication of work).
Short answer: you don't, right now. Sorry. But read on -->
The only source is the code, and probably Segher ;) None of the highlevel words, like package handling, properties, exceptions,
Exception handling is low-level Forth core, really.
have been touched in connection with paflof. It probably makes sense to push these forward until paflof is far enough to be able to execute fcode.
My current dev plan:
1) finish the outer interpreter (I only need to add correct number parsing, to get this step done).
2) implement the compiler (easy, really; it's designed, so not hard to implement, and the interpreter is done, so it's just pure Forth).
--> Here you all can start doing work :)
3) implement the non-ANS OF requirements
4) implement the fcode compiler. Not hard, either.
5) finish 1) to 3)
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.
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.
For taking ownership for a certain task just drop a note to this list about what your ideas are. This list has been low or rather zero traffic for a while; As far as I know only Segher and me are looking at the code currently so chances that you do duplicate work are naturally pretty low.
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).
I've started reading the IEEE 1275 spec, I should be done soon.
For anyone interested, this is the main information source that should be used for implementation - A lot of information is available in the Docs section of the OpenBIOS homepage: http://www.freiburg.linux.de/OpenBIOS/docs/
Feel free to respond to me on the list rather than directly. I'm subscribed now, but I wasn't sure how basic of information you wanted showing up on the list.
Assume anything is OK, unless not ;)
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.
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..
* 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
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..
-
Segher Boessenkool -
Stefan Reinauer