Mail Archives: djgpp/1992/03/14/00:19:38
DJ says:
>PB says:
>>I'm using djgpp verion 1.03. In examining the .S output from a C++
>>code file, I find an enormous number of (to my mind) useless jmps.
>>They jmp over '.align 2,144' statements and even setting optimization
>>on does nothing to get rid of them. Are they in fact optimized by the
>>assembler, in which case I wouldn't know the difference?
>
When I did the optimization, I set -O4, which is what I'm used to on
the Unix boxes at work. I went back and tried -O, which got rid of
the unnecessary jumps.
>The assembler doesn't do optimizations in gcc.
>
What I was getting at was does gcc depend on peephole optimizations
(unnecessary jump elimination) in the assembler level? The -O
solution answered that vague question.
>>I got sidetracked onto this by trying to figure out why my ray tracer
>>was so slow compared to those of people using Borland's C++.
>
>Two things make djgpp faster: longs and pointers (vs shorts and far
>pointers). Floating point isn't faster (same chip) and code speed
>isn't much faster (except for far jumps).
>
One of my original theories was that the method you used to implement
the 387 emulator might lead to *all* floating point operations being
subroutine calls. The assembly listing dispelled that misconception.
(I have the coprocessor and was ready to try cutting out any emulation
code if necessary).
>Using -O (gcc -S -O foo.cc) gets rid of a lot of that kind of stuff.
>I hope 2.0 solves it also; I haven't bothered to check.
>
>1.06 will be out soon, and it will have gcc 2.0 in it.
>
The bottom line is for me to use the correct settings for the older
revisions of gcc/g++. Now, on to making more stuff inline.
>DJ
>dj AT ctron DOT com
>Life is a banana.
Pete
- Raw text -