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:
- Segher Boessenkool segher@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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
* Stefan Reinauer stepan@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
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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
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@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 fileopen(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@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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
* Segher Boessenkool segher@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
* Segher Boessenkool segher@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
* Segher Boessenkool segher@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
* Segher Boessenkool segher@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
I am talking about the Forth engine, not the whole implementation of Forth words, as described in the IEEE 1275-1994.
Paflof -- Portable And Flexible Linux Open Firmware
It's not just the Forth engine :)
We should clearly split these two parts
You can't fully separate them (you can only do it artificially, that is).
and have a clear way of predefining dictionaries that are later used with paflof. Forth's strength is factorization, and we should use this design idea through out all the way. The base stuff is done and working. The fact that we don't have an assembler/disassembler or package support etc has nothing to do with paflof itself
I don't think I'll do an assembler _ever_, and the disassembler can surely wait until client program debugging support implementation time.
Please keep types.h intact, and have it include an auto-types.h or something like that. Much easier if you want to bypass the automatic stuff for whatever reason.
It's enough to touch types.h before doing a "make". Another idea would be to give a parameter to conf.pl to create a default config. keeping 2 instances of the same file seems a bit unclean.
touching is not good enough, certainly not when you use CVS. oh, and my system clock tends to reset itself to 1904.
xntpd is your friend ;)
That would work, if enough open 802.11 networks existed :) I'm on the road a lot these days.
But how do you want to include auto-types? We could include the file, and do an #ifndef type_X typedef .... #endif in types.h
I'm not sure anymore :) Figure out a way to do it cleanly, with as little code as possible, and I'm sure we'll agree.
this forbids using conf.pl on the command line, as they're set by make, not sh.
I think that's the lesser of two evils...
make -e solves the other evil ;)
That's a new make flag to me... time to read more docs, I guess.
we should add stack checking to the prim words that need it in the firmware version.
Adding it to INTERPRET should be enough. That, and a "guard area" around the stacks (which we already have; and the guard area generates the MMU trap, currently).
of course one can always crash the forth engine by compiling crap into the dictionary but we capture most of the crashes when we check stack depth before we access the stack.
What about
0 EXECUTE
or anything with unaligned accesses, for example.
We _cannot_ check whether any xt (or other address) is *actually* valid.
Too much checking will slow us down too much (but yes we need a *little* more safety brakes).
Yes, this is quite a bit overhead, but we don't want anything to crap out early when we run from flash.
So write good code for boot drivers :)
Using MMU should not be the way to go as many embedded systems don't have one - and those are among the systems that profit most from an OpenBIOS.
There's no reason to not use the MMU when you have one -- and you *need* to use it, if you run in a host environment (instead of on raw hardware). (In this case, the MMU is actually the OS VM system).
I looked into the kernel code for signal handling on alpha and i386 and the siginfo struct is never filled on alpha, which is simply a mistake in the existing code.
A-ha! Now that explains things ;)
It is easy to fix, but I did not find the time to make a patch yet.
So I can assume our signals are correct posix signals, and write an actual SEGV handler? That's great :)
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
Stefan Reinauer wrote:
- Segher Boessenkool segher@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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
* Segher Boessenkool segher@chello.nl [020628 15:32]:
Stefan Reinauer wrote:
- Segher Boessenkool segher@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
* Segher Boessenkool segher@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
Stefan Reinauer wrote:
- Segher Boessenkool segher@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@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
-
John R. Hogerhuis -
kseegeļ¼ t-online.de -
Segher Boessenkool -
Stefan Reinauer