From: Andrew Crabtree Message-Id: <199705212132.AA293060344@typhoon.rose.hp.com> Subject: PGCC Update To: djgpp AT delorie DOT com Date: Wed, 21 May 1997 14:32:23 PDT Precedence: bulk Hi Guys - This is to let everybody know that http://www.goof.com/pcg now has a link for the replacement Assembler that corrects the alignment problem (I think). Still waiting to hear from anoybody about specifics of this (if there are any :) I'm also including at the bottom of this message more specific details for rebuilding various packages. It will be a part of the readme.txt for the next snapshot release. Andrew files replaced by this zip, in case things don't work. There is also a separate zip package called new_as.zip that contains a replacement as.exe. This is not related to the PCG in any way. It is simply a rebuild of gas from binutils-2.7 that treats .align differently. For more info see notes below. It appears that if you want to use either -m486 or -mpentiumpro you must replace your as.exe with this one. It may also speed things up a little in general (don't know thought). There are several changes to gcc from 2.7.2. I do not know what all of them are, but I do know of a couple that may affect you. -Wall now includes -Wsign-compare and -Wimplicit. To get pgcc to behave like 2.7.2 you will need to change your CFLAGS to be -Wall -Wno-sign-compare -Wno-implicit. Note that this only affects people who run with -Wall -Werror, and that do signed vs unsigned comparisons or implicit int types. Also, this gcc complains about void main (main should return an int). For all of these cases it is probably best if you fix your code, instead of instructing gcc to stop complaining. Tips for rebuilding common packages - Allegro - Allegro has the sign compare problem. To get allegro to recompile change the makefile so that the optimization level is -O6 (also, get rid of any other options like -m486 if present), and add -Wno-sign-compare after -Wall. Thats it, this one is pretty easy. Libc - This one is a real bitch. Libc itself isn't that bad but some of the other packages that come with it (libm, debuggers) are. Edit \src\gcc.opt to change the optimization level to -O6, and add lines for -Wno-sing-compare and -Wno-implicit at the end of the file. I also found that make would often times crap out on assembly files. I just did a 'rename *.s *.S' and that took care of it for me. This would appear to be a LFN related problem and unzipping or something. I believe it is specific to me setup, but am including it here for completeness. For libm I actually found what appear to be bugs in the assembly source. The 2 ...finite.s files have lines in them like this setnel %al These both need to be changed to setneb %al for it to work. I also had a problem with stuff including math_private.h when my file was math_pri.h (another LFN problem). Renaming math_pri.h to math_private.h worked. Full Screen Debugger - This one is weird. The file fullscr.c just does not want to compile. On optimization -O2 it appears that pgcc outputs 3 bad opcodes (lines 2764,3965,8081 in the .s file). They all look like xorl %al,%al Compiling with -O6 causes the compiler to hang in the redraw function. You can work around this by manually compiling fullscr.c to a .o file like this. gcc -I. -S -O2 fullscr.c Now, edit fullscr.s and change the 3 xorl %al,%al to be xorb instead. Then do gcc -c fullscr.s Mkdoc - This is another strange one. The makefile has an explicit call to ld. If you just run make you will get undefined references from libc.a, in doprint, for symbols like ___moddi3. I have no idea what those are or how they got there (they are not from anything in the .c file or any included .h files. I can only assume gcc puts them in and they should come from libgcc or something). Anyway, I found that changing the rules for mkdoc.exe from ld ... stubify ... To just gcc $^ -O..\..\bin\mkdoc.exe Works around the problem. A lot of the auxiliary packages in here have the optimization flags specified somewhere other than gcc.opt. You will need to poke around and change them if you want. Meschach - Matrix/Vector Math Library This does not compile with -O6. The PCG is aware of the problem. Look for it to be fixed sometime down the road in pgcc. Most files will compile OK with -O6, some need to be set at -O2 for it to work. The Alignment Problem - If anyone can shed some light on this please tell me. Its driving me bonkers. Here is the section on gcc and alignment from the DJGPP FAQ. 14.3 DJGPP programs on a Pentium ================================ **Q*: Does DJGPP support Pentium-specific optimizations?* **Q*: I run the same program on a 486 and on a Pentium, and it's slower on a Pentium!!* *A* : DJGPP doesn't add to, or otherwise change the compiler features offered by GCC. DJGPP is just a port of GCC to MSDOS. Since GCC (as of version 2.7.2.1) doesn't support Pentium-specific optimizations, neither does DJGPP. A program might sometimes run slower on a Pentium due to alignment problems in DJGPP. GCC makes assumptions about how GAS (the assembler) handles alignment, but when GAS is built with the default DJGPP configuration, it treats alignment in a way that's different from what GCC assumes. The outcome of this is that longs are word-aligned, doubles are dword-aligned, etc. Depending on the DJGPP version, link order, library differences, you might get lucky (or unlucky) with a 50/50 chance to get an improper alignment. Different CPUs have different penalties for unaligned accesses, which may explain differences in speed. You might consider adding some slack static variables to induce changes in alignment; if any of the changes suddenly cause a significant change in the runtime performance, then alignment might be the reason. I don't know what exactly this means. I was suggested to me by Marc (from the PCG) that the cause was that some versions of gas treat .align as a number of bytes, and others as leading bits (power of 2 effectively). After some experimentation, I can say that the as.exe that comes with DJGPP seems to be wrong. I also do not understand the sentence from the FAQ about how 'but when GAS is built with the default DJGPP configuration, it treats alignment in a way that's different from what GCC assumes'. I rebuilt as.exe myself with what I believe to be the 'default' configuration for DJGPP and it treats alignment different. So, whats the problem? PGCC uses .align 16 when you specify -m486 or -mpentiumpro. The regular as.exe chokes on this. It could also be, that the regular as.exe misinterprets all of the other .aligns pgcc outputs. I don't know. I'd really like to. Here is a result summary from some tests I ran. as.exe provided in the binary binutils distribution from DJGPP (this is the one every DJGPP user has) It allows .align values from 1 to 15 (all numbers). Odd values such as 3 are allowed. Judging from the error message when you feed it a 16, 15 is the highest number. My as that I built on HPUX from the standard gnu binutils-2.7 source distribution (obtained from /pub/gnu from ftp.digital.com), built according to the unix->djgpp cross-compiler section of the DJGPP FAQ. It allows .align values of 1,2,4,8, and 16. It pukes on values like 3, saying "not a power of 2" The new as.exe for DJGPP that I built using my pgcc hpux->djgpp cross-compiler from the same binutils-2.7 sources above. Configured with --build=hppa1.1-hp.hpux9.05 --target=i386-coff-go32 --host=i386-coff-go32 It allows .align values of 1,2,4,8, and 16. It pukes on values like 3, saying "not a power of 2" So, I am providing the new copy of as.exe. It is not from a patched source base like pgcc. I have not done anything special to configure it (that I know of). It may or may not produce better aligned code then regular as.exe. But, it doesn't complain on .align 16. One thing I know for sure ... pgcc assumes that all the .aligns it outputs will be treated as byte values. I'd love to hear from people about how pgcc is working for them (only good things though :). If you have compiled a semi-standard package, and found that there was a lot of work needed, write it up and I'll include it here. Thats it. Good luck. Andrew