* 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. 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.
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 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.
and have a clear way of predefining dictionaries that are later used with paflof. Forth's strength is factorization, and we should use this design idea through out all the way. The base stuff is done and working. The fact that we don't have an assembler/disassembler or package support etc has nothing to do with paflof itself
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.
But how do you want to include auto-types? We could include the file, and do an #ifndef type_X typedef .... #endif in types.h
I'm not sure anymore :) Figure out a way to do it cleanly, with as little code as possible, and I'm sure we'll agree.
I still do not see any need for a fixed types.h - I will make creation of the types.h conditional in the Makefile. This is a clean solution and will not hurt. Besides - On an x86 it will always output the same file as the one you put in cvs, so i do not see any problem here.
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.
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
Yes, this is quite a bit overhead, but we don't want anything to crap out early when we run from flash.
So write good code for boot drivers :)
As soon as there is a way of externally plugging dictionary dumps into paflof I will look into package handling. (Started some stuff, but no usable results yet)
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.
It is easy to fix, but I did not find the time to make a patch yet.
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.
Stefan