Mail Archives: djgpp/1997/05/21/17:34:46
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
- Raw text -