Mariano Alvarez Fernandez a écrit :

pavenis@lanet.lv escribió:

...

gcc-2.95.X assumes definitions of strlen(), memcpy() and some other functions even in absence of prototypes. It's no more so with current development version of gcc-3.0. Patch adds needed includes to avoid some related warnings (I tried to build grx-2.3.4 for X11 under Linux with gcc-3.0 20010301 (prerelease)).

Thanks

...

Problems: gccbgi crashes when I have 32 bpp. It seems to work with 16 bpp. Perhaps I should recheck with gcc-2.95.2

It's not necesary, gccbgi doesn't work with 32 bpp even with 2.3.1, I think is a bgilib problem.

32 bpp works on djgpp v2. But may be you are speaking of the Linux versions ?

Maurice

On Sat, 3 Mar 2001, Mariano Alvarez Fernandez wrote:

Maurice Lombardi escribió:

...

32 bpp works on djgpp v2. But may be you are speaking of the Linux versions ?

Yes, but I don't know about 32bpp on djgpp v2 because modetest doesn't list 32 bpp modes with my Vodoo card.

Nevertheless, if bccbgi works in 32bpp for you, it must be a linux/X11 related problem.

Plain GRX (without BGI functions) mostly works under X11 with 32bpp (I'm have i810 and when I set color depth to 24, I'm getting 32bpp in GRX)

Now about BGI:

- 1st problem is that getmaxcol() should return value that doesn't fit in int. As result I'm getting call to random(0) with following crash. Setting it to something different from 0 from debugger avoid crash. Maybe we should introduce some typedef like typedef unsigned long long maxcolor_t; in libbcc.h for this purpose

- The next problem is that GrColorInfo->black and GrColorInfo->white are both equal to 0x01000000. After setting from debugger GrColorInfo->black to 0 I was finally able to get at least something displayed on the screen. But it seems that we still have much to do.

Andris

On Sat, 03 Mar 2001, Andris Pavenis wrote: [...]

Plain GRX (without BGI functions) mostly works under X11 with 32bpp (I'm have i810 and when I set color depth to 24, I'm getting 32bpp in GRX)

Now about BGI:

• 1st problem is that getmaxcol() should return value that doesn't

fit in int. As result I'm getting call to random(0) with following crash. Setting it to something different from 0 from debugger avoid crash. Maybe we should introduce some typedef like typedef unsigned long long maxcolor_t; in libbcc.h for this purpose

in BGI all colors are integer, we canŽt change this. Look at getmaxcol():

int getmaxcolor(void) { return GrNumColors()-1; }

GrnumColors returns ŽncolorsŽ set up in src/setup/colors.c (note the GrNOCOLOR inits for GrBlack&GrWhite):

void GrResetColors(void) { .... CLRINFO->ncolors = 1L << DRVINFO->actmode.bpp; CLRINFO->black = GrNOCOLOR; CLRINFO->white = GrNOCOLOR; setbits( DRVINFO->actmode.extinfo->cprec, DRVINFO->actmode.extinfo->cpos ); .... }

ncolors should be calculated using the cprec/cpos info so it correctly reports 1<<24 even in 32bpp mode and fails if more than 24bpp required. See below for a patch.

• The next problem is that GrColorInfo->black and GrColorInfo->white are

both equal to 0x01000000. After setting from debugger GrColorInfo->black to 0 I was finally able to get at least something displayed on the screen. But it seems that we still have much to do.

Both have BrNOCOLOR, see GrResetColors() above. You just checked it a little early: /* grx20.h*/ #define GrBlack() ((GrColorInfo->black==GrNOCOLOR)?(GrBlack)():GrColorInfo->black)

/* src/setup/colorbw.c */ GrColor GrBlack(void) { GRX_ENTER(); if(CLRINFO->black == GrNOCOLOR) CLRINFO->black = GrAllocColor(0,0,0); GRX_RETURN(CLRINFO->black); }

The correct value will be set on first call, same for GrWhite().

If any graphics system uses the GrCMODEMASK bits in 32bpp mode GRX will apply the wrong drawing mode, will change colors, ... The GR_frameXWIN32H driver is a candidates to fail. The RAM driver GR_frameRAM32H seems to work around this by shifting the color by 8.

Hope this helps, Hartmut

diff --recursive -c grx234-u1/src/include/libgrx.h grx234/src/include/libgrx.h *** grx234-u1/src/include/libgrx.h Sun Jan 21 02:31:48 2001 --- grx234/src/include/libgrx.h Sun Mar 4 15:47:09 2001 *************** *** 279,284 **** --- 279,285 ---- */ extern int _GR_firstFreeColor; /* can't access all colors on all systems */ extern int _GR_lastFreeColor; /* eg. X11 and other windowing systems */ + int _GrResetColors(void); /* like GrResetColors but return true on success */

