ANSI

[Stefan Reinauer]

Hi,..

I played a bit with the paflof sources and made them compile 
cleanly using gcc -ansi. I had to remove the C99 specific
*restricted stuff (which did not change performance at all)
Second issue was to replace C++ style comments as they are
not allowed in ANSI C. The patch changes any occurence to
either #ifdefs if it's code or C style comments in case of 
real comments. I checked it against the hayes test and
got the same output as with mainstream paflof.

I strongly suggest to apply this patch - this would allow a lot
more people to use paflof and probably get this compiled on
almost any host system.
Please comment on the patch. If there is no good reason against
it, this is definitely the way to go.

Best regards,
  Stefan Reinauer

Stefan Reinauer wrote:
> Hi,..
>
> I played a bit with the paflof sources and made them compile 
> cleanly using gcc -ansi.
>
> [snip...snip]
>
> Please comment on the patch. If there is no good reason against
> it, this is definitely the way to go.

100% agreed

Regards

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Stefan Reinauer  [020617 17:07]:
> I played a bit with the paflof sources and made them compile 
> cleanly using gcc -ansi. I had to remove the C99 specific
> *restricted stuff (which did not change performance at all)
> Second issue was to replace C++ style comments as they are
> not allowed in ANSI C. The patch changes any occurence to
> either #ifdefs if it's code or C style comments in case of 
> real comments. I checked it against the hayes test and
> got the same output as with mainstream paflof.

After fiddling a bit more I changed the patch so it does not
necessarily disable *restrict and other (not-used-yet) features
from C99 as the upcoming gcc HEAD will probably change the fact
that these are more or less noops.
There was some discussion on this list on probing compiler 
features before actually using them instead of making vague assumptions
on what version supports which feature. 
Instead of using a vast amount of autoconf/automake magic, I wrote a
small perl script that calls the compiler with simple code fragments
and analyzes these afterwards using nm. This way it is also
usable when cross compiling. Basically the patch removes types.h 
as it will be autogenerated plus the already known ANSI fixes (mostly
applying a regexp to change comment style)
The configuration script conf.pl also checks for available data types 
and chooses the needed ones to set up the internal structures.
gcc's TI mode is probed and, if available and needed, it is used.

Any comments? ;)

Stefan

Stefan Reinauer wrote:
> After fiddling a bit more I changed the patch so it does not
> necessarily disable *restrict and other (not-used-yet) features
> from C99 as the upcoming gcc HEAD will probably change the fact
> that these are more or less noops.
> There was some discussion on this list on probing compiler 
> features before actually using them instead of making vague assumptions
> on what version supports which feature. 
> Instead of using a vast amount of autoconf/automake magic, I wrote a
> small perl script that calls the compiler with simple code fragments
> and analyzes these afterwards using nm. This way it is also
> usable when cross compiling. Basically the patch removes types.h 
> as it will be autogenerated plus the already known ANSI fixes (mostly
> applying a regexp to change comment style)
> The configuration script conf.pl also checks for available data types 
> and chooses the needed ones to set up the internal structures.
> gcc's TI mode is probed and, if available and needed, it is used.
>
> Any comments? ;)

Sounds very nice. Particularly because i hope that i can omit it 
and edit "types.h" by hand :-)))

I like automatic things, which _can_ be switched off simply. So i 
would ask for the presence of at least one "generic" types.h file.

Just my 2 EuroCents

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> There was some discussion on this list on probing compiler
> features before actually using them instead of making vague assumptions
> on what version supports which feature.

I still prefer just requiring gcc-3 (although it currently works "fine"
with 2.95 as well) (except on some 64-bit targets).
> Instead of using a vast amount of autoconf/automake magic, I wrote a
> small perl script that calls the compiler with simple code fragments
> and analyzes these afterwards using nm.

