Developing/compiling software
in [Embedded]
|
From: ChrisQ on 25 Sep 2009 05:53 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 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 used IAR on H8 projects some years ago 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 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 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. Must be out of date on this as well - since when did vanilla gcc provide support for interrupt handlers ?. 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: FreeRTOS info on 25 Sep 2009 08:02 "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. 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. 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. -- Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems
From: David Brown on 25 Sep 2009 08:06 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. 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 - 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. > 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 >
From: Grant Edwards on 25 Sep 2009 10:28 On 2009-09-25, Chris H <chris(a)phaedsys.org> wrote: >>>>> Tell me is Mike Sowada happy with you/visi making these >>>>> accusations about TI? >>>> >>>>I don't think my ISP cares one way or the other about my >>>>opinions on TI's interaction with their customers. Neither >>>>does the post office or the phone company, in case you're >>>>curious about them. >>> >>> So you don't email from your work account either..... >> >>When I'm dealing with customers, vendors, or anything regarding >>products of my employer, I do. > > When officially representing the company > >>For miscellaneous usenet postings containing my personal >>opinions, I don't. > > And neither do the TI employees > > You are complaining they do exactly what you are doing No, I was complaining that when working with customers (specifically people who were working on open-source tools for the MSP430), certain TI employees attempted to hide the fact that they were TI employees. When asked directory whether or not they were TI employees, they declined to answer. -- Grant Edwards grante Yow! Was my SOY LOAF left at out in th'RAIN? It tastes visi.com REAL GOOD!!
From: ChrisQ on 25 Sep 2009 09:50
Grant Edwards wrote: > On 2009-09-25, Chris H <chris(a)phaedsys.org> wrote: > >>>>>> Tell me is Mike Sowada happy with you/visi making these >>>>>> accusations about TI? >>>>> I don't think my ISP cares one way or the other about my >>>>> opinions on TI's interaction with their customers. Neither >>>>> does the post office or the phone company, in case you're >>>>> curious about them. >>>> So you don't email from your work account either..... >>> When I'm dealing with customers, vendors, or anything regarding >>> products of my employer, I do. >> When officially representing the company >> >>> For miscellaneous usenet postings containing my personal >>> opinions, I don't. >> And neither do the TI employees >> >> You are complaining they do exactly what you are doing > > No, I was complaining that when working with customers > (specifically people who were working on open-source tools for > the MSP430), certain TI employees attempted to hide the fact > that they were TI employees. When asked directory whether or > not they were TI employees, they declined to answer. > 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... Regards, Chris |