I'm trying to adapt source code and create a makefile accordingly to the
explanation below.
The code used to be compiled with gcc 3.3.1, used at the time with Keil
(just as IDE), and also *.s and *.ld files from Keil.

Currently, I have gcc 4.3.3 compiler and Eclipse IDE, still the same *.s
and *.ld files from Keil and I also had to create a makefile.

The makefile was created accordingly with the previous
compiler/assembler control strings from Keil options screen. Although,
some strings had to be added or changed to match the new compiler
version. The source code was also adapted to match the new compiler
version.

The result is that I can only get "some life signals" with no
optimization level (with gcc 3.3.1 I was using O1), but:
- The memory occupied is almost 50% larger then with gcc 3.3.1
compilation and Keil IDE.
- The program runs something like 4 times slower (related with PLL?)
- Not everything works, such as the LCD.

The uC is the LPC2106 and I'm using Yagarto toolchain.

Any clues?
Thanks in advance!

danr

First of all search for missing volatiles. Most but not all problems
seen when higher optimization levels are enabled are caused by missing
volatiles (in empty loops or when accessing data from ISRs and the
"main-thread").

Maybe the LCD does not work since delay-loops are used which get
"optimized away". Try to add volatile to the loop-counter declaration if
not already there.

Do you used stdio? IRC the Keil 3.3.1 GNU package uses a different libc
and different lowlevel interface than most other GNU packages which
usually use newlib (like Yagarto).

The PLL-configuration should be independent from any optimization
settings.

How are ISRs declared? Do you use the GCC IRQ attribute, nacked
attribute with inline-assembler entry/exit code or an assembler-wrapper
for IRQs?

Regarding 'volatile' read this:
http://www.embedded.com/columns/beginerscorner/9900209

GCC 4.x performs stronger optimisation than 3.x. I would be surprised if
it optimised away a variable access when no optimisation was set. That
said, I would not be surprised if some latent bug or flaw in your code
manifested itself differently when built with a diferent compiler -
you'll just have to debug it, because the problem is most likly with
your code rather then the tool.

Are you using the same CRT start-up code? If not, does the new code set
the PLL up differently?

I have seen vastly differing performance between newlib builds for code
using floating-point. You should avoid using floating-point in any case.

Clifford

Hi,

@mthomas
All the behaviours mentioned above are for no optimization level.
stdio is being used.

ISR attributes are declared like this:

__attribute__ ((interrupt)); 

@clifford
I'm using the same start-up code (*.s) and the same file for memory and
sections definitions (*.ld) as before.


Thanks you both, I've now some topics to explore.

Cheers.