Good :)  The autoevil suite is, well, evil ;)
> This way it is also
> usable when cross compiling. Basically the patch removes types.h
> as it will be autogenerated plus the already known ANSI fixes (mostly
> applying a regexp to change comment style)

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.
> The configuration script conf.pl also checks for available data types
> and chooses the needed ones to set up the internal structures.
> gcc's TI mode is probed and, if available and needed, it is used.
>
> Any comments? ;)

Walkthrough :)  :

-CFLAGS = -Wall -W -std=gnu9x -g -O2 # -pg
+CFLAGS  = -Wall -std=gnu9x -g -O2 # -pg

Why remove -W ?  It's soooo useful :)

+CC     = gcc

I removed this for a reason ;)   Just   CC=gcc make   if you need it...

+NM     = nm -t bsd

Not all nm's are GNU nm.  Different nm's outputs are similar enough to
be parseable with a simple regexp.

-paflof.o paflof.s: paflof.c prim.code prep.h dict.xt
+paflof.o paflof.s: paflof.c prim.code prep.h types.h dict.xt

Ah yes, I forgot.  Thanks.

+$CC="gcc -std=gnu9x";
+$NM="nm";

Better just use sh's already-set variables for this.

+sub check_size
+{
+       my $what=shift;
+       my $attr=shift;
+       my $include=shift;
+       
+       # create .test.c file
+       open(F, ">.test.c");

Don't hide temporary files -- if you feel they clobber the source dir,
create them somewhere else (like, /tmp).

+# Check for restrict keyword.
+my $answer="no";
+print("\nChecking whether we can use the restrict keyword (C99)... ");
+print(I "\n#define __RESTRICT__ ");

The C compiler already defines __STDC_VERSION__ to 199901L or greater if
C99 features are supported.

-//#define DEBUG_STACKS
-

Don't remove this, please ;)  #undef it, if you want, but keep all compile-time
flags at the top op file :)

#include <stdio.h>
 #include <stdlib.h>
+#define __USE_XOPEN_EXTENDED
 #include <unistd.h>
-#include <string.h>
+#define __USE_MISC
 #include <sys/mman.h>
+#include <string.h>
 #include <termios.h>
+#define __USE_POSIX
+#define __USE_POSIX199309
 #include <signal.h>
 #include <fcntl.h>

This isn't exactly making stuff more portable, now is it?

struct interpreter {
-       cell *restrict data_stack;
-       cell *restrict return_stack;
-       cell *restrict dictionary;
-       char *restrict tib;
-       char *restrict pockets;
+       cell * __RESTRICT__ data_stack;
+       cell * __RESTRICT__ return_stack;
+       cell * __RESTRICT__ dictionary;
+       char * __RESTRICT__ tib;
+       char * __RESTRICT__ pockets;
        void *here;
 };

It would have been simpler had you done
#define restrict
if restrict isn't supported...

+#if 0
+       free(i->data_stack);
+       free(i->return_stack);
+       free(i->dictionary);
+#endif

#if 0  for commenting out code is evil, imho.

Well, I'll get to it.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[John R. Hogerhuis]

OFF TOPIC !

Niggling point from a C programmer with a few gray
hairs in his beard:

#if 0
#endif

is in fact the One True Way to comment out a block of
code in ANSI C, since you can't use //
and /* */ doesn't nest (i.e. you want to comment out a
block of code that has a smaller block commented out
already.)

Yeah it's harder to see, but it always works and never
leaves you scratching your head wondering why
commenting out a code doesn't seem to have the exact
intended effect.

On the other side, I don't like seeing these things
left in the code very long either. If I have #if 0's
in my code, it usually means I haven't decided if the
New Way is the Final Way, and it's usually better just
to make the decision and let the source code control
system keep the history.

-- John.

ON TOPIC !

