segher at chello.nl
Fri Jun 28 16:29:28 CEST 2002
> 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
> 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.
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 :)
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..
More information about the openbios