Inexpensive ARM compilers

Hello,

Has anyone an experience of use GNU-based or ImageCraft ARM compilers? What I'm intersted with is how good the compilers are? How good they optimize (say, relatively to others) and what general problems you had run into?

-- Ivan

Reply to
Ivan A. Kosarev
Loading thread data ...

--
// richard
http://www.imagecraft.com
Reply to
Richard M.

I used GCC for years with no problems.

GCC was comparable to the commercial one we had (Green Hills, IIRC).

I found a rather obscure bug in the assembler, but it was fixed within hours of my reporting it.

--
Grant Edwards                   grante             Yow!  I LIKE Aisle 7a.
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

If so, for what reason you had license the compiler from Green Hills?

Thanks.

Reply to
Ivan A. Kosarev

Somebody bought it for a previous project before I arrived and the company. I suggested we use gcc and eCos, since that would allow us to distribute a software development kit for our product. So we did.

--
Grant Edwards                   grante             Yow!  Inside, I'm already
                                  at               SOBBING!
 Click to see the full signature
Reply to
Grant Edwards

My experiences with arm-elf-gcc have been pretty good. The problem I've encountered is with error checking. I had -Wall on to ld and two of my files had a namespace conflict. gcc didn't catch this during compile time and took my a while to debug, running through a disassembler and diff.

Chris

Grant Edwards wrote:

Hills?

already

Reply to
Apparatus

Please provide some details - I've never met such a situation.

Please understand that it's fully legal to have two uninitialized data items with a common external name.

It's not a namespace conflict, but a COMMON variable with maybe silly conflicting data types - legal, but unwise.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

Why is this a problem? Surely ld identified the identifier in question, and a quick use of grep (or cscope) should show up all its occurences. Maybe you are not marking things with strictly file local use as static?

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

I'm not quite sure what you mean by that. ld, the linker, doesn't have a '-Wall' option. Only the compiler driver (gcc) does.

Of course it didn't --- no C or C++ toolchain that has separate compiler and linker can generally do that. Once you have a linker, that automatically means that you can create some kinds of error that only show up at link time. The usual one being "unresolved reference", which happens because the compiler phase cannot possibly know whether or not your linker command line will eventually provide a source to resolve that external object the compiler referenced.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Ivan,

not quite for free but excellent with ease of use and support is the Rowley implementation.

formatting link

It combines the option to call somebody when you need it and a low price.

Schwob

Ivan A. Kosarev wrote:

compilers? What

optimize

into?

Reply to
An Schwob in USA

Have any of you guys seem the Hitex claims on how bad gcc is on arm?

see chapter 2 of the pdf of the book

formatting link

Have to fill out their form to be able to download it.

In the book according to their benchmarks gcc is slower(by an order of magnitude) , less code density , has a larger stack size than IAR , Keil or Arm ADS.

They promote the Keil compiler as the best.

Quote from pg 29

"We can see from this simple analysis that the commercial compilers are streets ahead of the GNU tools in terms of code density and speed of execution. The reasons to use each of the given compilers can be summed up as follows: if you want the fastest code and standard tools use the ARM compiler, for best code density use the Keil, if you have no budget or a simple project use the GNU."

On page 28 All tests were performed under identical conditions using the Keil uVision Simulator. The ARM device used was a Philips LPC-2294 running at 60Mhz in Thumb mode.

Alex

Reply to
Alex Gibson

run

have

See the whole of thread "GNU is slow!" on the LPC2000 yahoo group for an alternative opinion.

formatting link

Reply to
Dave

In article , Alex Gibson writes

You could also get the same benchmarks from the keil site.... that's where they got them from.

formatting link
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

..., or are porting a Linux kernel to your target...

-- Dan Henry

Reply to
Dan Henry

have

Both Metrowerks and Green HIlls are targetting the Linux market with products and can compile the Linux Kernel. I think Green hills claims around 30% code reduction on the kernel vs GCC.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Good to know. Consistent with this thread, my informal comparisons of commercial vs. GCC code generation has the commercial toolchains as the winners. A victim of limited thinking, I had simply "assumed" that using GCC to build the Linux kernel was "just the way it's done" and never questioned whether alternatives are available.

Thanks,

-- Dan Henry

Reply to
Dan Henry

Im sure gcc can lag in performance but these "benchmarks" also have to be biased. I wouldnt put much weight into compiler benchmarks by a competing compiler manufacturer. Any 3rd party benchmarks available?

Terry

Chris Hills wrote:

compilers?

they

had run

Reply to
ktbowman

Yes, building the Linux Kernel is biased towards the GCC,and Green Hills still win.

--
Best Regards
Ulf at atmel dot com
 Click to see the full signature
Reply to
Ulf Samuelsson

In article , snipped-for-privacy@gmail.com writes

why?

The source code for these benchmarks is available. It works with the eval versions of the simulator and AFAIK the compilers. Try it your self.

Like what?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

The Keil benchmarks are hard to believe. If you use a good C standard library, then you find that the GNU compiler isn't at all bad.

Benchmarking on REAL HARDWARE, not a simulator, using Dhrystone as the benchmark as Keil does, CrossWorks for ARM (which uses the GNU compiler as a base) puts in this performance on the Keil MCB2100 board at 60MHz:

Keil MCB2100 (Philips LPC2294/60Mhz) 51,948 Dhrystones/second. and code size is 8,228 bytes.

Keil CA: 39,370 dhrystones/second, 10,330 bytes (slower and bigger than GNU) ARM ADS: 59,382 dhrystones/second, 22,266 bytes (faster but bigger than GNU) IAR: 40,983 dhrystones/second, 19,892 bytes (slower and biger than GNU)

So, the GNU compiler stacks up well against "commercial" compilers when mated with a good C library, doesn't it?

-- Paul.

Reply to
Paul Curtis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.