--- Segher Boessenkool  wrote:
> > There was some discussion on this list on probing
>
> compiler
> > features before actually using them instead of
>
> making vague assumptions
> > on what version supports which feature.
>
> I still prefer just requiring gcc-3 (although it
> currently works "fine"
> with 2.95 as well) (except on some 64-bit targets).
> > Instead of using a vast amount of
>
> autoconf/automake magic, I wrote a
> > small perl script that calls the compiler with
>
> simple code fragments
> > and analyzes these afterwards using nm.
>
> Good :)  The autoevil suite is, well, evil ;)
> > This way it is also
> > usable when cross compiling. Basically the patch
>
> removes types.h
> > as it will be autogenerated plus the already known
>
> ANSI fixes (mostly
> > applying a regexp to change comment style)
>
> 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.
> > The configuration script conf.pl also checks for
>
> available data types
> > and chooses the needed ones to set up the internal
>
> structures.
> > gcc's TI mode is probed and, if available and
>
> needed, it is used.
> > Any comments? ;)
>
> Walkthrough :)  :
>
> -CFLAGS = -Wall -W -std=gnu9x -g -O2 # -pg
> +CFLAGS  = -Wall -std=gnu9x -g -O2 # -pg
>
> Why remove -W ?  It's soooo useful :)
>
> +CC     = gcc
>
> I removed this for a reason ;)   Just   CC=gcc make 
>  if you need it...
>
> +NM     = nm -t bsd
>
> Not all nm's are GNU nm.  Different nm's outputs are
> similar enough to
> be parseable with a simple regexp.
>
> -paflof.o paflof.s: paflof.c prim.code prep.h
> dict.xt
> +paflof.o paflof.s: paflof.c prim.code prep.h
> types.h dict.xt
>
> Ah yes, I forgot.  Thanks.
>
> +$CC="gcc -std=gnu9x";
> +$NM="nm";
>
> Better just use sh's already-set variables for this.
>
> +sub check_size
> +{
>   my $what=shift;
>   my $attr=shift;
>   my $include=shift;
>   # create .test.c file
>   open(F, ">.test.c");
>
> Don't hide temporary files -- if you feel they
> clobber the source dir,
> create them somewhere else (like, /tmp).
>
> +# Check for restrict keyword.
> +my $answer="no";
> +print("\nChecking whether we can use the restrict
> keyword (C99)... ");
> +print(I "\n#define __RESTRICT__ ");
>
> The C compiler already defines __STDC_VERSION__ to
> 199901L or greater if
> C99 features are supported.
>
> -//#define DEBUG_STACKS
>
> Don't remove this, please ;)  #undef it, if you
> want, but keep all compile-time
> flags at the top op file :)
>
> #include <stdio.h>
>  #include <stdlib.h>
> +#define __USE_XOPEN_EXTENDED
>  #include <unistd.h>
> -#include <string.h>
> +#define __USE_MISC
>  #include <sys/mman.h>
> +#include <string.h>
>  #include <termios.h>
> +#define __USE_POSIX
> +#define __USE_POSIX199309
>  #include <signal.h>
>  #include <fcntl.h>
>
> This isn't exactly making stuff more portable, now
> is it?
>
> struct interpreter {
>   cell *restrict data_stack;
>   cell *restrict return_stack;
>   cell *restrict dictionary;
>   char *restrict tib;
>   char *restrict pockets;
>   cell * __RESTRICT__ data_stack;
>   cell * __RESTRICT__ return_stack;
>   cell * __RESTRICT__ dictionary;
>   char * __RESTRICT__ tib;
>   char * __RESTRICT__ pockets;
>   void *here;
>
> };
>
> It would have been simpler had you done
> #define restrict
> if restrict isn't supported...
>
> +#if 0
>   free(i->data_stack);
>   free(i->return_stack);
>   free(i->dictionary);
>
> +#endif
>
> #if 0  for commenting out code is evil, imho.
>
> Well, I'll get to it.
>
> Segher
>
> To unsubscribe: send mail to
> [e-mail]
> with 'unsubscribe openbios' in the body of the
> message
> http://www.freiburg.linux.de/OpenBIOS/ - free your
> system..

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool  [020623 15:47]:
> > There was some discussion on this list on probing compiler
> > features before actually using them instead of making vague assumptions
> > on what version supports which feature.
>
> 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.
> > Instead of using a vast amount of autoconf/automake magic, I wrote a
> > small perl script that calls the compiler with simple code fragments
> > and analyzes these afterwards using nm.
>
> Good :)  The autoevil suite is, well, evil ;)

