EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

ARM966E-S

Started by Gustavo Vargas January 28, 2010
Hi all,

Sorry about my newbe question, but I'm lost trying to figure out how
to do that....

I'm expert in ARM7 design but aways using comential IDEs (not so
expert). Now I'm working in a new project using an ARM966E-S core. And
my intention is to use the GCC to generate de code (I never use it
before).

First of all: is it good or should I run from it (gcc)?

Second: in the GCC documentation I can't find the especific ARM966E-S
core, can I generate code for a inferior core and run it in that core?
it works?

Thanks a lot for your help.

Regards,
Gustavo
Gustavo Vargas wrote:
> Hi all, > > Sorry about my newbe question, but I'm lost trying to figure out how > to do that.... > > I'm expert in ARM7 design but aways using comential IDEs (not so > expert). Now I'm working in a new project using an ARM966E-S core. And > my intention is to use the GCC to generate de code (I never use it > before). > > First of all: is it good or should I run from it (gcc)? > > Second: in the GCC documentation I can't find the especific ARM966E-S > core, can I generate code for a inferior core and run it in that core? > it works? > > Thanks a lot for your help. > > Regards, > Gustavo
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). -- Tauno Voipio tauno voipio (at) iki fi
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).

-- 
Tim Watts

Managers, politicians and environmentalists: Nature's carbon buffer.

Tim Watts wrote:
> 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.
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 40 kilobytes. -- Tauno Voipio tauno voipio (at) iki fi
On 2010-01-30, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> Tim Watts wrote: > >> 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. > > 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'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 256 bytes of RAM up to embedded Linux on ARM9 and StrongARM. 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. -- Grant Edwards grante Yow! I feel like a wet at parking meter on Darvon! visi.com
Gustavo Vargas <xgvargas@gmail.com> writes:

> 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 strongly recommend to install CodeSourcery's GCC (http://www.codesourcery.com/sgpp) for ARM. There is a free-as-in-free-beer version available. 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 -- Marcus Harnisch Consultant DOULOS - Developing Design Know-how VHDL * SystemC * Verilog * SystemVerilog * e * PSL * Perl * Tcl/Tk ARM Approved Training Centre (ATC) Doulos Ltd., Central European Office, Garbsener Landstr. 10, 30419 Hannover Tel: +49 (0)511 2771340 mailto: marcus.harnisch@doulos.com Fax: +49 (0)511 2771349 Web: http://www.doulos.com This e-mail and any attachments are confidential and Doulos Ltd. reserves all rights of privilege in respect thereof. It is intended for the use of the addressee only. If you are not the intended recipient please delete it from your system, any use, disclosure, or copying of this document is unauthorised. The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.

The 2024 Embedded Online Conference