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
  
-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)

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

[Stefan Reinauer]

* Stefan Reinauer <stepan(a)suse.de> [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 

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)

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 majordomo(a)freiburg.linux.de
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 majordomo(a)freiburg.linux.de
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 <segher(a)chello.nl> 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
 majordomo(a)freiburg.linux.de
 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 majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool <segher(a)chello.nl> [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

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

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

[Stefan Reinauer]

* Segher Boessenkool <segher(a)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

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

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

[Stefan Reinauer]

* Segher Boessenkool <segher(a)chello.nl> [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

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

Stefan Reinauer wrote:
  
 * Segher Boessenkool <segher(a)chello.nl> [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 majordomo(a)freiburg.linux.de
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 majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool <segher(a)chello.nl> [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

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

Stefan Reinauer wrote:
  
 * Segher Boessenkool <segher(a)chello.nl> [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 majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool <segher(a)chello.nl> [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


-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

Stefan Reinauer wrote:
  
 * Segher Boessenkool <segher(a)chello.nl> [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 majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Segher Boessenkool <segher(a)chello.nl> [020628 15:32]:
  
 
 Stefan Reinauer wrote:
  
 * Segher Boessenkool <segher(a)chello.nl> [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
-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..