Just a practical issue - we need perl anyways and it's a lot easier to
read than either the same amount of code in configure.in or 5k lines of
configure script.
> > This way it is also
> > usable when cross compiling. Basically the patch removes types.h
> > as it will be autogenerated plus the already known ANSI fixes (mostly
> > applying a regexp to change comment style)
>
> 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.
> Walkthrough :)  :
>
> -CFLAGS = -Wall -W -std=gnu9x -g -O2 # -pg
> +CFLAGS  = -Wall -std=gnu9x -g -O2 # -pg
>
> Why remove -W ?  It's soooo useful :)

ah.. confused it with -w. sorry.
> +CC     = gcc
>
> I removed this for a reason ;)   Just   CC=gcc make   if you need it...
>
> +NM     = nm -t bsd
>
> Not all nm's are GNU nm.  Different nm's outputs are similar enough to
> be parseable with a simple regexp.

there's 3 output formats with gnu nm - sysv, posix and bsd. To be clean
we have to check which output format is available and use an according 
regexp for that (hoping that other systems use one of these output
formats) For now this should be ok, because, as you said, we're still 
GNU cc specific in many other positions.
> +$CC="gcc -std=gnu9x";
> +$NM="nm";
>
> Better just use sh's already-set variables for this.

this forbids using conf.pl on the command line, as they're set by
make, not sh.
> +# Check for restrict keyword.
> +my $answer="no";
> +print("\nChecking whether we can use the restrict keyword (C99)... ");
> +print(I "\n#define __RESTRICT__ ");
>
> The C compiler already defines __STDC_VERSION__ to 199901L or greater if
> C99 features are supported.

I know. I just thought of a theoretical compiler that knows about
restrict without supporting other C99 features. It seemed wiser to check
for the used features themselfes, not the standards that say "this
feature belongs here"
> -//#define DEBUG_STACKS
>
> Don't remove this, please ;)  #undef it, if you want, but keep all compile-time
> flags at the top op file :)

I just moved it down to the other #defines
> #include <stdio.h>
>  #include <stdlib.h>
> +#define __USE_XOPEN_EXTENDED
>  #include <unistd.h>
> -#include <string.h>
> +#define __USE_MISC
>  #include <sys/mman.h>
> +#include <string.h>
>  #include <termios.h>
> +#define __USE_POSIX
> +#define __USE_POSIX199309
>  #include <signal.h>
>  #include <fcntl.h>
>
> This isn't exactly making stuff more portable, now is it?

It does not hurt it either. It's needed to compile with -ansi -pedantic,
but is changed in the newer release of my patch.
> struct interpreter {
>   cell *restrict data_stack;
>   cell *restrict return_stack;
>   cell *restrict dictionary;
>   char *restrict tib;
>   char *restrict pockets;
>   cell * __RESTRICT__ data_stack;
>   cell * __RESTRICT__ return_stack;
>   cell * __RESTRICT__ dictionary;
>   char * __RESTRICT__ tib;
>   char * __RESTRICT__ pockets;
>   void *here;
>
> };
>
> It would have been simpler had you done
> #define restrict
> if restrict isn't supported...

Uh.. nulling out reserved words... 
well.. i don't really care... we should just solve the case where it's
not existant.
> +#if 0
>   free(i->data_stack);
>   free(i->return_stack);
>   free(i->dictionary);
>
> +#endif
>
> #if 0  for commenting out code is evil, imho.

Better than C++ style comments in pure C code ;) And it's the only way
of doing it "portable" ;) But as John already mentioned, we should
decide whether we want that code or not and drop it completely in the
later case.

Stefan

[Segher Boessenkool]

