ARM966E-S

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.