LPC900/80C51 Compiler Toolchain

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&#4294967295;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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/