Gnu tools for ARM Cortex development
in [Embedded]
|
Prev: Simulation of ARM7TDMI-S
Next: Which controller to use?
From: David Brown on 28 May 2010 02:58 On 28/05/2010 00:11, Hans-Bernhard Br�ker wrote: > David Brown wrote: > >> I have never seen a situation where correct C code failed because of >> higher optimisation except when exact timing is needed, > > In that case, it wasn't correct C code to begin with. Relying on exact > timing of any code sequence written in C is a design error. I only partly agree here. Sometimes you /do/ need exact timing in software, and though C is a poor tool for such code, it may still be the best you've got. So I'd say that it's a weak point in the design that needs extra care, but not necessarily an error as it may be better than any practical alternatives.
From: Walter Banks on 28 May 2010 08:50 Hans-Bernhard Br�ker wrote: > > David Brown wrote: > > > I have never seen a situation where correct C code failed because of > > higher optimisation except when exact timing is needed, > > In that case, it wasn't correct C code to begin with. Relying on exact > timing of any code sequence written in C is a design error. Probably more accurately relying on instruction execution timing is a design error. Our automotive customers write engine controller code in C with a requirement that timing events be accurate. This is done using processor based timers rather than relying on execution timing. Reliable event timing can be achieved as a combination of hardware and software. Outputs are preprogrammed to be transferred to a pin on the arrival of an event (a timer for example) and inputs are sampled and held on an event waiting for further processing. This approach has essentially removed timing errors in applications written in either C or asm. None of this is new. The Z8 and COP8 microprocessors used timer events for serial port timing 20 plus years ago. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Hans-Bernhard Bröker on 29 May 2010 12:12 David Brown wrote: > On 28/05/2010 00:11, Hans-Bernhard Br�ker wrote: >> David Brown wrote: >>> I have never seen a situation where correct C code failed because of >>> higher optimisation except when exact timing is needed, >> In that case, it wasn't correct C code to begin with. Relying on exact >> timing of any code sequence written in C is a design error. > I only partly agree here. Sometimes you /do/ need exact timing in > software, and though C is a poor tool for such code, it may still be the > best you've got. Just because it's the best one's got doesn't mean it deserves to be qualified as "correct C code". Code that fulfills its requirements by coincidence as much as by design cannot possibly be correct. Some jobs just can't be done correctly (or done at all) in C. Exact timing is about the most obvious example in that category.
From: Ulf Samuelsson on 1 Jun 2010 18:59 Oliver Betz skrev: > Chris H wrote: > > [...] > >> There is no need except for amusement. GCC is a LONG way behind the main >> commercial compilers. > > which Compiler(s) would you recommend for the Coldfire and CM3? > > Oliver I have been told that the Keil is marginally better than the IAR. This was last summer, so things might have changed. At that time the gcc for CM3 really sucked. Would like to know if gcc has improved. -- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic AB
From: Oliver Betz on 2 Jun 2010 05:24
Ulf Samuelsson wrote: [...] >>> There is no need except for amusement. GCC is a LONG way behind the main >>> commercial compilers. >> >> which Compiler(s) would you recommend for the Coldfire and CM3? >> >> Oliver >I have been told that the Keil is marginally better than the IAR. for the CM3, I assume? >This was last summer, so things might have changed. >At that time the gcc for CM3 really sucked. > >Would like to know if gcc has improved. Can't tell for CM3, and not for Keil or IAR, but I currently test gcc (CodeSourcery) and CodeWarrior for Coldfire. Until now, I found no stupid piece of code. gcc even detected that in |static const unsigned int len[] = {16, 16, 32}; |... |foo = (foo + 1) % len[1]; Buflen[1] is constant and used the appropriate andi (and immediate) instruction, where CodeWarrior used the much slower remu (remainder). Besides this, I found no noticeable differences in code quality, but I hadn't yet the time to test in depth. I already gave up on libraries since I need them really lightweight, e.g. without locale, so I will make my own (don't need many or complicated functions). Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To: |