[OpenBIOS] ANSI

[Stefan Reinauer]

* Segher Boessenkool <segher at chello.nl> [020626 07:57]:
> > > I still prefer just requiring gcc-3 (although it currently works "fine"
> > > with 2.95 as well) (except on some 64-bit targets).
> > 
> > Agreed. Though it does not hurt to start looking into portability early
> > especially as Paflof is close to complete now.
> 
> "close to complete"?!?  muahahahahaha!
> only 7.3 ("Forth language command group") is anywhere near complete yet.
 
I am talking about the Forth engine, not the whole implementation of
Forth words, as described in the IEEE 1275-1994. We should clearly 
split these two parts 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

> > > Please keep types.h intact, and have it include an auto-types.h or
> > > something like that.  Much easier if you want to bypass the automatic
> > > stuff for whatever reason.
> > 
> > It's enough to touch types.h before doing a "make". Another idea would
> > be to give a parameter to conf.pl to create a default config. keeping 2
> > instances of the same file seems a bit unclean.
> 
> touching is not good enough, certainly not when you use CVS.  oh, and my
> system clock tends to reset itself to 1904.

xntpd is your friend ;)  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 

> > this forbids using conf.pl on the command line, as they're set by
> > make, not sh.
> 
> I think that's the lesser of two evils...
 
make -e solves the other evil ;)

> > Uh.. nulling out reserved words...
> 
> not.  they'll only be nulled out when compiling with a non-C99 compiler, and
> it's not a reserved word then :)
 
good point. ;)

> Well if the signal handler would actually work on _all_ linux systems,
> i'd get rid of the code, but i think i'll have to change it back now.
> 
> anyway, this (and most other "more evil" parts of paflof) is just in the
> "paflof runs as client on a unix host" version of the code (which is the
> only one in existance right now, of course).
 
we should add stack checking to the prim words that need it in the
firmware version. of course one can always crash the forth engine by 
compiling crap into the dictionary but we capture most of the crashes
when we check stack depth before we access the stack.
Yes, this is quite a bit overhead, but we don't want anything to crap
out early when we run from flash. Using MMU should not be the way to go
as many embedded systems don't have one - and those are among the
systems that profit most from an OpenBIOS.

I looked into the kernel code for signal handling on alpha and i386 and
the siginfo struct is never filled on alpha, which is simply a mistake
in the existing code. It is easy to fix, but I did not find the time to
make a patch yet.

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