> > 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.
> > 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.
> > +CC     = gcc
> >
> > I removed this for a reason ;)   Just   CC=gcc make   if you need it...
> >
> > +NM     = nm -t bsd
> >
> > Not all nm's are GNU nm.  Different nm's outputs are similar enough to
> > be parseable with a simple regexp.
>
> there's 3 output formats with gnu nm - sysv, posix and bsd. To be clean
> we have to check which output format is available and use an according
> regexp for that (hoping that other systems use one of these output
> formats) For now this should be ok, because, as you said, we're still
> GNU cc specific in many other positions.
> > +$CC="gcc -std=gnu9x";
> > +$NM="nm";
> >
> > Better just use sh's already-set variables for this.
>
> 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...
> > The C compiler already defines __STDC_VERSION__ to 199901L or greater if
> > C99 features are supported.
>
> I know. I just thought of a theoretical compiler that knows about
> restrict without supporting other C99 features. It seemed wiser to check
> for the used features themselfes, not the standards that say "this
> feature belongs here"

true
> 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 :)
> Better than C++ style comments in pure C code ;) And it's the only way

C99 comments, not C++ comments.  _of course_ anything C++ is much more
evil than #if 0 ;)
> of doing it "portable" ;) But as John already mentioned, we should
> decide whether we want that code or not and drop it completely in the
> later case.

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

cheers,

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool  [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

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

[Stefan Reinauer]

* Segher Boessenkool  [020628 15:29]:
> > 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 :)

Then you should work on making it like that. Nothing against some small
parts that break a rule because it makes sense. But we have to be
careful not to pack too many things together that can be done seperately
without giving you any disadvantages.
Besides, the name is somewhat misleading. OpenBIOS' goal has nothing to
do with Linux, besides Linux is _one_ of the Operating systems we can
boot with it.
> > We should clearly split these two parts
>
> You can't fully separate them (you can only do it artificially, that is).

Still paflof should not contain anything but the prim words and a bare
base dictionary which covers the forth language group and not the other
stuff that can be done a lot better as an extension where it is not
making components more complex than absolutely necessary. If we want 
OpenBIOS to be used in embedded systems we will have to proof certain
runtime behaviour, which is a lot easier if it is clearly defined which
component does which tasks.
> > 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.

Me neither. But OpenBIOS is an Open Source project - If people need it,
they will do it. If paflof is clean and "bug free" we will not even need
a disassembler. One more reason to keep Paflof as small as possible.
> > 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.

I still do not see any need for a fixed types.h - I will make creation
of the types.h conditional in the Makefile. This is a clean solution and
will not hurt. Besides - On an x86 it will always output the same file
as the one you put in cvs, so i do not see any problem here.
> > 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).

still, interpret does not know the stack characteristics of an executed
word.
> Too much checking will slow us down too much (but yes we need a *little*
> more safety brakes).

ack. Though all OF implementations I've been working with had stack
protection. and I consider a dup with nothing on a stack something that 
happens by accident, whereas you only get an xt with open firmware
functions. 0 EXECUTE is something that can almost be considered 
crashing on purpose
> > 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 :)

As soon as there is a way of externally plugging dictionary dumps into
paflof I will look into package handling. (Started some stuff, but
no usable results yet)
> 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).

Yes, there is. It adds complexity to the system where we can cope with
some simple checks and keep the same codebase running on a lot more
systems. For now, this is not the most severe matter though.
> > 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 :)

yes. The only reason it is not there on alpha is someone forgot to do
it.

Stefan

[Segher Boessenkool]

Stefan Reinauer wrote:
> Segher Boessenkool  [020628 15:29]:
> > > 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 :)
>
> Then you should work on making it like that. Nothing against some small
> parts that break a rule because it makes sense. But we have to be
> careful not to pack too many things together that can be done seperately
> without giving you any disadvantages.

I don't understand this paragraph, sorry.  Maybe you can rephrase it?
> Besides, the name is somewhat misleading. OpenBIOS' goal has nothing to
> do with Linux, besides Linux is _one_ of the Operating systems we can
> boot with it.

