[OpenBIOS] ANSI

[Stefan Reinauer]

* 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.
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

-- 
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..