Forums

LPC900/80C51 Compiler Toolchain

Started by Unknown June 20, 2007
In article <1182535554.002738.258530@c77g2000hse.googlegroups.com>, Eric 
<englere_geo@yahoo.com> writes
>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.
No , I didn't
> 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.
I bet it doesn't do it that well
>> 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.
Absolutely not. As many commercial companies have looked at both they know how far *behind* GCC and SDCC are. Particularly in the case of SDCC for 8051.
> Commercial compilers >are developed and improved whenever there is a reasonable expectation >that paying customers will come forward, or continue to come forward.
Yes. Which includes all the targets you have mentioned so far. Are you suggesting that Gcc and SDC are written for MCU that have no market?
>Sometimes decent commercial compilers are not kept up to date because >the customer demand might be "soft" for a particular target family of >devices.
Usually because the particular MCU has been discontinued.
>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.
Yes but compilers isn't one of those niches -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Fri, 22 Jun 2007 22:24:45 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>>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. > >Yes but compilers isn't one of those niches
Yes it is! It's just that the business model of OSS is totally different. With proprietary tools, you usually purchase the compiler (cheap through expensive) and then pay a relatively low cost for support and annual upgrades. In the the open source world, you get the compiler free, but support is paid for at the going rate. Richard Stallman charges in dollars per minute, according to a page I once browsed. Other models include the software rental model, which one of our most successful clients uses. This model gets continuous development money and permits "small and often" upgrades. Another mode, e.g. the one used by Rowley and others for ARM, is to take the gcc compiler and then to provide added value in terms of IDEs and libraries focussed on embedded systems - not to mention a real installer. There are lots of software business models, and use of OSS in business is just based on one that the conventional commercial toolmakers do not use. Once you realise that all software developers have to earn a living, it's just a question of looking for the business model they use. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads


Chris Hills wrote:

