Posted-Date:	Fri, 13 Mar 92 22:23:07 CST
Date:	Fri, 13 Mar 92 22:23:07 CST
From:	bergstro AT src DOT honeywell DOT com (Pete Bergstrom)
To:	dj AT ctron DOT com
Subject:	question re: generated code
Status:	O

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 -