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..