Developing/compiling software
in [Embedded]
|
From: Grant Edwards on 25 Sep 2009 12:58 On 2009-09-25, ChrisQ <meru(a)devnull.com> wrote: > Grant Edwards wrote: >> On 2009-09-25, ChrisQ <meru(a)devnull.com> wrote: >> >>> If this is a chess game :-). Is the issue that you should >>> declare conflicts of interest when expressing opinions about >>> proprietary products. No reason to do so otherwise... >> >> I'm not talking about expressing opinions. I'm talking about >> being actively involved in working with/on open-source tools >> and attempting to hide one's affilliation while doing so. >> >> It turned out the maintainer of one of the key libraries that >> was holding back progress in the effort to support JTAG >> debugging was a TI employee who didn't disclose the fact and >> declined to answer when asked directly. >> >> Offers to help with development of the library (even if it >> required signing an NDA) or offerst to beta-test the library >> were ignored. >> >> I can't speak for others involved, but that left a pretty bad >> taste in my mouth. > > Wasn't implying criticism - just my warped sense of humour > found the thread amusing for some reason ~). [...] > I guess you have to accept that some vendors and individuals > are just hard work and learn to live with it or leave it > :-)... Yep. It's a trade-off. When you find a part that fits the requirements much better than the alternatives, but the vendor is difficult to deal with, you pays your money and you makes your choice. And then you complain about it. :) -- Grant Edwards grante Yow! I hope the at ``Eurythmics'' practice visi.com birth control ...
From: Niklas Holsti on 25 Sep 2009 13:06 A small addition to my own posting, sorry for omitting it initially: Niklas Holsti wrote: (I elide most of the context): > However, sometimes the IAR compiler > generates code that adds or subtracts a larger number (> 1) to/from Y, > and then it must use two 8-bit operations, and must disable interrupts > just as gcc does. Some AVR models do provide instructions (ADIW, SBIW) that can atomically add/subtract an immediate number (0..63) to/from the 16-bit Y register. I assume, but haven't checked, that IAR uses these instructions when possible, rather than two 8-bit operations in an interrupt-disabled region. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Ulf Samuelsson on 25 Sep 2009 18:00 ChrisQ skrev: > Ulf Samuelsson wrote: > >> The GNU toolchain can be OK, and it can be horrible. >> If you look at ST's home page you will find some discussion >> about performance of GCC-4.2.1 on the STM32. >> >> The rumoured 90 MIPS becomes: >> >> wait for it... >> >> 32 MIPS... >> >> With a Keil compiler you can reach about 60-65 MIPS at least with >> a 72 MHz Cortex-M3. > > Just how are they measuring these "mips" and can we see some asm code > output evidence Everything else is just supposition ... ?. The MIPS rate is Dhrystone number divided by Dhrystone number on a VAX-11/780. Can't tell how the ST gcc result was measured, but the code I ran, used a timer for measurement. There is a Dhrystone benchmark on : http://www.atmel.com/dyn/resources/prod_documents/softpack-1.6-at91sam3u-ek.zip In the test power consumption project. > > The assembler output is the final arbiter. Optimisation and code > generation can only work with what you give it and depends a lot on the > C constructs and code layout used. That is, you need to understand and > work cooperatively with your compiler to get the best results. Gcc 68k > produces pretty well optimised code as it's been around for a long time. > Have been working with Renesas 80C87 on and off for a couple of years > now. The assembler output would be difficult to improve on. Often half a > dozen lines of C produces about the same number of lines of assembler > output. If there is a major difference, is it perhaps because Cortex is > still fairly new in gcc terms, or is it because there are not enough > people interested enough / have the free time to improve it ?. > >> On the AVR I noted things like pushing ALL registers >> when entering an interrupt. >> The IAR is simply - better - . > > Hardly rational - I think you need to look at a lot more than single > point to decide on "better". I have, that is but one example. If you look at the code generation, there are plenty of things which is done better on the IAR compiler. > I used IAR on H8 projects some years ago And I was discussing the AVR architecture. The IAR compiler will be good for some architectures, and not so good for others. > and found the toolchain, shall we say, a bit eccentric. It worked and > produced good code afaik, but was quite limited in terms of command line > switches, options, utilities etc. That is, there wasn't much added value > in the package and nothing like as good as Microtek's 68k offerings. > It's probably much better now, but compare that with the gnu toolchain, > which is not just gcc and binutils, but a whole raft of other utilities, > all of which work seamlessly with a linux, unix or windows development > environment and cost nothing other than the time to set it up. > > As for registers, many of us came from an assembler background, but the > world has moved on and modern micros have more than enough grunt to get > the job done without worrying about how many registers are being saved. > The whole idea is that you can now afford to write eveything in C With IAR it is easier to write in C, because it is closer to assembler in performance. > without having to examine the entrails to optimise the code. Issues like > no view of the big picture, poor system design and partitioning have > much more impact than any tool efficiency issues, imnsho. Pushing a few > or all registers makes how much ? - a few microseconds difference at > most. Irrelevant in practical terms. If a poor compiler generates signifianct more code, then you might have to add more code, and eventually go to a larger controller. adding cost. > If the architecture is being > pushed so far close to the ragged edge, it suggests that you are trying > to do a "mission impossible" project, or didn't size up requirements > properly in the first place. You might have made a good selection, and then the environment changes forcing you to add more code. Must be out of date on this as well - since > when did vanilla gcc provide support for interrupt handlers ?. WinAVR does. > > If you want a better gcc for your architecture, don't just criticise, > join in and contribute. I'm just gratefull that there is so much good > open source code out there and free to use... > > Regards, > > Chris
From: Ulf Samuelsson on 25 Sep 2009 18:02 FreeRTOS info skrev: > "ChrisQ" <meru(a)devnull.com> wrote in message > news:W91vm.97400$Bg1.35156(a)newsfe25.ams2... >> Ulf Samuelsson wrote: > > <snip> > >>> With a Keil compiler you can reach about 60-65 MIPS at least with >>> a 72 MHz Cortex-M3. >> >> Just how are they measuring these "mips" and can we see some asm code >> output evidence Everything else is just supposition ... ?. > > GCC output is very literal and therefore very slow when optimisation is > turned off - it does ok with higher optimisation. With regard to code > size, by default it does not remove unreferenced code whereas commercial > linkers do. With a few command line options you can get the code size > very close to the commercial guys. 32 MIPS was gcc-4.2.1 with -O3. > > I'm not offering an opinion on the quality of GCC - just pointing out a > few facts. The best thing to do is not believe anything you read and > instead try it out for yourself. > Or ask for other people's experience. > Also, when using an 8051 squeezing out every last instruction can be > important. If it is really that important on your new designs then > basically you chose the wrong CPU (I don't want to start another thread > about supporting legacy systems!). > > >>> On the AVR I noted things like pushing ALL registers >>> when entering an interrupt. >>> The IAR is simply - better - . >> > > GCC and IAR compilers do very different things on the AVR - the biggest > difference being that IAR use two stacks whereas GCC uses one. This > makes IAR more difficult to setup and tune, and GCC slower and clunkier > because it has to disable interrupts for a few instructions on every > function call. Normally this is not a problem, but it is not as elegant > as the two stack solution for sure. GCC is very popular on the AVR > though, and is good enough for most applications, especially used in > combination with the other free AVR tools such as AVRStudio. > Yes, more than 50% of the AVR users, use gcc. BR Ulf Samuelsson
From: Ulf Samuelsson on 25 Sep 2009 18:12
David Brown skrev: > Ulf Samuelsson wrote: >> The GNU toolchain can be OK, and it can be horrible. >> If you look at ST's home page you will find some discussion >> about performance of GCC-4.2.1 on the STM32. >> > > Could you provide a link to this? I could not see any such discussion. > > I note that gcc-4.2.1 was the CodeSourcery release two years ago, when > Thumb-2 support was very new in gcc. And if the gcc-4.2.1 in question > was not from CodeSourcery but based on the official FSF tree, then I > don't think it had Thumb-2 at all. It is very important with gcc to be > precise about the source and versions - particularly so since > CodeSourcery (who maintain the ARM ports amongst others) have > target-specific features long before they become part of the official > FSF tree. > >> The rumoured 90 MIPS becomes: >> >> wait for it... >> >> 32 MIPS... >> >> With a Keil compiler you can reach about 60-65 MIPS at least with >> a 72 MHz Cortex-M3. >> >> Anyone seen improvement in later gcc versions? >> > > I would be very surprised to see any major ARM compiler generating code > at twice the speed of another major ARM compiler, whether we are talking > gcc or commercial compilers. To me, this indicates either something odd > about the benchmark code, something wrong in the use of the tools (such > as compiler flags or libraries), or something wrong in the setup of the > device in question (maybe failing to set clock speeds or wait states > correctly). > > If there was consistently such a big difference, I would not expect > gcc-based development tools to feature so prominently on websites such > as ST's or TI (Luminary Micros) - a compiler as bad as you suggest here > would put the devices themselves in a very bad light. > > I haven't used the ST32 devices, but I am considering TI's Cortex-M3 for > a project, so I interested in the state of development tools for the > same core. > >> ... >> On the AVR I noted things like pushing ALL registers >> when entering an interrupt. > > avr-gcc does /not/ push all registers when entering an interrupt. It > does little for the credibility of your other points when you make such > widely inaccurate claims. In the case I investigated for a customer (which was more than one year ago) the interrupt routines took a lot longer time to execute, and this causes a lot of grievance. > > avr-gcc always pushes three registers in interrupts - SREG, and its > "zero" register and "tmp" register because some code sequences generated > by avr-gcc make assumptions about being able to use these registers. > Theoretically, these could be omitted in some cases, but it turns out to > be a difficult to do in avr-gcc, and the advantages are small (for > non-trivial interrupt functions). No one claims that avr-gcc is > perfect, merely that it is very good. > > Beyond that, avr-gcc pushes registers if they are needed - pretty much > like any other compiler I have used. If your interrupt function calls > an external function, and you are not using whole-program optimisation, > then this means pushing all ABI "volatile" registers - an additional 12 > registers. Again, this is the same as for any other compiler I have > seen. And as with any other compiler, you avoid the overhead by keeping > your interrupt functions small and avoiding external function calls, or > by using whole-program optimisations. > >> The IAR is simply - better - . >> > > I'll not argue with you about IAR producing somewhat smaller or faster > code than avr-gcc. I have only very limited experience with IAR, so I > can't judge properly. But then, you apparently have very little > experience with avr-gcc - I don't disagree with that. I have both, but I quickly scurry back to the IAR compiler if I need to show off the AVR. > few people have really studied and compared > both compilers in a fair and objective test. There is certainly room > for improvement in avr-gcc - there are people working on it, and it gets > better over time. > > But to say "IAR is simply better" is too sweeping a statement to be > taken seriously, since "better" means so many different things to > different people. OK, let me rephrase: It generally outputs smaller and faster code. > >> The gcc compiler can be OK, as shown with the AVR32 gnu compiler. >> > > To go back to your original statement, "The GNU toolchain can be OK, and > it can be horrible", I agree in general - although I'd rate the range a > bit higher (from "very good" down to "pretty bad", perhaps). There have > been gcc ports in the past that could rate as "horrible", but I don't > think that applies to any modern gcc port in serious active use. > >> BR Ulf Samuelsson |