#ifdef __TURBOC__ # define C_OPER(color) (unsigned int)(((unsigned char *)(&(color)))[3]) diff --recursive -c grx234-u1/src/setup/colors.c grx234/src/setup/colors.c *** grx234-u1/src/setup/colors.c Tue Jan 16 23:36:22 2001 --- grx234/src/setup/colors.c Sun Mar 4 15:47:09 2001 *************** *** 69,75 **** #else #define _GR_firstFreeColor 0 #endif ! void GrResetColors(void) { # define NSAVED 16 static char infosave[offsetof(struct _GR_colorInfo,ctable[NSAVED])]; --- 69,76 ---- #else #define _GR_firstFreeColor 0 #endif ! ! int _GrResetColors(void) { # define NSAVED 16 static char infosave[offsetof(struct _GR_colorInfo,ctable[NSAVED])]; *************** *** 82,93 **** sttzero(CLRINFO); if(DRVINFO->actmode.extinfo->mode == GR_frameText) { memcpy(CLRINFO,infosave,sizeof(infosave)); ! return; } DACload = DRVINFO->actmode.extinfo->loadcolor; - CLRINFO->ncolors = 1L << DRVINFO->actmode.bpp; CLRINFO->black = GrNOCOLOR; CLRINFO->white = GrNOCOLOR; setbits( DRVINFO->actmode.extinfo->cprec, DRVINFO->actmode.extinfo->cpos --- 83,107 ---- sttzero(CLRINFO); if(DRVINFO->actmode.extinfo->mode == GR_frameText) { memcpy(CLRINFO,infosave,sizeof(infosave)); ! return TRUE; } DACload = DRVINFO->actmode.extinfo->loadcolor; CLRINFO->black = GrNOCOLOR; CLRINFO->white = GrNOCOLOR; + CLRINFO->ncolors = 1L << DRVINFO->actmode.bpp; + if ( (CLRINFO->ncolors&GrCVALUEMASK) != CLRINFO->ncolors ) { + /* can happen on 32bpp systems. Now try to calculate + the minimum number of colors from cprec & cpos info */ + int i, cbpp, c; + cbpp = 0; + for (i=0; i < 3; ++i) { + c = DRVINFO->actmode.extinfo->cprec[i] + + DRVINFO->actmode.extinfo->cpos[i]; + if ( c > cbpp ) + cbpp = c; + } + CLRINFO->ncolors = 1L << cbpp; + } setbits( DRVINFO->actmode.extinfo->cprec, DRVINFO->actmode.extinfo->cpos *************** *** 115,121 **** --- 129,143 ---- CLRINFO->RGBmode = TRUE; break; } + return (CLRINFO->ncolors&GrCVALUEMASK) == CLRINFO->ncolors; + } + + + void GrResetColors(void) + { + _GrResetColors(); } +