Paflof != OpenBIOS.  The "Linux" part of the name of Paflof is _not_ misleading,
as Paflof's goal is to provide an OF implementation for all Linux systems.

Of course it's fine to boot other OS'es with it, though :)  ;  it's OF
after all,
so any OS that can boot as an OF client can use it.

But this is where the "you need GCC to build it" constraint comes from,
for example...
> > > We should clearly split these two parts
> >
> > You can't fully separate them (you can only do it artificially, that is).
>
> Still paflof should not contain anything but the prim words and a bare

paflof, the executable, you mean?
> base dictionary which covers the forth language group and not the other
> stuff that can be done a lot better as an extension where it is not
> making components more complex than absolutely necessary. If we want
> OpenBIOS to be used in embedded systems we will have to proof certain
> runtime behaviour, which is a lot easier if it is clearly defined which
> component does which tasks.

The Forth language group _itself_ will be a couple of "extensions", already.
> > I don't think I'll do an assembler _ever_, and the disassembler can surely
> > wait until client program debugging support implementation time.
>
> Me neither. But OpenBIOS is an Open Source project - If people need it,
> they will do it. If paflof is clean and "bug free" we will not even need
> a disassembler. One more reason to keep Paflof as small as possible.

A disassembler is mostly useful for debugging the *client* program (== linux),
not the host (== paflof) itself.
> > > 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).
>
> still, interpret does not know the stack characteristics of an executed
> word.

It doesn't need to.  It only needs to check for stack underflow and overflow,
to prevent *horrible* crashes; it can't actually prevent crashes themselves.
> > Too much checking will slow us down too much (but yes we need a *little*
> > more safety brakes).
>
> ack. Though all OF implementations I've been working with had stack
> protection. and I consider a dup with nothing on a stack something that
> happens by accident, whereas you only get an xt with open firmware
> functions. 0 EXECUTE is something that can almost be considered
> crashing on purpose

0 EXECUTE is exactly the same kind of programming error as a DUP on an empty
stack: someone forgot to check some return value ;)
> > 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).
>
> Yes, there is. It adds complexity to the system where we can cope with
> some simple checks and keep the same codebase running on a lot more
> systems. For now, this is not the most severe matter though.

That's what DEFER words are for, and [IF] ... [THEN] .
> > So I can assume our signals are correct posix signals, and write an actual
> > SEGV handler?  That's great :)
>
> yes. The only reason it is not there on alpha is someone forgot to do
> it.

Great :)

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> I strongly suggest to apply this patch - this would allow a lot
> more people to use paflof and probably get this compiled on
> almost any host system.
> Please comment on the patch. If there is no good reason against
> it, this is definitely the way to go.

