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 :)
We should clearly split these two parts
You can't fully separate them (you can only do it artificially, that is).
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.
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 ;)
That would work, if enough open 802.11 networks existed :) I'm on the road a lot these days.
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.
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 ;)
That's a new make flag to me... time to read more docs, I guess.
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).
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.
What about
0 EXECUTE
or anything with unaligned accesses, for example.
We _cannot_ check whether any xt (or other address) is *actually* valid.
Too much checking will slow us down too much (but yes we need a *little* more safety brakes).
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 :)
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.
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).
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.
A-ha! Now that explains things ;)
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 :)
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..