[OpenBIOS] ANSI

[Segher Boessenkool]

> 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 at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..