* Segher Boessenkool segher@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