Stefan Reinauer wrote:
- Segher Boessenkool segher@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 after all, 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, for example...
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 word.
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 it.
Great :)
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..