Sender: root AT delorie DOT com Message-ID: <3908A05C.26F9B8B4@inti.gov.ar> Date: Thu, 27 Apr 2000 17:17:33 -0300 From: salvador Organization: INTI X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.38 i686) X-Accept-Language: es-AR, en, es MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: [long] gcc performance and possible bug References: <39046544 DOT ADB90632 AT inti DOT gov DOT ar> <200004271315 DOT JAA03722 AT delorie DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Dieter Buerssner wrote: > > BTW: If you use const *and* compile it as C++ you'll get faster code > >because C++ allows the compiler to use consts as C uses #define macros if > >the compiler considers that's favorable. > > This of course is true. But I think to the special case, it can't make > a difference, because there AFAIK is no MUL im32 instruction. It does, the difference is quite small but is faster ;-) > BTW. I haven't seen this weird behaviour on linux (with the same > compiler and binutils version). Same assembler output? (check dumping the executable). > Is there a switch for gcc, that causes it not to store const data > in the code segment. This might help not only my AMD CPU, but also > other CPUs, as Eli reported a 1:3 speed difference with P166. Well, it seems it will help only when the constant is too close to the function. To the question: don't know. > It may even be desirable to default to such a switch for special > -mcpu or for compiling with -O and without -g. But you'll lose protection. Try writing to a constant in Linux, I just checked and got a Segmentation fault. SET -- Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org set AT ieee DOT org set-soft AT bigfoot DOT com Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013