On Jun 18, 9:18 pm, JeffM <jef...@email.com> wrote:> ratemonotonic wrote: > >Can any one tell me [their] [bitter?] or sweet experiences > >using GNU toolchain for embedded software development? > > Rate > > Some previous comments on this:http://groups.google.com/group/comp.arch.embedded/browse_frm/thread/8...Thanks a lot ! reading the comments and the links I have a lot more confidence in using GNU tools. FreeRTOS is a great site !
Pros and Cons of GNU toolchain
Started by ●June 18, 2007
Reply by ●June 19, 20072007-06-19
Reply by ●June 19, 20072007-06-19
On Jun 19, 12:40 am, ratemonotonic <niladri1...@gmail.com> wrote:> On Jun 18, 12:56 pm, Ali <abdulra...@gmail.com> wrote: > > > > > On Jun 18, 4:57 pm, ratemonotonic <niladri1...@gmail.com> wrote: > > > > Hi , > > > > I am a relatively new in embedded systems and have so far only used > > > ARM realview tool chian , tool chains for TI DSPs and GNU tool chain. > > > But I have not encountered many problems with either yet ( most > > > probably due to lack of experience :-( ) . > > > Can any one tell me thier better or sweet experiences using GNU > > > toolchain for embedded software development? > > > > Thanks > > > > Rate > > > Anything that comes with : > > a) Hardware support after sale. > > b) Active mailing list. > > d) Good documentation. > > e) Tools that can be replaced with similar tools is a BIG advantage. > > f) Finally, I'd prefer tool chain that comes with less patches;) from > > kernel to libraries. > > > ali > >e) Tools that can be replaced with similar tools is a BIG advantage. > > in your experience is GNU tools easyly replaceble by other commercial > tool ?Well! it depends, if you stick to genuine GNU thing then chances are vital to get replacement of required tools. But if someone want you to buy proprietary software with GNU suit then its different story;) ali
Reply by ●June 19, 20072007-06-19
On Jun 18, 1:15 pm, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:> The only exceptions are when clients use micros that > aren't supported by GCC.In theory you can fix that. Maybe even in practice if you can find a supported one that is not too distant architecturally.
Reply by ●June 19, 20072007-06-19
cs_posting@hotmail.com wrote:> On Jun 18, 1:15 pm, "Michael N. Moran" <mnmo...@bellsouth.net> wrote: > >> The only exceptions are when clients use micros that >> aren't supported by GCC. > > In theory you can fix that.I "could", but I *do* have a life (family, etc ;-) I figure that if the device mfg want their micro to thrive, or the community thinks it should, then it will happen. Although it's been done with some "interesting" architectures, GCC may not be easily portable to some micro-controller architectures. It is *basically* targeted at higher end 32-bit stuff, though there are many exceptions. It also likes single address space RISC like architectures, better than others.> Maybe even in practice if you can find a supported one that is not too > distant architecturally.At 50 years of age, I've learned that I really don't have time to do *everything* myself ;-) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●June 19, 20072007-06-19
"Michael N. Moran" wrote:>... snip ...> > At 50 years of age, I've learned that I really don't > have time to do *everything* myself ;-)You're quick. It took me longer. :-) -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> <http://www.aaxnet.com/editor/edit043.html> cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●June 19, 20072007-06-19
On 2007-06-19, Michael N. Moran <mnmoran@bellsouth.net> wrote:> Although it's been done with some "interesting" architectures, > GCC may not be easily portable to some micro-controller > architectures. It is *basically* targeted at higher end 32-bit > stuff, though there are many exceptions.It seems to port well to CPUs with 16-bit address spaces like the 6812 and the MSP430. It helps that those CPUs handle 16-bit quantities well. If you look at the code gcc generates for something like the AVR, it's a bit more painful.> It also likes single address space RISC like architectures, > better than others.It deals pretty well with CISC architectures like the IA32, 68K, VAX, etc. In fact I think most of the earlier ports were for CISC machines. The RISC ports were more recent.>> Maybe even in practice if you can find a supported one that is not too >> distant architecturally. > > At 50 years of age, I've learned that I really don't > have time to do *everything* myself ;-)Sad but true. -- Grant Edwards grante Yow! Didn't I buy a 1951 at Packard from you last March visi.com in Cairo?
Reply by ●June 20, 20072007-06-20
"CBFalconer" <cbfalconer@yahoo.com> wrote in message news:467849EC.A6F5CB59@yahoo.com...> "Michael N. Moran" wrote: >> > ... snip ... >> >> At 50 years of age, I've learned that I really don't >> have time to do *everything* myself ;-) > > You're quick. It took me longer. :-)Damn! I have just four days to learn *something*. Peter
Reply by ●June 20, 20072007-06-20
Grant Edwards wrote:> On 2007-06-19, Michael N. Moran <mnmoran@bellsouth.net> wrote: > >> Although it's been done with some "interesting" architectures, >> GCC may not be easily portable to some micro-controller >> architectures. It is *basically* targeted at higher end 32-bit >> stuff, though there are many exceptions. > > It seems to port well to CPUs with 16-bit address spaces like > the 6812 and the MSP430. It helps that those CPUs handle > 16-bit quantities well. If you look at the code gcc generates > for something like the AVR, it's a bit more painful. > >> It also likes single address space RISC like architectures, >> better than others. > > It deals pretty well with CISC architectures like the IA32, > 68K, VAX, etc. In fact I think most of the earlier ports were > for CISC machines. The RISC ports were more recent. >One of the key points is that the gcc model works well when you have lots of similar registers. It's not the RISC style cpu that is the particular requirement, but multiple symmetric registers a characteristic commonly associated with RISC. For example, the 68k is a CISC architecture, but it has many RISCy features, such as multiple registers. And the i386 target is an exceptional case for gcc - it is not a natural fit for gcc's models, but generates good code as a result of a huge effort in optimising the compiler for the i386.>>> Maybe even in practice if you can find a supported one that is not too >>> distant architecturally. >> At 50 years of age, I've learned that I really don't >> have time to do *everything* myself ;-) > > Sad but true. >
Reply by ●June 21, 20072007-06-21
On Jun 20, 3:20 pm, David Brown <d...@westcontrol.removethisbit.com> wrote:> Grant Edwards wrote: > > On 2007-06-19, Michael N. Moran <mnmo...@bellsouth.net> wrote: > > >> Although it's been done with some "interesting" architectures, > >> GCC may not be easily portable to some micro-controller > >> architectures. It is *basically* targeted at higher end 32-bit > >> stuff, though there are many exceptions. > > > It seems to port well to CPUs with 16-bit address spaces like > > the 6812 and the MSP430. It helps that those CPUs handle > > 16-bit quantities well. If you look at the code gcc generates > > for something like the AVR, it's a bit more painful. > > >> It also likes single address space RISC like architectures, > >> better than others. > > > It deals pretty well with CISC architectures like the IA32, > > 68K, VAX, etc. In fact I think most of the earlier ports were > > for CISC machines. The RISC ports were more recent. > > One of the key points is that the gcc model works well when you have > lots of similar registers. It's not the RISC style cpu that is the > particular requirement, but multiple symmetric registers a > characteristic commonly associated with RISC. For example, the 68k is a > CISC architecture, but it has many RISCy features, such as multiple > registers. > > And the i386 target is an exceptional case for gcc - it is not a natural > fit for gcc's models, but generates good code as a result of a huge > effort in optimising the compiler for the i386. > > > > >>> Maybe even in practice if you can find a supported one that is not too > >>> distant architecturally. > >> At 50 years of age, I've learned that I really don't > >> have time to do *everything* myself ;-) > > > Sad but true.- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text -David , Could you expand on 'similar registers' I dont understand. Rate
Reply by ●June 21, 20072007-06-21
ratemonotonic wrote:> On Jun 20, 3:20 pm, David Brown <d...@westcontrol.removethisbit.com> > wrote: >> Grant Edwards wrote: >>> On 2007-06-19, Michael N. Moran <mnmo...@bellsouth.net> wrote: >>>> Although it's been done with some "interesting" architectures, >>>> GCC may not be easily portable to some micro-controller >>>> architectures. It is *basically* targeted at higher end 32-bit >>>> stuff, though there are many exceptions. >>> It seems to port well to CPUs with 16-bit address spaces like >>> the 6812 and the MSP430. It helps that those CPUs handle >>> 16-bit quantities well. If you look at the code gcc generates >>> for something like the AVR, it's a bit more painful. >>>> It also likes single address space RISC like architectures, >>>> better than others. >>> It deals pretty well with CISC architectures like the IA32, >>> 68K, VAX, etc. In fact I think most of the earlier ports were >>> for CISC machines. The RISC ports were more recent. >> One of the key points is that the gcc model works well when you have >> lots of similar registers. It's not the RISC style cpu that is the >> particular requirement, but multiple symmetric registers a >> characteristic commonly associated with RISC. For example, the 68k is a >> CISC architecture, but it has many RISCy features, such as multiple >> registers. >> >> And the i386 target is an exceptional case for gcc - it is not a natural >> fit for gcc's models, but generates good code as a result of a huge >> effort in optimising the compiler for the i386. >> >> >> >>>>> Maybe even in practice if you can find a supported one that is not too >>>>> distant architecturally. >>>> At 50 years of age, I've learned that I really don't >>>> have time to do *everything* myself ;-) >>> Sad but true.- Hide quoted text - >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > David , > Could you expand on 'similar registers' I dont understand. > Rate >On the 68k, for example, there are eight data registers D0 .. D7, all of which can be used in exactly the same way at any time. Similarly, address registers A0 .. A6 are identical. ABI and compiler conventions use specific registers for specific purposes, but this is not enforced by the cpu, and the compiler has a free choice. Compare this to a true CISC processor like the i386, whose data registers A, B, C and D have different purposes and different instructions.
