On 2008-01-12, FreeRTOS.org <noemail@address.com> wrote:>>I can give you a comparison of WINAVR (GCC) vs. IAR on AVR >>platform. With optimization turned on, IAR code was 30% smaller >>than GCC. > > Make sure you are comparing like for like. By default IAR > will remove unreferenced code, while GCC will not,Right. GCC will remove unreachable code, and it can be told to remove unreferences functions and variables at link time, but you have to add a couple command-line flags to enable that feature.> although I'm sure IAR will still be smaller. > > Also the GCC librariesWhat libraries? I'm only aware of one: libgcc.> can get pulled in which make the code size larger.You mean that IAR doesn't have a library of compiler functions to implement operations that the underlying architecture doesn't support directly (e.g. 32 bit multiply on an AVR)? The IAR compiler emits in-line code for _everything_ including floating point operations? -- Grant Edwards grante Yow! Actually, what at I'd like is a little toy visi.com spaceship!!
Buying IAR C
Started by ●January 11, 2008
Reply by ●January 12, 20082008-01-12
Reply by ●January 12, 20082008-01-12
>> can get pulled in which make the code size larger. > > You mean that IAR doesn't have a library of compiler functions > to implement operations that the underlying architecture > doesn't support directly (e.g. 32 bit multiply on an AVR)? The > IAR compiler emits in-line code for _everything_ including > floating point operations?I was really just referring to the GCC implementation of functions such as sprintf(), which are not necessarily optimal for small embedded systems and can suddenly cause your code size to increase if you are not careful. -- Regards, Richard. + http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop 14 official architecture ports, 5000 downloads per month. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems.
Reply by ●January 12, 20082008-01-12
"FreeRTOS.org" <noemail@address.com> wrote in message news:yR6ij.76303$c_1.59139@text.news.blueyonder.co.uk...>>> can get pulled in which make the code size larger. >> >> You mean that IAR doesn't have a library of compiler functions >> to implement operations that the underlying architecture >> doesn't support directly (e.g. 32 bit multiply on an AVR)? The >> IAR compiler emits in-line code for _everything_ including >> floating point operations? > > I was really just referring to the GCC implementation of functions such as sprintf(), which are not necessarily > optimal for small embedded systems and can suddenly cause your code size to increase if you are not careful.Or something basic like 64-bit division or floating point operations where GCC's libraries use a generic implementation rather than one optimised for the target architecture. None of the GCC libraries I tried are suitable for embedded systems, not even newlib. They seem to be made for big systems running Linux, not systems where every byte and cycle counts. Wilco
Reply by ●January 12, 20082008-01-12
> Or something basic like 64-bit division or floating point operations where > GCC's libraries use a generic implementation rather than one optimised > for the target architecture. None of the GCC libraries I tried are > suitable > for embedded systems, not even newlib. They seem to be made for big > systems running Linux, not systems where every byte and cycle counts.Which is why people like Rowley (CrossWorks) provide their own library implementations. [although your point of view is a little stronger than my own, I would hopefully never design a system where I was down to counting every byte and cycle anyway, although I accept in severely cost sensitive apps this might not be feasible] -- Regards, Richard. + http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop 14 official architecture ports, 5000 downloads per month. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems.
Reply by ●January 12, 20082008-01-12
"FreeRTOS.org" <noemail@address.com> wrote in message news:pw8ij.76363$c_1.65735@text.news.blueyonder.co.uk...>> Or something basic like 64-bit division or floating point operations where >> GCC's libraries use a generic implementation rather than one optimised >> for the target architecture. None of the GCC libraries I tried are suitable >> for embedded systems, not even newlib. They seem to be made for big >> systems running Linux, not systems where every byte and cycle counts. > > Which is why people like Rowley (CrossWorks) provide their own library implementations.Indeed. One of the ARM libraries I wrote for GCC is about 6 times as small as the standard one. With that kind of improvement possible it is a no brainer...> [although your point of view is a little stronger than my own, I would hopefully never design a system where I was > down to counting every byte and cycle anyway, although I accept in severely cost sensitive apps this might not be > feasible]It's actually surprising how much money companies are willing to pay for optimizations that make their code a few percent faster/smaller. On multi million units the cost saving of avoiding a larger flash (or faster core) is more than worth it. I often go to great lengths in saving bytes and cycles for customers, including things like compressing the intialization data of the initialized data section to reduce flash footprint... Wilco
Reply by ●January 12, 20082008-01-12
On 2008-01-12, FreeRTOS.org <noemail@address.com> wrote:>>> can get pulled in which make the code size larger. >> >> You mean that IAR doesn't have a library of compiler functions >> to implement operations that the underlying architecture >> doesn't support directly (e.g. 32 bit multiply on an AVR)? The >> IAR compiler emits in-line code for _everything_ including >> floating point operations? > > I was really just referring to the GCC implementation of functions such as > sprintf(),GCC doesn't implement sprintf().> which are not necessarily optimal for small embedded systems and > can suddenly cause your code size to increase if you are not careful.I presume you're talking about glibc, and that's not part of gcc. -- Grant Edwards grante Yow! ... I want a COLOR at T.V. and a VIBRATING BED!!! visi.com
Reply by ●January 12, 20082008-01-12
Grant Edwards wrote:> On 2008-01-12, FreeRTOS.org <noemail@address.com> wrote: > >>> I can give you a comparison of WINAVR (GCC) vs. IAR on AVR >>> platform. With optimization turned on, IAR code was 30% smaller >>> than GCC. >> Make sure you are comparing like for like. By default IAR >> will remove unreferenced code, while GCC will not, > > Right. GCC will remove unreachable code, and it can be told to > remove unreferences functions and variables at link time, but > you have to add a couple command-line flags to enable that > feature. > >> although I'm sure IAR will still be smaller. >> >> Also the GCC libraries > > What libraries? I'm only aware of one: libgcc. >avrlibc is the main library for avr-gcc. It has certainly been the case that some parts of the library were bigger than necessary, although the most recent release has improved things (the floating point code has been re-written, for example).>> can get pulled in which make the code size larger. > > You mean that IAR doesn't have a library of compiler functions > to implement operations that the underlying architecture > doesn't support directly (e.g. 32 bit multiply on an AVR)? The > IAR compiler emits in-line code for _everything_ including > floating point operations? >No, he means that the equivalent functions in the avrlibc libraries are bigger than those in the IAR libraries. In some cases at least, it is true - although there has been substantial improvement recently. How large or small an issue it is will depend very much on the actual routines used.
Reply by ●January 12, 20082008-01-12
On 2008-01-12, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:> > "FreeRTOS.org" <noemail@address.com> wrote in message news:yR6ij.76303$c_1.59139@text.news.blueyonder.co.uk... >>>> can get pulled in which make the code size larger. >>> >>> You mean that IAR doesn't have a library of compiler functions >>> to implement operations that the underlying architecture >>> doesn't support directly (e.g. 32 bit multiply on an AVR)? The >>> IAR compiler emits in-line code for _everything_ including >>> floating point operations? >> >> I was really just referring to the GCC implementation of functions such as sprintf(), which are not necessarily >> optimal for small embedded systems and can suddenly cause your code size to increase if you are not careful. > > Or something basic like 64-bit division or floating point operations where > GCC's libraries use a generic implementation rather than one optimised > for the target architecture. None of the GCC libraries I tried are suitable > for embedded systems, not even newlib.What "gcc libraries" are you talking about? Are we talking about libc implimentations or about compiler code generation?> They seem to be made for big systems running Linux, not > systems where every byte and cycle counts.-- Grant Edwards grante Yow! I've got an IDEA!! at Why don't I STARE at you visi.com so HARD, you forget your SOCIAL SECURITY NUMBER!!
Reply by ●January 12, 20082008-01-12
On 2008-01-12, David Brown <david.brown@hesbynett.removethisbit.no> wrote:>>> Also the GCC libraries >> >> What libraries? I'm only aware of one: libgcc. > > avrlibc is the main library for avr-gcc.Oh. I wasn't aware that avrlibc was part of (or somehow tied to gcc).> It has certainly been the case that some parts of the library > were bigger than necessary, although the most recent release > has improved things (the floating point code has been > re-written, for example).[...]> No, he means that the equivalent functions in the avrlibc libraries are > bigger than those in the IAR libraries. In some cases at least, it is > true - although there has been substantial improvement recently. How > large or small an issue it is will depend very much on the actual > routines used.OK, the thread seems to have morphed from comparing compilers to comparing libc implementations. -- Grant Edwards grante Yow! over in west at Philadelphia a puppy is visi.com vomiting ...
Reply by ●January 12, 20082008-01-12
"Grant Edwards" <grante@visi.com> wrote in message news:13oikqnbaflrhb4@corp.supernews.com...> On 2008-01-12, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote: >> >> "FreeRTOS.org" <noemail@address.com> wrote in message news:yR6ij.76303$c_1.59139@text.news.blueyonder.co.uk... >>>>> can get pulled in which make the code size larger. >>>> >>>> You mean that IAR doesn't have a library of compiler functions >>>> to implement operations that the underlying architecture >>>> doesn't support directly (e.g. 32 bit multiply on an AVR)? The >>>> IAR compiler emits in-line code for _everything_ including >>>> floating point operations? >>> >>> I was really just referring to the GCC implementation of functions such as sprintf(), which are not necessarily >>> optimal for small embedded systems and can suddenly cause your code size to increase if you are not careful. >> >> Or something basic like 64-bit division or floating point operations where >> GCC's libraries use a generic implementation rather than one optimised >> for the target architecture. None of the GCC libraries I tried are suitable >> for embedded systems, not even newlib. > > What "gcc libraries" are you talking about? Are we talking > about libc implimentations or about compiler code generation?I already mentioned Newlib which is one of the GCC libraries (others are glibc, tinylibc, dietlibc etc). The examples I gave are compiler helper functions which are in the main GCC source tree. Wilco
