Gnu tools for ARM Cortex development
in [Embedded]
|
Prev: Simulation of ARM7TDMI-S
Next: Which controller to use?
From: Oliver Betz on 21 May 2010 01:58 Chris H wrote: [...] >I agree... however it does not stop benchmarks being done. Most compiler >companies test all the competitors compilers they can get their hands >on. I have seen some of these tests. (I am under NDA's with various >companies and have done compiler testing) They are all better than GCC >equivalents. does this apply to well maintained 32 bit targets as m68k/Coldfire, ARM? General code generation problems or library quality? Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
From: David Brown on 21 May 2010 03:57 On 21/05/2010 07:58, Oliver Betz wrote: > Chris H wrote: > > [...] > >> I agree... however it does not stop benchmarks being done. Most compiler >> companies test all the competitors compilers they can get their hands >> on. I have seen some of these tests. (I am under NDA's with various >> companies and have done compiler testing) They are all better than GCC >> equivalents. > > does this apply to well maintained 32 bit targets as m68k/Coldfire, > ARM? > In my experience, gcc produces very good code for general C (and C++, Ada, Fortran, etc.) for the main 32-bit targets, such as m68k/Coldfire, ARM, MIPS, x86, and PPC as well as the 64-bit targets PPC, MIPS, and amd64. There are some aspects where top-rank commercial compilers will do a better job - their support for "cpu accelerators" such as extra DSP or vector units is often better, especially if there are few chips with these units. In general, the more specialised an add-on is, the less likely it is that gcc will fully support it. Support for that sort of thing takes time and money - commercial tool vendors will often get support from the chip vendors, and they have customers happy to pay money for exactly this sort of thing. With gcc, such features depend more on popularity and on the number of paying customers at commercial gcc developers like Code Sourcery. Hardware vendors may also sponsor such features. On the other hand, more development is done on the front end of gcc than for most other compilers. The front end is shared across all ports, and is thus probably more used than all other compilers put together. So there is a lot in terms of language support and extensions, as well as front and middle end optimisations, in which gcc leads many commercial compilers. One area in which gcc has been poor at compared to commercial compilers is whole-program optimisation (a.k.a. link time optimisation, inter module optimisation, omniscient code generation, etc.). For several versions, gcc has supported this to a limited extent - basically, you compile all your C files at once with a few compiler flags. But you couldn't split the compilation up, you couldn't mix in C++, you couldn't use it on libraries, and it didn't scale well (that's less of a problem with many embedded systems, but limits the scope for development and testing since it is of little use on "big system" software). With gcc 4.5, there is now proper link-time optimisation. It remains to be seen just how good this will be in practice, and it will probably take time to mature, but the potential is huge, and it could lead to many changes to the way C code and modules are organised. > General code generation problems or library quality? > Libraries also vary a lot in quality. There are also balances to be made - libraries aimed for desktop use will put more effort into flexibility and standards compliance (such as full IEEE floating point support), while those aimed at embedded system emphasis size and speed. This is an area where the various commercial gcc vendors differentiate their products. > Oliver
From: Chris H on 21 May 2010 04:43 In message <9O2dndwkDrE9h2vWnZ2dnUVZ8vydnZ2d(a)lyse.net>, David Brown <david.brown(a)hesbynett.removethisbit.no> writes >Chris H wrote: >> In message <4bf529e2$0$2035$8404b019(a)news.wineasy.se>, David Brown >> <david(a)westcontrol.removethisbit.com> writes >>> Another difference between gcc and commercial tools is that commercial >>> tools often have EULAs restricting you from publishing any sort of >>> benchmark information (this is understandable from the supplier's >>> viewpoint). >> I agree... however it does not stop benchmarks being done. Most >>compiler >> companies test all the competitors compilers they can get their hands >> on. I have seen some of these tests. (I am under NDA's with various >> companies and have done compiler testing) They are all better than GCC >> equivalents. >> That is unless you spend a LOT of time (and time == money) improving >>the >> GCC compiler set up. Then it gets better but rarely as good. It is >> essentially a generic compiler system it is not going to get anywhere >> close to the targeted commercial compilers. >> >What I am saying is that you cannot place much trust in a compiler >vendor's benchmark publications. I agree. The published ones are not of any real use. >I am not trying to accuse them of dishonesty or anything (unless you >consider all marketing dishonest) - it's just that it's somewhere >between very hard and impossible to do a good job of such benchmarks, >and there are too many conflicts of interest involved. I agree. And that applies to the non-commercial tools as well. BTW whilst the marketing from some companies is "close to the line" (and some times close on the wrong side :-) Open Source Devotees can be just as bad and often far worse in their claims and arguments. They make religious zealots look sane. >I'm sure that /internally/ vendors take gcc a lot more seriously. Not technically. It is way behind most commercial compilers and for many targets there are no open source or free compilers. One compiler designer I know was complaining last year that all GCC is doing is rearranging the deck chairs on the titanic when it comes to compiler technology. > I'd be very surprised if they don't do close comparisons on all sorts >of generated code using their own tools and gcc, They do.... but not "and gcc". Gcc is just one of many compilers a compiler company will test starting with their main competitors. > and I'm sure there are times when they study the gcc source code for >ideas (they won't copy anything, of course - it would not fit in their >code structure. And it would be illegal). There is no need except for amusement. GCC is a LONG way behind the main commercial compilers. >But that's different from published benchmarks. Internal benchmarks >are a development tool written and used by engineers. Published >benchmarks are a marketing tool for salespeople. Yes and not. All benchmarks are benchmarks. The published ones tend to use well known benchmarks where the source is public. Internal benchmarks use all sorts of code. I know one company who uses several very large projects from customers as well as the sources for their own tools. >I've often heard you say that this sort of benchmark proves that gcc >can't compare to commercial compilers. It does. > But I'm sure you'll agree that a statement like that on its own is >worthless - and your NDAs prevent you giving anything more. Yes to a point. > Even if you are able to provide your customers or potential customers >with more details "off the record", anyone interested in checking the >performance of a compiler has to do the tests themselves. Yes. But who does? Apart from the standard published benchmarks which are very narrow. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: Walter Banks on 21 May 2010 06:38 David Brown wrote: > > I'm sure that /internally/ vendors take gcc a lot more seriously. I'd > be very surprised if they don't do close comparisons on all sorts of > generated code using their own tools and gcc, and I'm sure there are > times when they study the gcc source code for ideas (they won't copy > anything, of course - it would not fit in their code structure. And it > would be illegal). > > But that's different from published benchmarks. Internal benchmarks are > a development tool written and used by engineers. Published benchmarks > are a marketing tool for salespeople. > > I've often heard you say that this sort of benchmark proves that gcc > can't compare to commercial compilers. In my experience that true. The technical issue with gcc is the fundamental design is very old and it tries to support many targets with as much common code as possible. These are primary weaknesses when gcc is competing with commercial compilers designed for a specific target. I don't think that many commercial compiler companies would be looking though gcc source code for ideas anymore. The approaches that commercial compiler developers are using now using is so fundamentally different that gcc would be of little help. Regards, w.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Oliver Betz on 21 May 2010 07:39
David Brown wrote: [...] >In my experience, gcc produces very good code for general C (and C++, >Ada, Fortran, etc.) for the main 32-bit targets, such as m68k/Coldfire, >ARM, MIPS, x86, and PPC as well as the 64-bit targets PPC, MIPS, and amd64. what I have seen in my tests till now looked good, besides a strange re-ordering of instructions making the generated code not faster but unreadable (e.g. in the debugger). And it could be that the re-ordering affects performance when accessing slow Coldfire V2 peripherals (consecutive accesses to peripherals cost more wait states), but I didn't investigate this yet. [...] >One area in which gcc has been poor at compared to commercial compilers >is whole-program optimisation (a.k.a. link time optimisation, inter >module optimisation, omniscient code generation, etc.). For several since this affects mainly code size, this is no problem for me. My applications are small and time critical, so I need only speed. [...] >> General code generation problems or library quality? > >Libraries also vary a lot in quality. There are also balances to be >made - libraries aimed for desktop use will put more effort into >flexibility and standards compliance (such as full IEEE floating point >support), while those aimed at embedded system emphasis size and speed. newlib, uClibc? IMO still bloated for small applications. > This is an area where the various commercial gcc vendors differentiate >their products. At least Codesourcery doesn't tell much about specific advantages of their libraries. And since the libraries have to cover a broad range of applications, it might be necessary to compile them with specific settings - who provides sources? Oliver -- Oliver Betz, Munich despammed.com might be broken, use Reply-To: |