segher at chello.nl
Sun Jun 30 13:52:30 CEST 2002
Stefan Reinauer wrote:
> * Segher Boessenkool <segher at chello.nl> [020628 15:29]:
> > > I am talking about the Forth engine, not the whole implementation of
> > > Forth words, as described in the IEEE 1275-1994.
> > Paflof -- Portable And Flexible Linux Open Firmware
> > It's not just the Forth engine :)
> Then you should work on making it like that. Nothing against some small
> parts that break a rule because it makes sense. But we have to be
> careful not to pack too many things together that can be done seperately
> without giving you any disadvantages.
I don't understand this paragraph, sorry. Maybe you can rephrase it?
> Besides, the name is somewhat misleading. OpenBIOS' goal has nothing to
> do with Linux, besides Linux is _one_ of the Operating systems we can
> boot with it.
Paflof != OpenBIOS. The "Linux" part of the name of Paflof is _not_ misleading,
as Paflof's goal is to provide an OF implementation for all Linux systems.
Of course it's fine to boot other OS'es with it, though :) ; it's OF
so any OS that can boot as an OF client can use it.
But this is where the "you need GCC to build it" constraint comes from,
> > > We should clearly split these two parts
> > You can't fully separate them (you can only do it artificially, that is).
> Still paflof should not contain anything but the prim words and a bare
paflof, the executable, you mean?
> base dictionary which covers the forth language group and not the other
> stuff that can be done a lot better as an extension where it is not
> making components more complex than absolutely necessary. If we want
> OpenBIOS to be used in embedded systems we will have to proof certain
> runtime behaviour, which is a lot easier if it is clearly defined which
> component does which tasks.
The Forth language group _itself_ will be a couple of "extensions", already.
> > I don't think I'll do an assembler _ever_, and the disassembler can surely
> > wait until client program debugging support implementation time.
> Me neither. But OpenBIOS is an Open Source project - If people need it,
> they will do it. If paflof is clean and "bug free" we will not even need
> a disassembler. One more reason to keep Paflof as small as possible.
A disassembler is mostly useful for debugging the *client* program (== linux),
not the host (== paflof) itself.
> > > we should add stack checking to the prim words that need it in the
> > > firmware version.
> > Adding it to INTERPRET should be enough. That, and a "guard area" around
> > the stacks (which we already have; and the guard area generates the MMU
> > trap, currently).
> still, interpret does not know the stack characteristics of an executed
It doesn't need to. It only needs to check for stack underflow and overflow,
to prevent *horrible* crashes; it can't actually prevent crashes themselves.
> > Too much checking will slow us down too much (but yes we need a *little*
> > more safety brakes).
> ack. Though all OF implementations I've been working with had stack
> protection. and I consider a dup with nothing on a stack something that
> happens by accident, whereas you only get an xt with open firmware
> functions. 0 EXECUTE is something that can almost be considered
> crashing on purpose
0 EXECUTE is exactly the same kind of programming error as a DUP on an empty
stack: someone forgot to check some return value ;)
> > There's no reason to not use the MMU when you have one -- and you *need*
> > to use it, if you run in a host environment (instead of on raw hardware).
> > (In this case, the MMU is actually the OS VM system).
> Yes, there is. It adds complexity to the system where we can cope with
> some simple checks and keep the same codebase running on a lot more
> systems. For now, this is not the most severe matter though.
That's what DEFER words are for, and [IF] ... [THEN] .
> > So I can assume our signals are correct posix signals, and write an actual
> > SEGV handler? That's great :)
> yes. The only reason it is not there on alpha is someone forgot to do
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..
More information about the openbios