Paul Taylor wrote:> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: > >> For code size (I assume you mean both Code and Data data usually >> being the critical one ) the only options are Keil and IAR in >> that order. GCC is not in the running. > > oops - I haven't used/looked at the 8051 for years, and just > assumed that gcc was ported to 8051.Remember, this is Chris Hills, operating from his anti-open-source bias position. He might even be accurate here. -- <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
LPC900/80C51 Compiler Toolchain
Started by ●June 20, 2007
Reply by ●June 21, 20072007-06-21
Reply by ●June 22, 20072007-06-22
In article <467B25F7.5AD27C0D@yahoo.com>, CBFalconer <cbfalconer@yahoo.com> writes>Paul Taylor wrote: >> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >> >>> For code size (I assume you mean both Code and Data data usually >>> being the critical one ) the only options are Keil and IAR in >>> that order. GCC is not in the running. >> >> oops - I haven't used/looked at the 8051 for years, and just >> assumed that gcc was ported to 8051. > >Remember, this is Chris Hills, operating from his anti-open-source >bias position. He might even be accurate here.No, I have to work with hard facts not the fanciful notions of the FOSS Devotee Gcc is a general purpose system. It is better suited to the 32 bit systems.. Rather than the 8 bit ones especially the 8051. As has been pointed out GCC uses technology that is about 10-15 years behind the top commercial compilers in the 8-16 bit field. The problem with the 8061 family is the memory map and the DATA space. In this case the internal eXternal DATA space. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●June 22, 20072007-06-22
Chris Hills wrote:> In article <pan.2007.06.21.18.20.07.689574@tiscali.co.uk>, Paul Taylor > <paul_ng_pls_rem@tiscali.co.uk> writes >> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >> >>> For code size (I assume you mean both Code and Data data usually being >>> the critical one ) >> >> yes >> >>> the only options are Keil and IAR in that order. >> >>> GCC is not in the running. >> >> oops - I haven't used/looked at the 8051 for years, and just assumed that >> gcc was ported to 8051. > > As far as I know it is but It would not be a practical answer. >As far as I know, there is no 8051 gcc port. If there was, I'm sure it would be pretty poor for code generation, since gcc (as you said) is aimed more at 32-bit, or at least 16-bit, processors with plenty of registers. 8-bit accumulator based architectures like the 8051 are not a good match. The "standard" open source compiler for the 8051 is SDCC. I've never used the 8051, so I can't really comment on the tools.
Reply by ●June 22, 20072007-06-22
In article <467b95c2$0$1455$8404b019@news.wineasy.se>, David Brown <david@westcontrol.removethisbit.com> writes>Chris Hills wrote: >> In article <pan.2007.06.21.18.20.07.689574@tiscali.co.uk>, Paul >>Taylor <paul_ng_pls_rem@tiscali.co.uk> writes >>> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >>> >>>> For code size (I assume you mean both Code and Data data usually being >>>> the critical one ) >>> >>> yes >>> >>>> the only options are Keil and IAR in that order. >>> >>>> GCC is not in the running. >>> >>> oops - I haven't used/looked at the 8051 for years, and just assumed that >>> gcc was ported to 8051. >> As far as I know it is but It would not be a practical answer. >> > >As far as I know, there is no 8051 gcc port. If there was, I'm sure it >would be pretty poor for code generation, since gcc (as you said) is >aimed more at 32-bit, or at least 16-bit, processors with plenty of >registers. 8-bit accumulator based architectures like the 8051 are not >a good match. > >The "standard" open source compiler for the 8051 is SDCC.Then there is no open source option for the 8051 at the moment. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●June 22, 20072007-06-22
In article <467bad0e$0$1455$8404b019@news.wineasy.se>, David Brown <david@westcontrol.removethisbit.com> writes>Chris Hills wrote: >> In article <467B25F7.5AD27C0D@yahoo.com>, CBFalconer >><cbfalconer@yahoo.com> writes >>> Paul Taylor wrote: >>>> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >>>> >>>>> For code size (I assume you mean both Code and Data data usually >>>>> being the critical one ) the only options are Keil and IAR in >>>>> that order. GCC is not in the running. >>>> >>>> oops - I haven't used/looked at the 8051 for years, and just >>>> assumed that gcc was ported to 8051. >>> >>> Remember, this is Chris Hills, operating from his anti-open-source >>> bias position. He might even be accurate here. >> No, I have to work with hard facts not the fanciful notions of the >>FOSS Devotee >> Gcc is a general purpose system. It is better suited to the 32 bit >>systems.. Rather than the 8 bit ones especially the 8051. >> As has been pointed out GCC uses technology that is about 10-15 >>years behind the top commercial compilers in the 8-16 bit field. >> > >That's apples and oranges. gcc uses some of the latest compiler >technologies, and is way ahead of many (but not all) commercially >available compilers *within its field*.Not at all... not according to the compiler people I know. The most generous comment I heard was that the latest Gcc is at least 5 years behind commercial compilers. They weren't looking at the 8 bit ones either. Others will tell you it is 10 years behind. However they are not going to tell you how they do it for obvious reasons. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●June 22, 20072007-06-22
Chris Hills wrote:> In article <467B25F7.5AD27C0D@yahoo.com>, CBFalconer > <cbfalconer@yahoo.com> writes >> Paul Taylor wrote: >>> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >>> >>>> For code size (I assume you mean both Code and Data data usually >>>> being the critical one ) the only options are Keil and IAR in >>>> that order. GCC is not in the running. >>> >>> oops - I haven't used/looked at the 8051 for years, and just >>> assumed that gcc was ported to 8051. >> >> Remember, this is Chris Hills, operating from his anti-open-source >> bias position. He might even be accurate here. > > No, I have to work with hard facts not the fanciful notions of the FOSS > Devotee > > Gcc is a general purpose system. It is better suited to the 32 bit > systems.. Rather than the 8 bit ones especially the 8051. > > As has been pointed out GCC uses technology that is about 10-15 years > behind the top commercial compilers in the 8-16 bit field. >That's apples and oranges. gcc uses some of the latest compiler technologies, and is way ahead of many (but not all) commercially available compilers *within its field*. There are no gcc ports for the 8051 or similar types of cpu - it is not "behind" or using out-of-date technology, or anything of the kind. In the same way, no one is going to claim ByteCraft's compilers are "out of date" because they don't auto-vectorise loops or re-organise structures to minimise the cost of cache misses - such features are not relevant to targets like the 8051. Perhaps the only target that could be overlapped by compilers specialised for small targets and gcc is the AVR - it is 8-bit, with separate memory spaces, but has multiple registers and a gcc port. It would be fascinating to know how the sorts of techniques used by ByteCraft, IAR, and other commercial embedded compiler specialists compare to those of gcc.> The problem with the 8061 family is the memory map and the DATA space. > In this case the internal eXternal DATA space. >
Reply by ●June 22, 20072007-06-22
Chris Hills wrote:> In article <467bad0e$0$1455$8404b019@news.wineasy.se>, David Brown > <david@westcontrol.removethisbit.com> writes >> Chris Hills wrote: >>> In article <467B25F7.5AD27C0D@yahoo.com>, CBFalconer >>> <cbfalconer@yahoo.com> writes >>>> Paul Taylor wrote: >>>>> On Thu, 21 Jun 2007 18:09:22 +0100, Chris Hills wrote: >>>>> >>>>>> For code size (I assume you mean both Code and Data data usually >>>>>> being the critical one ) the only options are Keil and IAR in >>>>>> that order. GCC is not in the running. >>>>> >>>>> oops - I haven't used/looked at the 8051 for years, and just >>>>> assumed that gcc was ported to 8051. >>>> >>>> Remember, this is Chris Hills, operating from his anti-open-source >>>> bias position. He might even be accurate here. >>> No, I have to work with hard facts not the fanciful notions of the >>> FOSS Devotee >>> Gcc is a general purpose system. It is better suited to the 32 bit >>> systems.. Rather than the 8 bit ones especially the 8051. >>> As has been pointed out GCC uses technology that is about 10-15 >>> years behind the top commercial compilers in the 8-16 bit field. >>> >> >> That's apples and oranges. gcc uses some of the latest compiler >> technologies, and is way ahead of many (but not all) commercially >> available compilers *within its field*. > > Not at all... not according to the compiler people I know. The most > generous comment I heard was that the latest Gcc is at least 5 years > behind commercial compilers. They weren't looking at the 8 bit ones > either. Others will tell you it is 10 years behind. >What do you expect a commercial compiler vendor to tell you - we've got this great expensive compiler, but it is not as advanced as a free and open source one? And where does this mythical time-line come from anyway? There are many compilers available for many targets, and some are stronger than others in certain ways and for certain types of code. If you need to know details, do a benchmark yourself using your own code - anything else is just ramblings.> However they are not going to tell you how they do it for obvious reasons. > >
Reply by ●June 22, 20072007-06-22
Chris Hills wrote:> In article <467bad0e$0$1455$8404b019@news.wineasy.se>, > David Brown <david@westcontrol.removethisbit.com> writes >> Chris Hills wrote: >>> As has been pointed out GCC uses technology that is >>> about 10-15 years behind the top commercial compilers >>> in the 8-16 bit field. >> >> That's apples and oranges. gcc uses some of the latest >> compiler technologies, and is way ahead of many (but >> not all) commercially available compilers *within its >> field*. > > Not at all... not according to the compiler people I > know. The most generous comment I heard was that the > latest Gcc is at least 5 years behind commercial > compilers. They weren't looking at the 8 bit ones either. > Others will tell you it is 10 years behind.FUD alert. Facts please. No hearsay and/or innuendo.> However they are not going to tell you how they do it for > obvious reasons.Perhaps because they would need to admit their claims are baseless or exaggerated? On the other hand, there is a price to be paid for supporting a large number of targets of different types, and vendors that specialize in particular targets (e.g. 8051) will tend to be more optimized in that narrow field. -- 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 22, 20072007-06-22
On Jun 22, 4:14 am, Chris Hills <c...@phaedsys.org> wrote:> Gcc is a general purpose system. It is better suited to the 32 bit > systems.. Rather than the 8 bit ones especially the 8051.I know you meant to say SDCC instead of gcc. But you need to consider that SDCC, although similar to gcc in some respects, was specifically designed to target small devices, hence its name. It also understands the memory architecture of the 8051. gcc has been ported to generate H8 code, hc11, and I probably others. So it does support some 8-bit targets. I agree that it's nor a "good" code generator for 8 bit targets. gcc likes to see a real software stack and no excessive memory paging, which is why it doesn't support 8051, and PIC. But gcc does OK with the PIC24/dsPIC devices because those have a "serious" 16 bit architecture that is quite different from the lowly PIC everyone knows (and loves?).> As has been pointed out GCC uses technology that is about 10-15 years > behind the top commercial compilers in the 8-16 bit field.I'm sure this is true in some cases. But I expect that gcc and SDCC lead ahead of commercial compilers in some cases. Commercial compilers are developed and improved whenever there is a reasonable expectation that paying customers will come forward, or continue to come forward. Sometimes decent commercial compilers are not kept up to date because the customer demand might be "soft" for a particular target family of devices. I'm not against commercial software because I enjoy a pay check as much as anyone else! Open source serves a niche that can't easily be served by commercial software in some cases. Eric
Reply by ●June 22, 20072007-06-22
On Jun 22, 5:50 am, David Brown <d...@westcontrol.removethisbit.com> wrote:> 8-bit accumulator based architectures like the 8051 are not > a good match.The h8 and hc11 also have 8 bit accumulators and they are supported by gcc. It's the blasted memory paging and poor stack that make the 8051 such a difficult device to target. These same limitations are seen in the PIC. Eric
