Hi John, Stepan, everyone else,
Stefan Reinauer wrote:
* John R. Hogerhuis <jhogerhuis(a)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
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
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
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
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
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
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).
started reading the IEEE 1275 spec, I should be
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:
> 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
Assume anything is OK, unless not ;)
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.
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
- free your system..