ARM966E-S

GCC should not be a problem. You can use ARMv5 instructions in GCC and as. Other ARM9 cores should also be OK.

If the chip is on a proprietary board, you have to create a suitable linker script to match the board set-up. The GNU compiler suite is quite flexible in regard to the location of the code. The method here is to use the named ELF sections. For special pieces of code, you can use your own sections in addition to the sections .text, .data, .const and .bss used by the compiler. The linker can also locate any section into one location (RAM) for running and another location (ROM) for loading. This is useful for initialized data (.data).

I suppose that the chip has a memory mapping unit (MMU), which brings an extra complication in assigning addresses, if you're going to use it.

I've been using the GCC tool suite with ARM7TDMI's and some ARM9's without any greater problems. The generated code is good in both ARM and Thumb modes when the compiler is allowed to optimize (I use -Os or -O2).

Hello Tauno,

Thanks for your replay! In fact I never used the GCC before so I'm a little bit lost with all that binaries and the size (2GB), of this Cygwin (I'm in a Windows XP System). I've lost all current day reading documentation and I'm convinced that GCC is a great compiler but not yet confortable with it. Reading your explanation I think there is a lot more documentation I should read tomorrow :)

I have a lot o code that I wrote for a ARM7TDMI using an other comertial compiler but this compiler does not suport that ARM966E-S, so before I spend money with that suport I'm trying to use the GCC, I already see a lot of advantages in using it, just need some more time to be confortable with it.

Thanks for your tip about the ARM5v instruction set, this one I've found in the GCC!

Regards, Gustavo

General comment...

GCC is a very solid compiler, good optimisation. Remember that nearly every linux box out there was compiled with it from the kernel to pretty much every application.

What's it like on small targets? I think the best method, if you are used to the assembler for your target, is try it and look at the output.

My limited observations targeting the AVR 8 bit jobbies is it appears sane and able to take advantage of architecture specific features (might need a hint to help it though).

If you are happy with the code output (and remember that the optimisations are quite unable - "-O0" will turn them off, "-O2" is what most people default to) then you may reasonably assume that it is going to be highly stable (ie not do random crap nor produce random crap).

I have been using GCC routinely on a bunch of ARM's and AVR's for years. When properly used, the code is good eve on small targets, like 1 kibyte of code on an AVR.

I ported an application from Intel 80C188EB to an ARM7TDMI (Atmel AT91M40800). The Intel code was translated with Borland C with Paradigm Locate, and the ARM code was handled with the GNU tools (GCC 2.95/Thumb, and suitable binutils). The ARM code was slightly smaller than the corresponding Intel code. It was still compacted by 15 - 20%, when upgrading the GCC to versions 3.2.1 and later 4.3.3. The code size was about

I've been using it for 10+ years on various microcontrollers (ARM7, ARM9, StrongARM, H8/300, AVR, MSP430). I've been quite happy with it.

Project sizes range from the MSP430 with 8KB of code space and

Over the years I've compared code size with a number of close-source, commercial compilers (IAR, GreenHills, etc.) and there wasn't never much difference -- certainly not enough to justify the horrors of doing development under Windows.

I strongly recommend to install CodeSourcery's GCC

In contrast to other GCC distributions that I came across, "Sourcery G++" has been a reliable tool for ARM targets.

If code quality (size/speed) is really a concern (it normally isn't as much as people think), nothing beats commercial compilers, such as those from ARM.

Best regards