[OpenBIOS] Re: OpenBIOS

[Stefan Reinauer]

* Segher Boessenkool <segher at 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.

> 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).
 
> 4) 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
  
-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
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..