Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work.
Some comments about results.
It seems that it's better to check for __DJGPP__ instead of __GO32__ (I don't know about DJGPP v1, but we're removing support for it anyway). See patch.
gcc-3.0 20010314 miscompiles src/bgi/text7 with '-O3 -fomit-frame-pointer' . Do we really need to use -O6 -fomit--frame-pointer to build optimized library? How much we're getting from that? Maybe it would be enough to use simply -O2? I sent bug report about this problem to gcc-bugs mailing list.
grx24/makedefs contains definition of default font path (fortunatelly commented out ...) : strcat(getenv("DJDIR"),"/contrib/grx24/fonts") which modifies value returned bu getenv() (but it must not be modified).
Andris
--- grx24/include/grx20.h~1 Sat Mar 10 19:18:50 2001 +++ grx24/include/grx20.h Sat Mar 17 13:55:10 2001 @@ -51,7 +51,7 @@ #endif
#ifdef __GNUC__ -#ifdef __GO32__ +#ifdef __DJGPP__ #define GRX_VERSION GRX_VERSION_GCC_386_GO32 #endif #if defined(__linux__) && defined(__i386__) @@ -1468,7 +1468,7 @@ int kbhit(void); int getch(void); #endif -#ifndef __GO32__ +#ifndef __DJGPP__ int getkey(void); int getxkey(void); #endif --- grx24/src/fdrivers/svga16.c~1 Mon Nov 6 00:42:22 2000 +++ grx24/src/fdrivers/svga16.c Sat Mar 17 13:55:58 2001 @@ -153,7 +153,7 @@ }
-#if !defined(__WATCOMC__) && (defined(__GO32__) || defined(__TURBOC__)) +#if !defined(__WATCOMC__) && (defined(__DJGPP__) || defined(__TURBOC__)) /* The VGA banked frame buffer must start on a 64k boundary ** for this optimized assembler code. ** Linux: mmap may place the frame buffer on a 4k boundary :( --- grx24/src/fdrivers/svga8.c~1 Mon Nov 6 00:43:14 2000 +++ grx24/src/fdrivers/svga8.c Sat Mar 17 13:57:24 2001 @@ -154,7 +154,7 @@ }
-#if !defined(__WATCOMC__) && (defined(__GO32__) || defined(__TURBOC__)) +#if !defined(__WATCOMC__) && (defined(__DJGPP__) || defined(__TURBOC__)) /* The VGA banked frame buffer must start on a 64k boundary ** for this optimized assembler code. ** Linux: mmap may place the frame buffer on a 4k boundary :( --- grx24/src/mouse/input.h~1 Fri Mar 2 20:32:16 2001 +++ grx24/src/mouse/input.h Sat Mar 17 13:52:28 2001 @@ -98,7 +98,7 @@ #define MS_PER_TICK 55 #endif
-#ifdef __GO32__ +#ifdef __DJGPP__ #define user_time(tv) do { \ setup_far_selector(LINP_SEL(0x0000046c)); \ (tv) = peek_l_f(LINP_PTR(0x0000046c)); \ --- grx24/src/mouse/dosinput.c~1 Sat Mar 17 13:59:06 2001 +++ grx24/src/mouse/dosinput.c Sat Mar 17 13:59:24 2001 @@ -22,7 +22,7 @@ #include <conio.h> #endif
-#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif
--- grx24/src/mouse/doskeys.c~1 Mon Nov 6 00:46:22 2000 +++ grx24/src/mouse/doskeys.c Sat Mar 17 13:59:40 2001 @@ -24,7 +24,7 @@ #include "int86.h" #include "memfill.h"
-#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif
--- grx24/src/bgi/palette.c~1 Fri Jan 12 15:38:20 2001 +++ grx24/src/bgi/palette.c Sat Mar 17 14:00:10 2001 @@ -37,7 +37,7 @@
void __gr_setpalette(int colornum, int color) { -#ifdef __GO32__ +#ifdef __DJGPP__ # include <dpmi.h> # include <go32.h> _go32_dpmi_registers regs; --- grx24/test/keys.c~1 Sat Mar 10 18:12:58 2001 +++ grx24/test/keys.c Sat Mar 17 14:00:40 2001 @@ -39,7 +39,7 @@ /* ***************************************************************************/ #endif /* PENTIUM_CLOCK */
-#ifdef __GO32__ +#ifdef __DJGPP__ #include <conio.h> #include <pc.h> #endif --- grx24/test/linetest.c~1 Mon Jan 29 23:47:26 2001 +++ grx24/test/linetest.c Sat Mar 17 14:01:02 2001 @@ -18,7 +18,7 @@ **/
#include "test.h" -#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif
--- grx24/test/modetest.c~1 Sat Mar 10 17:58:42 2001 +++ grx24/test/modetest.c Sat Mar 17 14:01:24 2001 @@ -26,7 +26,7 @@ #include <conio.h> #endif
-#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif
--- grx24/test/speedtst.c~1 Sat Mar 10 17:58:00 2001 +++ grx24/test/speedtst.c Sat Mar 17 14:01:42 2001 @@ -28,7 +28,7 @@ #else #include <values.h> #endif -#ifdef __GO32__ +#ifdef __DJGPP__ #include <conio.h> #include <pc.h> #endif
Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work.
Can you provide the diff for the workaround (or can we expect that gcc will be fixed)?
Some comments about results.
It seems that it's better to check for __DJGPP__ instead of __GO32__ (I don't know about DJGPP v1, but we're removing support for it anyway). See patch.
OK, I will apply the pach (__GO32__ was necessary for DJGPP v1), and I will merge src/makebase.dj and src/makefile.dj2 in next release.
gcc-3.0 20010314 miscompiles src/bgi/text7 with '-O3 -fomit-frame-pointer' . Do we really need to use -O6 -fomit--frame-pointer to build optimized library? How much we're getting from that? Maybe it would be enough to use simply -O2? I sent bug report about this problem to gcc-bugs mailing list.
Really I don't know what -O6 means, the gcc docs don't say nothing about -O6. And note that we are using it in the four plattforms. So I can change it if you think is OK.
grx24/makedefs contains definition of default font path (fortunatelly commented out ...) : strcat(getenv("DJDIR"),"/contrib/grx24/fonts") which modifies value returned bu getenv() (but it must not be modified).
This was a contribution by Maurice Lombardi, but I commented it out because I prefer to set the environment variable (or not set it at all to prove test programs).
Thanks, Andris.
M.Alvarez
On Wed, 21 Mar 2001, Mariano Alvarez Fernandez wrote:
Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work.
Can you provide the diff for the workaround (or can we expect that gcc will be fixed)?
I don't know whether gcc will be fixed.
Workaround was simple: I added prototype for 'static void _outtextxy (... ' and moved definition of this function to the end of source to avoid inlining.
Anyway. If we don't think to release next update soon, we should recheck compiling src/bgi/text7.c. It's easier for me to do it under Linux as I have current CVS version of gcc-3.0 bootstrapped and tested every night (cron task).
Some comments about results.
It seems that it's better to check for __DJGPP__ instead of __GO32__ (I don't know about DJGPP v1, but we're removing support for it anyway). See patch.
OK, I will apply the pach (__GO32__ was necessary for DJGPP v1), and I will merge src/makebase.dj and src/makefile.dj2 in next release.
If we're killing support for DJGPP v1 permenently, then it's Ok. However I cannot be sure that definition of __GO32__ will no reappear before release of gcc-3.0. Anyway __DJGPP__ is better define to check for ... (in case of DJGPP v2)
gcc-3.0 20010314 miscompiles src/bgi/text7 with '-O3 -fomit-frame-pointer' . Do we really need to use -O6 -fomit--frame-pointer to build optimized library? How much we're getting from that? Maybe it would be enough to use simply -O2? I sent bug report about this problem to gcc-bugs mailing list.
Really I don't know what -O6 means, the gcc docs don't say nothing about -O6. And note that we are using it in the four plattforms. So I can change it if you think is OK.
It's from PGCC where optimization levels >3 added somethng new. I have tried PGCC some times but never was satified with results. Perhaps it would be nice to build GRX with current options '-O3 -fomit-frame-pointer' (for gcc -O6 is the same as -O3) and with -O2 and compare results of speedtst in various modes
grx24/makedefs contains definition of default font path (fortunatelly commented out ...) : strcat(getenv("DJDIR"),"/contrib/grx24/fonts") which modifies value returned bu getenv() (but it must not be modified).
I think that it would be better to add install target in makefiles.
For DJGPP it could install libgrx20.a and include files in $DJDIR/lib and $DJDIR/include. Perhaps something like $DJDIR/share/grxfonts would be Ok for fonts.
For Linux we could use similar approach ($prefix/lib. $prefix/include, $prefix/share/grxfonts where prefix could be /usr or /usr/local)
This was a contribution by Maurice Lombardi, but I commented it out because I prefer to set the environment variable (or not set it at all to prove test programs).
Also I think thet we should change a way how more that one library is being built (like libgrx20.a and libgrx20.so.2.4.0 for Linux). One of the ways could be using different extension instead of .o for object files to be put in shared library.
Andris
On Wed, 21 Mar 2001, Mariano Alvarez Fernandez wrote:
Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work.
Can you provide the diff for the workaround (or can we expect that gcc will be fixed)?
Tested with gcc-3.0 20010319 (prerelease) under Linux: the problem is still there. After following patch it works for me. I'm not sure we should apply it now though. With patch we'll get smaller code (_outtextxy() not inlined 4 times) but perhaps some very small performance penalty
It will also go away if we'll change to use -O2 instead of -O3 -fomit-frame-pointer without this patch but as I said it requires benchmarking.
Andris
--- grx24/src/bgi/text7.c~1 Fri Jan 12 15:44:38 2001 +++ grx24/src/bgi/text7.c Wed Mar 21 09:16:24 2001 @@ -24,30 +24,9 @@
#include "text.h"
-/* ----------------------------------------------------------------- */ static void _outtextxy(int *xx, int *yy, int XX, int YY, - int len, const uchar *textstring) -{ - _DO_INIT_CHECK; - __gr_text_init(); -#ifdef GRX_VERSION - if (TXT.font==DEFAULT_FONT) { - if (DefaultFonts[TXT.charsize] == NULL) - DefaultFonts[TXT.charsize] = - GrBuildConvertedFont( - DefaultFonts[1], - GR_FONTCVT_RESIZE, - 8*ZERO2ONE(TXT.charsize), - 8*ZERO2ONE(TXT.charsize), - 0, 0); - __gr_text_bit(DefaultFonts[TXT.charsize],xx,yy,XX,YY,len,(char *) textstring); - } else -#endif - if (BITMAP(TXT.font)) - __gr_text_bit((GrFont *)Fonts[TXT.font],xx,yy,XX,YY,len,(char *) textstring); - else - __gr_text_vec(xx,yy,XX,YY,len,(char *) textstring); -} + int len, const uchar *textstring); +
/* ----------------------------------------------------------------- */ void outtext(const char *textstring) @@ -71,4 +50,29 @@ void __gr_p_outtextxy(int x, int y, __gr_p_GPCstr *txt) { _outtextxy( &x, &y, x+VL, y+VT+PY, txt->len, txt->str); +} + +/* ----------------------------------------------------------------- */ +static void _outtextxy(int *xx, int *yy, int XX, int YY, + int len, const uchar *textstring) +{ + _DO_INIT_CHECK; + __gr_text_init(); +#ifdef GRX_VERSION + if (TXT.font==DEFAULT_FONT) { + if (DefaultFonts[TXT.charsize] == NULL) + DefaultFonts[TXT.charsize] = + GrBuildConvertedFont( + DefaultFonts[1], + GR_FONTCVT_RESIZE, + 8*ZERO2ONE(TXT.charsize), + 8*ZERO2ONE(TXT.charsize), + 0, 0); + __gr_text_bit(DefaultFonts[TXT.charsize],xx,yy,XX,YY,len,(char *) textstring); + } else +#endif + if (BITMAP(TXT.font)) + __gr_text_bit((GrFont *)Fonts[TXT.font],xx,yy,XX,YY,len,(char *) textstring); + else + __gr_text_vec(xx,yy,XX,YY,len,(char *) textstring); }
On 21 Mar 2001, at 19:37, Hartmut Schirmer wrote:
On Tue, 20 Mar 2001, pavenis@lanet.lv wrote:
Do we really need to use -O6 -fomit--frame-pointer to build optimized library?
-O2 or even -Os might be good defaults.
Did the gcc 3.0 branch warn about any multiline stings in asm code ?
I'm not getting related warnings. Maybe they are for gcc HEAD branch only
Andris
-
Andris Pavenis -
Hartmut Schirmer -
Mariano Alvarez Fernandez -
pavenis＠lanet.lv