>Eric writes: > >> 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. > >I bet it doesn't do it that well
And you know this...how?
>Absolutely not. As many commercial companies have looked at both they >know how far *behind* GCC and SDCC are. Particularly in the case of >SDCC for 8051.
No offense intended, but you have a long posting history of claiming that Open Source Software is inferior to commercial software, and your website ( http://www.phaedsys.org/ ) appears to be that of a vendor selling commercial software, and thus reading your opinions is a lot like asking a realtor whether this is a good time to buy a house. Do you have any references or examples that support the claim you made above? I am not saying you are wrong; I just want to test the claim myself as best I can. (Disclaimer: I personally have no use for anything called a "Small Device C Compiler for 8051." I program 8051s in Assembly and Forth, as God intended us to do when he gave the 8051 design spec to Moses. I have nothing against those folks who like PDB8 assembly lang... er, I mean C, but I personally prefer Forth and Assembly.)
In article <C6GdnVrx5dK71ODbRVn_vgA@giganews.com>, Guy Macon 
<http@?.guymacon.com/.invalid> writes
>Chris Hills wrote: >>Eric writes: >> >>> 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. >> >>I bet it doesn't do it that well >And you know this...how?
1 I have a copy of it here. 2 benchmarks (which can of course be used to (dis)/prove anything :-) 3 I know what it doesn't do that some of the commercial compilers do.
>>Absolutely not. As many commercial companies have looked at both they >>know how far *behind* GCC and SDCC are. Particularly in the case of >>SDCC for 8051. > >No offense intended, but you have a long posting history of claiming >that Open Source Software is inferior to commercial software, and >your website ( http://www.phaedsys.org/ ) appears to be that of a >vendor selling commercial software, and thus reading your opinions >is a lot like asking a realtor whether this is a good time to buy a >house. Do you have any references or examples that support the >claim you made above? I am not saying you are wrong; I just want >to test the claim myself as best I can.
Yes I sell tools. Therefore my opinion is as good as any user of FOSS who promotes FOSS. Why is it assumed that any person who sells commercial SW is unduly biased but any one who promotes FOSS is not? I have generally found the reverse to be more true. I have to work in Engineering reality . Not some utopian belief. I got cynical early. However as over many years I have discussed in private with many commercial compiler developers, code analysis developers and seen the results of their tests I have been able to form a good picture. Most of what I have seen or been able to examine is under NDA. The problem is the FOSS Sw is just that. Open. So any development is seen by all the commercial tool developers. However the reverse is not true. So anything FOSS has the commercial people also have and therefore FOSS can not be more advanced. At best it can only be equal. On top of that the commercial developers get access to the silicon companies and some sophisticated development tools and test suites. How many GCC or SDCC compilers have been run against Plum-Hall or Perennial? Test suites that are rigorous can cost more recourse to develop than the compiler itself. There are techniques used in the commercial tools that are not used in Gcc or SDCC and the like. To maintain their advantage the commercial tool companies are not going to tell FOSS developers what these are. Though in some cases like DATA overlaying on the 8051 knowing what is done is of little help. There is a lot of effort involved in data overlaying and other forms of optimisation. There is mention above that the SDCC handles the architecture of the 8051... WHICH architecture. There are several. Having worked for an ICE manufacturer I know there are over 40 different cores and I think about 10 different timing models spread over the 600 odd variants. Just compare the variants SDCC supports compared to say the Keil PK51... Incidentally the KEil suite used, under the IDE, 2 different compilers and linkers to support the full range to 8051's Some parts use more than one memory model. I recall the fun when Philips brought out the MX range... an 8051 with 256K contiguous linear memory. (Internal eXternal Data etc) this caused compiler companies a lot of..... opportunities. However they worked directly with, in this case, Philips for many months before the part was launched. Therefore they discuss the mechanisms inside the chip and how they will work in a way the FOSS developers can't. SO add together what the commercial compilers get Full view of the SDCC and or Gcc compilers and how they work Full testing with Industry standard test suites Full co-operation of the silicon vendors. Resource for sophisticated development and test tools Addition all in house techniques A lot of in house knowledge. The FOSS compilers get Nothing. Recently some one challenged Byte craft on one of their claims saying it was not possible. They showed it was possible but did not explain exactly how they did it. The basic books on compiler theory take a lot of reading and understanding. The problem is the commercial tools companies have invested heavily in advancing the science. They just had not published. Only FOSS does that. So any advances FOSS makes the commercial guys get but not vice versa. Then there are the customers. When you deal with the safety critical world you find the customer run their own tests. This also gives a good indication of what compilers can do. However again these are usually under NDA's FOSS Devotees will have to get over it. ALL their stuff is open in a world where no one plays by those rules. It is like playing bridge where there is a team of 3 against 1 and you always have the disclosed hand. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
>
... snip ...
> > There are techniques used in the commercial tools that are not > used in Gcc or SDCC and the like. To maintain their advantage the > commercial tool companies are not going to tell FOSS developers > what these are. Though in some cases like DATA overlaying on the > 8051 knowing what is done is of little help. There is a lot of > effort involved in data overlaying and other forms of optimisation.
That is not so, because most open-source is released under the GPL or an equivalent license. Copying such is outright theft. Using it, and releasing source, is not. ... snip ...
> > Recently some one challenged Byte craft on one of their claims > saying it was not possible. They showed it was possible but did > not explain exactly how they did it. The basic books on compiler > theory take a lot of reading and understanding. The problem is > the commercial tools companies have invested heavily in advancing > the science. They just had not published. Only FOSS does that. > So any advances FOSS makes the commercial guys get but not vice > versa.
I suspect you are referring to my quizzing Andrew on a (mis)statement he made on compiler checking. He cleared that up. It was NOT an explanation of how he did it. Your claim above is a gross distortion. -- <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
In article <467E7B47.CC77491@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Chris Hills wrote: >> >... snip ... >> >> There are techniques used in the commercial tools that are not >> used in Gcc or SDCC and the like. To maintain their advantage the >> commercial tool companies are not going to tell FOSS developers >> what these are. Though in some cases like DATA overlaying on the >> 8051 knowing what is done is of little help. There is a lot of >> effort involved in data overlaying and other forms of optimisation. > >That is not so, because most open-source is released under the GPL >or an equivalent license. Copying such is outright theft. Using >it, and releasing source, is not.
Looking at the source you understand what is it is doing. You can then use the same idea in your own system... I didn't mean you literally copy the source. In any event Sw is not pantentable.
>... snip ... >> >> Recently some one challenged Byte craft on one of their claims >> saying it was not possible. They showed it was possible but did >> not explain exactly how they did it. The basic books on compiler >> theory take a lot of reading and understanding. The problem is >> the commercial tools companies have invested heavily in advancing >> the science. They just had not published. Only FOSS does that. >> So any advances FOSS makes the commercial guys get but not vice >> versa. > >I suspect you are referring to my quizzing Andrew on a >(mis)statement he made on compiler checking. He cleared that up. >It was NOT an explanation of how he did it. Your claim above is a >gross distortion.
Andrew who? OK then can some one PROVE how FOSS compilers are more advanced or *at least* as good as commercial ones? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> > OK then can some one PROVE how FOSS compilers are more advanced or *at > least* as good as commercial ones? >
Wanting to remain an observer of this debate - however I am curious......what is this advancement buying you? Considering the law of diminishing returns, what does last years advancement get me? If its an extra micro seconds per control loop, and this is important to me, then I chose the wrong processor - not the wrong compiler. -- Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 certified real time kernel for safety related systems.
Chris Hills wrote:

> In any event Sw is not pantentable.
You should tell the USPTO that. And the EPO, too, while at it. And the hundreds of developers who found themselves threatened with lawsuits over the LZW patent, too. Software is explicitly declared non-patentable in the documents establishing the European Patent Office. Yet the GIF patent prevailed.
> OK then can some one PROVE how FOSS compilers are more advanced or *at > least* as good as commercial ones?
Not unless we all agree on a quantifiable measur of "advanced" or "good" first. Which, of course, is the core of the problem. Proprietary tools cause certain risks to their users, primarily by tying your project's long-term survival to that of the tool vendor, possibly extending to a hostage-taking kind of situation. This is a risk that, once expressed as a finanial risk factor, may forbid using the tool. It's practically impossible for GCC to ever stop working. Proprietary compilers can do that, some did, and some will do it in the future.
In article <NwAfi.11116$p8.10051@text.news.blueyonder.co.uk>, 
FreeRTOS.org <noemail@address.com> writes
>> >> OK then can some one PROVE how FOSS compilers are more advanced or *at >> least* as good as commercial ones? >> > >Wanting to remain an observer of this debate - however I am >curious......what is this advancement buying you? Considering the law of >diminishing returns, what does last years advancement get me? If its an >extra micro seconds per control loop, and this is important to me, then I >chose the wrong processor - not the wrong compiler.
Yes much better compression and execution speed. I have seen several programs that the Keil 2/4/8k limited compilers could get to run on a 51 that the unlimited SDCC could not. The problem is when they want to add "just one more feature" without changing the whole design. For example... smart cards and mobile SIMS and many other things. Especially when by law you need to add something to an old system or to change some IO because they are new sensors. Ideally you would scrap the whole system and start again to ad a small change to an end of life product. The other problem is that there are new extended 8051 family members. The ones with 8Mg adress space in both code and data areas. Internal (on chip) External data space. And all sorts of things in the new parts that the better commercial compilers will cope with the the FOSS ones don't I do find it strange that people are arguing so strongly for using second rate tools in their profession. What would you think of a doctor, dentist, aeronautical engineer who argued the same? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <f5mlqf$o0f$02$1@news.t-online.com>, Hans-Bernhard Br&#2013266166;ker 
<HBBroeker@t-online.de> writes
>Chris Hills wrote: > >> In any event Sw is not pantentable. > >You should tell the USPTO that. And the EPO, too, while at it. And >the hundreds of developers who found themselves threatened with >lawsuits over the LZW patent, too. > >Software is explicitly declared non-patentable in the documents >establishing the European Patent Office.
Yes. There are no patents for software.
> Yet the GIF patent prevailed.
That was not the law that prevailed but commerce. It is not likely to have the same effecting a year or two.
>> OK then can some one PROVE how FOSS compilers are more advanced or >>*at least* as good as commercial ones? > >Not unless we all agree on a quantifiable measur of "advanced" or >"good" first. Which, of course, is the core of the problem. > >Proprietary tools cause certain risks to their users, primarily by >tying your project's long-term survival to that of the tool vendor,
Not seen that happen so far. SO far there always seems to be a way around that.
> possibly extending to a hostage-taking kind of situation.
Not seen that happen do you have a case of that? Or is this just making up FUD like everyone is saying MS are doing. Also that can happen with FOSS too... Several FOSS companies are starting to sound more like MS than MS do over trade marks and their IP.
> This is a risk that, once expressed as a finanial risk factor, may >forbid using the tool.
We you make up the scenarios... I can make up equally ludicrous ones
>It's practically impossible for GCC to ever stop working. Proprietary >compilers can do that, some did, and some will do it in the future.
I think that is called "scare tactics" and is not s real argument. Incidentally now several FOSS companies are doing cross licensing with the Great Satan I would be interested to see how accurate your scenario is. *IF* (and I think it is somewhat unlikely, but no more unlikely than your scenarios) these MS cross licensing and patents things to take hold GCC might be deemed as having broken various laws and could not then be used legally..... -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/