[OpenBIOS] Re: OpenBIOS

[Segher Boessenkool]

Hi John, Stepan, everyone else,

Stefan Reinauer wrote:
> 
> * John R. Hogerhuis <jhogerhuis at 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 at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..