void GrSetRGBcolorMode(void) { diff --recursive -c grx234-u1/src/setup/setmode.c grx234/src/setup/setmode.c *** grx234-u1/src/setup/setmode.c Tue Feb 27 00:03:06 2001 --- grx234/src/setup/setmode.c Sun Mar 4 15:47:09 2001 *************** *** 418,424 **** DRVINFO->vposx = 0; DRVINFO->vposy = 0; DBGPRINTF(DBG_SETMD,("GrResetColors ...\n")); ! GrResetColors(); DBGPRINTF(DBG_SETMD,("GrResetColors done\n")); if(fdr.init) { DBGPRINTF(DBG_SETMD,("fdr.init ...\n")); --- 418,427 ---- DRVINFO->vposx = 0; DRVINFO->vposy = 0; DBGPRINTF(DBG_SETMD,("GrResetColors ...\n")); ! if ( !_GrResetColors() ) { ! res = errhdlr("could not set color mode"); ! goto done; ! } DBGPRINTF(DBG_SETMD,("GrResetColors done\n")); if(fdr.init) { DBGPRINTF(DBG_SETMD,("fdr.init ...\n")); diff --recursive -c grx234-u1/src/vdrivers/vd_xwin.c grx234/src/vdrivers/vd_xwin.c *** grx234-u1/src/vdrivers/vd_xwin.c Fri Jan 19 23:13:58 2001 --- grx234/src/vdrivers/vd_xwin.c Sun Mar 4 15:47:09 2001 *************** *** 413,419 **** case 16: grxwinext.mode = GR_frameXWIN16; break; case 24: switch (bpp) { ! case 24: grxwinext.mode = GR_frameXWIN24; break; case 32: grxwinext.mode = (visual->red_mask & 0xff000000) ? GR_frameXWIN32H : GR_frameXWIN32L; break; } --- 413,419 ---- case 16: grxwinext.mode = GR_frameXWIN16; break; case 24: switch (bpp) { ! case 24: grxwinext.mode = GR_frameXWIN24; break; case 32: grxwinext.mode = (visual->red_mask & 0xff000000) ? GR_frameXWIN32H : GR_frameXWIN32L; break; }

On Mon, 5 Mar 2001, Mariano Alvarez Fernandez wrote:

A last change to colors.c. This code:

       int i, cbpp, c;
         cbpp = 0;
         for (i=0; i < 3; ++i) {
             c = DRVINFO->actmode.extinfo->cprec[i]
               + DRVINFO->actmode.extinfo->cpos[i];
             if ( c > cbpp )
                 cbpp = c;
       }

breaks the 32H driver, so I think we must use this (and be confident that GRX drivers now what they are doing):

       int cbpp = 0;
         for (i=0; i < 3; ++i)
             cbpp += DRVINFO->actmode.extinfo->cprec[i];

May be we should have a separate function for this as similar construction is needed also in build_mode_table (bccgrx.c)

unsigned GrModeNumColors (_GR_video_mode * mode) { int cbpp = 0; for (i=0; i<3; i++) cbpp += DRVINFO->actmode.extinfo->cprec[i]; return 1 << cbpp; }

Also I don't think more we should use 1 << DRVINFO->actmode.bpp in _GrResetColors at all as calling such function (GrModeNumColors) is not so large overhead (and it's unlikely to be called in tight loop ...)

Andris

On Fri, 3 Aug 2001, Hartmut Schirmer wrote:

...

On Sun, 4 Mar 2001, Mariano Alvarez Fernandez wrote:

...

Nevertheless the real bug is that: 1L << 32 == 1 !!!!!! This is what breaks bccbgi (and even modetest) in 32 bpp mode.

Yes, strange. Andris, is this a compiler bug or just undefined behaviour ?

If we are treating it as bug, it's an Intel bug. At least on both CPU's I tested this with (Pentium MMX and Pentium III) after following instructions mov $1, %eax movb foo, %cl shl %cl, %eax I'm getting 1 << (foo % 32) in %eax. I looked in old reference of M$ Macro assembler (year 1991, it happened I have it near me) and I saw that this behaviour is documented to be present for all CPUs after 808[68]

What C standard is requesting to be result off foo<<bar if bar is bigger than number of bits in foo?

compiling the following source using gcc -O3 -fomit-grame-pointer (gcc2.7.2.3)

---

extern int si; extern unsigned ui; extern long li; extern unsigned long ul;

void foo(void) { si <<= 32; ui <<= 32; li <<= 32; ul <<= 32; }

void foo2(void) { si = 1; si <<= 32; ui = 1; ui <<= 32; li = 1; li <<= 32; ul = 1; ul <<= 32; }

I would have expected the foo() in both cases. It shouldn´t make any difference if ´ui´ unknown or known to be 1 ... Can yhou please check other GCC versions. I would expect gcc 3.0 to behave at least consistent here.

Below are results I got with gcc-3.0 20010301 (prerelease) configured for i686-pc-linux-gnu

Andris

Reading specs from /disk2/gcctest/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs Configured with: ../gcc/configure --prefix=/disk2/gcctest --enable-shared --verbose --enable-threads=posix : (reconfigured) gcc version 3.0 20010301 (prerelease) /disk2/gcctest/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ shift2.cc -D__GNUG__=3 -D_GNU_SOURCE -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase shift2.cc -O2 -version -o /tmp/cc9iIywe.s GNU CPP version 3.0 20010301 (prerelease) (cpplib) (i386 Linux/ELF) GNU CPP version 3.0 20010301 (prerelease) (cpplib) (i386 Linux/ELF) GNU C++ version 3.0 20010301 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.0 20010301 (prerelease). #include "..." search starts here: #include <...> search starts here: /usr/lib/qt/include . /disk2/gcctest/include/g++-v3 /disk2/gcctest/include/g++-v3/i686-pc-linux-gnu /usr/local/include /disk2/gcctest/lib/gcc-lib/i686-pc-linux-gnu/3.0/include /disk2/gcctest/i686-pc-linux-gnu/include /usr/include End of search list. shift2.cc: In function `void foo()': shift2.cc:8: warning: left shift count >= width of type shift2.cc:9: warning: left shift count >= width of type shift2.cc:10: warning: left shift count >= width of type shift2.cc:11: warning: left shift count >= width of type shift2.cc: In function `void foo2()': shift2.cc:16: warning: left shift count >= width of type shift2.cc:17: warning: left shift count >= width of type shift2.cc:18: warning: left shift count >= width of type shift2.cc:19: warning: left shift count >= width of type as -V -Qy -a -o shift2.o /tmp/cc9iIywe.s GNU assembler version 2.10.91 (i386-slackware-linux) using BFD version 2.10.1.0.4 GAS LISTING /tmp/cc9iIywe.s page 1

1 .file "shift2.cc" 2 .version "01.01" 3 gcc2_compiled.: 4 .text 5 .align 16 6 .globl _Z3foov 7 .type _Z3foov,@function 8 _Z3foov: 9 .LFB1: 10 0000 55 pushl %ebp 11 .LCFI0: 12 0001 31C0 xorl %eax, %eax 13 0003 31C9 xorl %ecx, %ecx 14 0005 A3000000 movl %eax, si 14 00 15 000a 31D2 xorl %edx, %edx 16 000c 89E5 movl %esp, %ebp 17 .LCFI1: 18 000e 890D0000 movl %ecx, ui 18 0000 19 0014 31C0 xorl %eax, %eax 20 0016 89150000 movl %edx, li 20 0000 21 001c A3000000 movl %eax, ul 21 00 22 0021 5D popl %ebp 23 0022 C3 ret 24 .LFE1: 25 .Lfe1: 26 .size _Z3foov,.Lfe1-_Z3foov 27 0023 8DB60000 .align 16 27 00008DBC 27 27000000 27 00 28 .globl _Z4foo2v 29 .type _Z4foo2v,@function 30 _Z4foo2v: 31 .LFB2: 32 0030 55 pushl %ebp 33 .LCFI2: 34 0031 BA010000 movl $1, %edx 34 00 35 0036 B8010000 movl $1, %eax 35 00 36 003b 89150000 movl %edx, si 36 0000 37 0041 B9010000 movl $1, %ecx 37 00 38 0046 89E5 movl %esp, %ebp 39 .LCFI3: 40 0048 A3000000 movl %eax, ui 40 00 41 004d 890D0000 movl %ecx, li 41 0000 42 0053 89150000 movl %edx, ul 42 0000 43 0059 5D popl %ebp GAS LISTING /tmp/cc9iIywe.s page 2

44 005a C3 ret 45 .LFE2: 46 .Lfe2: 47 .size _Z4foo2v,.Lfe2-_Z4foo2v 48 .ident "GCC: (GNU) 3.0 20010301 (prerelease)" GAS LISTING /tmp/cc9iIywe.s page 3

DEFINED SYMBOLS *ABS*:0000000000000000 shift2.cc /tmp/cc9iIywe.s:3 .text:0000000000000000 gcc2_compiled. /tmp/cc9iIywe.s:8 .text:0000000000000000 _Z3foov /tmp/cc9iIywe.s:30 .text:0000000000000030 _Z4foo2v

UNDEFINED SYMBOLS si ui li ul

On Fri, 2 Mar 2001, Maurice Lombardi wrote:

Mariano Alvarez Fernandez a écrit :

...

pavenis@lanet.lv escribió:

...

gcc-2.95.X assumes definitions of strlen(), memcpy() and some other functions even in absence of prototypes. It's no more so with current development version of gcc-3.0. Patch adds needed includes to avoid some related warnings (I tried to build grx-2.3.4 for X11 under Linux with gcc-3.0 20010301 (prerelease)).

Problems: gccbgi crashes when I have 32 bpp. It seems to work with 16 bpp. Perhaps I should recheck with gcc-2.95.2

It's not necesary, gccbgi doesn't work with 32 bpp even with 2.3.1, I think is a bgilib problem.

32 bpp works on djgpp v2. But may be you are speaking of the Linux versions ?

It's so, I tested with gcc-3.0 prerelease under Linux only (XFree86 4.0.2). Anyway I'm getting crash earlier when gcc-3.0 prerelease is being used rather than with gcc-2.95.2 (32bpp mode). So I suspect I have some problem with gcc-3.0 prerelease. Changing to -O2 and removing -fomit-frame-pointer makes binary to crash at the same place where one compiled with gcc-2.95.2

Andris