EmbeddedRelated.com
Forums
Memfault State of IoT Report

GCC compiler for ARM7-TDMI

Started by news.inet.tele.dk July 6, 2006
On Sun, 09 Jul 2006 20:22:05 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

[Snipped]
> >My advice is that the best benchmark is the application you're planning >to run. People put far too much emphasis on tiny benchmarks when they >should simply test their existing code. Benchmarks are never going to >be representative, even if you find one that matches the area you are >interested in. Most compilers have free evaluation periods, so you can >try your code on various compilers before deciding which to use.
I agree totally. Another advantage of actually testing one's own code is to see how easy it will be to port as well. Lots of code rely on hidden assumptions, which breaks very quickly under high optimisation levels. If it was an assumption which is true for GCC, then GCC might be the best option even "IF" the comercial compilers are better. The first time I had to port my own code from one compiler to another (exactely the same hardware), I was amazed by how many things broke. Since then I have been MUCH more aware of things one should not assume. Regards Anton Erasmus
In article <mbi7b2p7fas93q91lkgsapg2o0ri1p1nbs@4ax.com>, Anton Erasmus
<nobody@spam.prevent.net> writes
>On Sun, 09 Jul 2006 20:22:05 GMT, "Wilco Dijkstra" ><Wilco_dot_Dijkstra@ntlworld.com> wrote: > >[Snipped] >> >>My advice is that the best benchmark is the application you're planning >>to run. People put far too much emphasis on tiny benchmarks when they >>should simply test their existing code. Benchmarks are never going to >>be representative, even if you find one that matches the area you are >>interested in. Most compilers have free evaluation periods, so you can >>try your code on various compilers before deciding which to use. > >I agree totally. Another advantage of actually testing one's own code >is to see how easy it will be to port as well.
This is why you should use the eval versions of the commercial compilers.
>Lots of code rely on >hidden assumptions, which breaks very quickly under high optimisation >levels.
That depends on the compiler. the more standard the code the less this should happen. Obviously when you get close to the HW all compilers have non standard extensions.
>If it was an assumption which is true for GCC, then GCC might >be the best option even "IF" the comercial compilers are better.
Why? I don't follow this logic?
>The >first time I had to port my own code from one compiler to another >(exactely the same hardware), I was amazed by how many things broke.
What sort of thing? I am curious? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Tue, 11 Jul 2006 17:36:09 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>In article <mbi7b2p7fas93q91lkgsapg2o0ri1p1nbs@4ax.com>, Anton Erasmus ><nobody@spam.prevent.net> writes >>On Sun, 09 Jul 2006 20:22:05 GMT, "Wilco Dijkstra" >><Wilco_dot_Dijkstra@ntlworld.com> wrote: >> >>[Snipped] >>> >>>My advice is that the best benchmark is the application you're planning >>>to run. People put far too much emphasis on tiny benchmarks when they >>>should simply test their existing code. Benchmarks are never going to >>>be representative, even if you find one that matches the area you are >>>interested in. Most compilers have free evaluation periods, so you can >>>try your code on various compilers before deciding which to use. >> >>I agree totally. Another advantage of actually testing one's own code >>is to see how easy it will be to port as well. > >This is why you should use the eval versions of the commercial >compilers.
Of course one should use all the available compilers. This is a good way to test the reasonable priced against the megabucks priced commercial compilers.
> >>Lots of code rely on >>hidden assumptions, which breaks very quickly under high optimisation >>levels. > >That depends on the compiler. the more standard the code the less this >should happen. Obviously when you get close to the HW all compilers >have non standard extensions. > >>If it was an assumption which is true for GCC, then GCC might >>be the best option even "IF" the comercial compilers are better. > >Why? I don't follow this logic?
What do you mean. All commercial compilers are not better than GCC. GCC is being improved at a higher rate than most commercial compilers. Some commercial compilers are currently better - mostly in the libraries they provide. For some projects one need the "best" whatever it is at the moment. For most "good enough" is good enough.
> >>The >>first time I had to port my own code from one compiler to another >>(exactely the same hardware), I was amazed by how many things broke. > >What sort of thing? I am curious?
It has been a while so it is a bit difficult to make a list, but I will try. 1. Comparisons between unsigned and signed integers. 2. Using unions to access bytes inside a long. 3. Assuming structure member alignment would be on boundaries of 32bits on a 32-bit architecture. (This could be fixed with a compiler option) 4. Assuming that all compilers would cast and perform the various operators in the same order in an expression such as long a,d, short b,c; a=d+b+c; (This is a simplified expression and might be a bad example. In the original code the one compiler did the operation between the shorts first, then the cast and then the final operation. The other did the casts first) Most of the errors were the typical type of errors lint would have warned one about. Especially relying on implied casts. Regards Anton Erasmus
Seems like this Green Hills tactic would significantly reduce their
sales. Is there product so good that potential customers are not
concerned about this restriction?

David

www.uCHobby.com
Microcontrollers for Hobbyist

Chris Hills wrote:
> In article <00q*qDglr@news.chiark.greenend.org.uk>, Paul Gotch > <paulg@at-cantab-dot.net> writes > >Dr Justice <sorry@no.spam.wanted> wrote: > >> Yes. Although for some it may not be so quick and easy to collect all the > >> compilers, get their their real-life projects compiled on on the possibly > > > >It's also usually in violation of the license agreements on commerical > >compilers to publish benchmark results. > > > > > Only some of them. Quite a few don't have the restriction. As noted in > the IAR set GreenHills do have that restriction but the others, Keil, > IAR, ARM etc do not. > > > -- > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ > /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <1152680207.460766.23810@s13g2000cwa.googlegroups.com>,
david.fowler@gmail.com writes
>Seems like this Green Hills tactic would significantly reduce their >sales.
It doesn't
>Is there product so good that potential customers are not >concerned about this restriction?
Yes it is. Have you never come across the GHS tools?
> >David > >www.uCHobby.com >Microcontrollers for Hobbyist > >Chris Hills wrote: >> In article <00q*qDglr@news.chiark.greenend.org.uk>, Paul Gotch >> <paulg@at-cantab-dot.net> writes >> >Dr Justice <sorry@no.spam.wanted> wrote: >> >> Yes. Although for some it may not be so quick and easy to collect all the >> >> compilers, get their their real-life projects compiled on on the possibly >> > >> >It's also usually in violation of the license agreements on commerical >> >compilers to publish benchmark results. >> > >> >> >> Only some of them. Quite a few don't have the restriction. As noted in >> the IAR set GreenHills do have that restriction but the others, Keil, >> IAR, ARM etc do not. >> >> >> -- >> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ >> /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ >> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Memfault State of IoT Report