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
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
-- // richard http://www.imagecraft.com
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 visi.com
If so, for what reason you had license the compiler from Green Hills?
Thanks.
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! visi.com
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
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
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 "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
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.
Ivan,
not quite for free but excellent with ease of use and support is the Rowley implementation.
It combines the option to call somebody when you need it and a low price.
Schwob
Ivan A. Kosarev wrote:
compilers? What
optimize
into?
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
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
run
have
See the whole of thread "GNU is slow!" on the LPC2000 yahoo group for an alternative opinion.
In article , Alex Gibson writes
You could also get the same benchmarks from the keil site.... that's where they got them from.
..., or are porting a Linux kernel to your target...
-- 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 ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
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
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
Yes, building the Linux Kernel is biased towards the GCC,and Green Hills still win.
-- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
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
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.
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.