Well no.  It will still only compile on compilers that support GCC's
variable macro arg syntax and its computed-goto-to-label support;  the
only compiler that works with all this is GCC (even icc won't work).
Oh, and named record initialization, too (a C99-ism).

If you send a patch that removes these dependencies while not getting
any performance loss (and the restrict's matter a lot, but there's not
enough of them at this exact moment), it'll sure be applied.  But as
long as we require GCC anyway, I prefer using all C99 goodies that ease
my life.

I'll look into the auto-config-types thingie sometime soonish, btw.
Yes I'm slow these days, sorry.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool  [020623 03:05]:
> Well no.  It will still only compile on compilers that support GCC's
> variable macro arg syntax and its computed-goto-to-label support;  the
> only compiler that works with all this is GCC (even icc won't work).
> Oh, and named record initialization, too (a C99-ism).

The later one is probably easy to "fix", computed goto has it's point.
But this can probably be worked around with some #ifdefs as well.
Variable macro arg is a problem. Will we still need this when we are
able to compile the whole thing with itself?
> If you send a patch that removes these dependencies while not getting
> any performance loss (and the restrict's matter a lot, but there's not
> enough of them at this exact moment), it'll sure be applied.  But as
> long as we require GCC anyway, I prefer using all C99 goodies that ease
> my life.

None of my tests showed any change in performance with restrict
(was gcc 3.1.1 though, not HEAD) Still, restrict is changed to a macro
in the latest version of my patch, which is set when the keyword is
available. The same way would be viable for the other C99isms and
GNUisms. This way people have the choice between portability and speed
without having to touch the source. I don't think this will bloat the
source too bad - less than thousand lines are pretty easy to overview.
> I'll look into the auto-config-types thingie sometime soonish, btw.
> Yes I'm slow these days, sorry.

It's getting summer,.. nothing more understandable than that. If you
have any todo/wishes/requirements for this, drop me a note, I will
implement it.

Stefan

[Segher Boessenkool]

Stefan Reinauer wrote:
> Segher Boessenkool  [020623 03:05]:
> > Well no.  It will still only compile on compilers that support GCC's
> > variable macro arg syntax and its computed-goto-to-label support;  the
> > only compiler that works with all this is GCC (even icc won't work).
> > Oh, and named record initialization, too (a C99-ism).
>
> The later one is probably easy to "fix", computed goto has it's point.
> But this can probably be worked around with some #ifdefs as well.
> Variable macro arg is a problem. Will we still need this when we are
> able to compile the whole thing with itself?

We'll still need a bootstrap dictionary, although we can distribute
the more common varieties (correct-endian vs little-endian, 32 or 64 bit)
in binary form.
> > If you send a patch that removes these dependencies while not getting
> > any performance loss (and the restrict's matter a lot, but there's not
> > enough of them at this exact moment), it'll sure be applied.  But as
> > long as we require GCC anyway, I prefer using all C99 goodies that ease
> > my life.
>
> None of my tests showed any change in performance with restrict
> (was gcc 3.1.1 though, not HEAD) Still, restrict is changed to a macro

I got an about 2x speedup (with older versions of the paflof source;
newer source screws up somewhere).
> in the latest version of my patch, which is set when the keyword is
> available. The same way would be viable for the other C99isms and
> GNUisms. This way people have the choice between portability and speed
> without having to touch the source. I don't think this will bloat the
> source too bad - less than thousand lines are pretty easy to overview.

but don't do that ugly

#define __RESTRICT__ restrict

thing; rather, do

#define restrict /**/

or something like that.
> > I'll look into the auto-config-types thingie sometime soonish, btw.
> > Yes I'm slow these days, sorry.
>
> It's getting summer,.. nothing more understandable than that. If you

well i'm just busy, that's all.  although the beach is only a few
minutes of walking from here :)
> have any todo/wishes/requirements for this, drop me a note, I will
> implement it.

can't think of anything right now, sorry...

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool  [020626 07:57]:
> We'll still need a bootstrap dictionary, although we can distribute
> the more common varieties (correct-endian vs little-endian, 32 or 64 bit)
> in binary form.

Does this work when we are not really relocatable? Different platforms
still have different default load addresses and memory maps. If this can
be solved, it is enough to provide 4 base dictionaries in binary form to
support almost all systems.

Stefan

[Segher Boessenkool]

Stefan Reinauer wrote:
> Segher Boessenkool  [020626 07:57]:
> > We'll still need a bootstrap dictionary, although we can distribute
> > the more common varieties (correct-endian vs little-endian, 32 or 64 bit)
> > in binary form.
>
> Does this work when we are not really relocatable?

No idea -- but we *are* really relocatable :)
On-disk dictionaries are not just binary memory dumps :)

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool  [020628 15:32]:
> Stefan Reinauer wrote:
> > Segher Boessenkool  [020626 07:57]:
> > > We'll still need a bootstrap dictionary, although we can distribute
> > > the more common varieties (correct-endian vs little-endian, 32 or 64 bit)
> > > in binary form.
> >
> > Does this work when we are not really relocatable?
>
> No idea -- but we *are* really relocatable :)
> On-disk dictionaries are not just binary memory dumps :)

Ah.. you have that working already? Where can I look at it?

Stefan