Hi folks..

I looking for C compilers (and C++ if exist) for developing systems for 8051 uC.

Thanks..

Rafael Dias schrieb:

> I looking for C compilers (and C++ if exist) for developing systems for 8051 uC.

.... then look at http://www.8052.com. There are many links.

-- 
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Ma�.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

Rafael Dias wrote:
> 
> Hi folks..
> 
> I looking for C compilers (and C++ if exist) for developing systems for 8051 uC.
> 
> Thanks..

http://www.dontronics.com/wickenhaeuser.html


-- 
Don McKenzie
E-Mail Contact Page:      http://www.e-dotcom.com/ecp.php?un=Dontronics

Don's Free Guide To Spam Reduction http://www.e-dotcom.com/spam_exp.php
The World's Largest Range of Atmel/AVR & PICmicro Hardware and Software

If you're serious about your work and don't want to waste time, the best one
I've used is from Keil.  Would trust nothing else.  http://www.keil.com/

-Z


"Rafael Dias" <rdmeneze@yahoo.com.br> wrote in message
news:3e2bf39f.0401081053.309bcc13@posting.google.com...
> Hi folks..
>
> I looking for C compilers (and C++ if exist) for developing systems for
8051 uC.
>
> Thanks..

Keil is very good. Haven't tried others.

"MArk" <marky@mark.com> wrote in message news:<btllja$rt$1@ls219.htnet.hr>...
> Keil is very good. Haven't tried others.

Keil is good but costs $$$.  Decent freeware one is SDCC (small device c ompiler)

go here:

http://sdcc.sourceforge.net/

In article <a700329f.0401091415.274e290e@posting.google.com>, James
Miles <liquidl@email.com> writes
>"MArk" <marky@mark.com> wrote in message news:<btllja$rt$1@ls219.htnet.hr>...
>> Keil is very good. Haven't tried others.
>
>Keil is good but costs $$$.  
Yes

>Decent freeware one is SDCC (small device c 
>ompiler)

Well it is free.. but hardley decent yet. 

Try the Dunfeild compiler for a reasonable inexpensvie C compiler for
the 8051


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills threw some tea leaves on the floor
 and this is what they wrote:

> In article <a700329f.0401091415.274e290e@posting.google.com>, James
> Miles <liquidl@email.com> writes
>>"MArk" <marky@mark.com> wrote in message news:<btllja$rt$1@ls219.htnet.hr>...
>>> Keil is very good. Haven't tried others.
>>
>>Keil is good but costs $$$.  
> Yes
>
>>Decent freeware one is SDCC (small device c 
>>ompiler)
>
> Well it is free.. but hardley decent yet.

Here we go again!

SDCC *is* decent (depending upon your definition of decent :).

I've used it to drive a LCD display via a AT89C2051, drive a stepper,
and various other things. It has an excellent PC simulator, and quite a
few libraries.

SDCC is Free and unlimited.

It's also very stable and works nicely with all the Unix toolsets etc.

Sure it's not as smooth as Keil stuff, but it's most certainly usable
right *now* and has been for years.



-- 
              Kind Regards from Terry 
    My Desktop is powered by GNU/LinuX, Gentoo-1.4_rc2   
         New Homepage: http://milkstone.d2.net.au/          
 ** Linux Registration Number: 103931,  http://counter.li.org **

Chris Hills wrote:
> In article <a700329f.0401091415.274e290e@posting.google.com>, James
> Miles <liquidl@email.com> writes
> 
>>"MArk" <marky@mark.com> wrote in message news:<btllja$rt$1@ls219.htnet.hr>...
>>
>>>Keil is very good. Haven't tried others.
>>
>>Keil is good but costs $$$.  
> 
> Yes
> 
> 
>>Decent freeware one is SDCC (small device c 
>>ompiler)
> 
> 
> Well it is free.. but hardley decent yet. 
> 
> Try the Dunfeild compiler for a reasonable inexpensvie C compiler for
> the 8051
> 

Not enough information. If he is a hobbyist, suggesting Keil is as inappropriate
as farting loudly in church.

The eval mode is not even worth talking about. Dunfield might be OK, but I've never
heard anyone around here talk about it, good or otherwise.


[...]

>> Well it is free.. but hardley decent yet. 
>> 
>> Try the Dunfeild compiler for a reasonable inexpensvie C compiler for
>> the 8051
>> 

>Not enough information. If he is a hobbyist, suggesting Keil is as inappropriate
>as farting loudly in church.

>The eval mode is not even worth talking about. Dunfield might be OK, but I've never
>heard anyone around here talk about it, good or otherwise.

Thats because I don't believe in using public usenet groups to promote my
products (see my faq's) - I take it to email asap (exception when people start
thinking I don't exist anymore :-) - been in the business since 83.

Regards,

-- 
Dunfield Development Systems          http://www.dunfield.com
Low cost software development tools for embedded systems
Software/firmware development services       Fax:613-256-5821

Dave Dunfield wrote:
>>>Well it is free.. but hardley decent yet. 
>>>
>>>Try the Dunfeild compiler for a reasonable inexpensvie C compiler for
>>>the 8051
>>>
> 
> 
>>Not enough information. If he is a hobbyist, suggesting Keil is as inappropriate
>>as farting loudly in church.
> 
> 
>>The eval mode is not even worth talking about. Dunfield might be OK, but I've never
>>heard anyone around here talk about it, good or otherwise.
> 
> 
> Thats because I don't believe in using public usenet groups to promote my
> products (see my faq's) - I take it to email asap (exception when people start
> thinking I don't exist anymore :-) - been in the business since 83.
> 
> Regards,
> 

I wasn't talking about self promotion, but rather what others say. I was going to
try your compiler, which was one listed on the Cygnal site (at least at one time),
but I'm not expert enough to tell if the compiler is doing good job. Time has been
a severe constraint in the past, maybe less now, and maybe I'll have more opportunity
to learn the micro better and try your tool set.

If I had to go just on what people offered here, and a few other places, I would not
even have a starting opinion on your products.

Zelda (SDCC) has fleas. Not just a few, and not tiny ones either.

If you can sweet talk LEsly into sending you an evaluation copy of Keil, do
so.

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Computer Engineering Consultant.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au


"James Miles" <liquidl@email.com> wrote in message
news:a700329f.0401091415.274e290e@posting.google.com...
> "MArk" <marky@mark.com> wrote in message
news:<btllja$rt$1@ls219.htnet.hr>...
> > Keil is very good. Haven't tried others.
>
> Keil is good but costs $$$.  Decent freeware one is SDCC (small device c
ompiler)
>
> go here:
>
> http://sdcc.sourceforge.net/

M.R.Van Luyn. threw some tea leaves on the floor
 and this is what they wrote:

> Zelda (SDCC) has fleas. Not just a few, and not tiny ones either.

I believe we are discussing C compilers Mr Van Luyn, and not pets.

Perhaps you would be so kind as to be specific as to what kinds of
problems you believe the OP will encounter using SDCC ?

>
> If you can sweet talk LEsly into sending you an evaluation copy of Keil, do
> so.

Why beg for proprietary software when Free Software (GPL'd) is available
as your *right* ?

>
> Regards,
> Murray.
> _____________________________________
> Murray R.Van Luyn
> Computer Engineering Consultant.
> Ph:   +618 9354 1375
> E-mail: vanluynm@iinet.net.au
>            vanluynm@cs.curtin.edu.au
>
>
> "James Miles" <liquidl@email.com> wrote in message
> news:a700329f.0401091415.274e290e@posting.google.com...
>> "MArk" <marky@mark.com> wrote in message
> news:<btllja$rt$1@ls219.htnet.hr>...
>> > Keil is very good. Haven't tried others.
>>
>> Keil is good but costs $$$.  Decent freeware one is SDCC (small device c
> ompiler)
>>
>> go here:
>>
>> http://sdcc.sourceforge.net/
>
>


-- 
              Kind Regards from Terry 
    My Desktop is powered by GNU/LinuX, Gentoo-1.4_rc2   
         New Homepage: http://milkstone.d2.net.au/          
 ** Linux Registration Number: 103931,  http://counter.li.org **

On Sat, 10 Jan 2004 03:50:42 GMT, Bryan Hackney wrote:
> 
> 
> Chris Hills wrote:

> The eval mode is not even worth talking about. Dunfield might be OK, but I've never
> heard anyone around here talk about it, good or otherwise.

I use it to support the COMM-Links (oldest code is ~15 years old) on
my HCS project. I use it under dos-emu on my Linux box and it works
very well and it's very inexpensive. I'm happy with it.

-- 
Linux Home Automation         Neil Cherry        ncherry@comcast.net
http://home.comcast.net/~ncherry/               (Text only)
http://linuxha.sourceforge.net/                 (SourceForge)
http://hcs.sourceforge.net/                     (HCS II)

"Terry" <tjporter@gronk.porter.net> wrote in message
news:hfo4d1-6a6.ln1@gronk.porter.net...
> M.R.Van Luyn. threw some tea leaves on the floor
>  and this is what they wrote:
>
> > Zelda (SDCC) has fleas. Not just a few, and not tiny ones either.
>
> I believe we are discussing C compilers Mr Van Luyn, and not pets.
>
> Perhaps you would be so kind as to be specific as to what kinds of
> problems you believe the OP will encounter using SDCC ?
>

Please feel free to defend SDCC Terry. Varied and divergent opinion is a
very good thing. Just as you are free to state your opinion, readers of this
forum are free to formulate opinions and take actions based on  your
recommendations.

Zelda is fine if you want to write a few lines of code. I have found however
that for larger programs, the 'mystery' error rate increases exponentially
with the size of the code. I can't really tell you what's wrong with it -
maybe 'starts out happy, but eventually won't go' sums it up appropriately.
I'm not beyond stating that my experience may have been due to inexperience.
I wonder whether contributions to the associated manual from experienced
users such as yourself, wouldn't have helped to avoid some of the more
obvious pitfalls in Zelda's use.

The price is right, and I have a great deal of admiration for the clever
developers responsible for SDCCs creation. Use it though, and if you are a
sane and rational person, I categorically guarantee that you will abandon it
within a very short space of time. Failing that, I guess you could always
defend it to your dying breath.

I'm sorry Terry. I genuinely just don't want anyone else to waste the 3
painful weeks that I did.

Regards,
Murray.
___________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au

M.R.Van Luyn. threw some tea leaves on the floor
 and this is what they wrote:

> "Terry" <tjporter@gronk.porter.net> wrote in message
> news:hfo4d1-6a6.ln1@gronk.porter.net...
>> M.R.Van Luyn. threw some tea leaves on the floor
>>  and this is what they wrote:
>>
>> > Zelda (SDCC) has fleas. Not just a few, and not tiny ones either.
>>
>> I believe we are discussing C compilers Mr Van Luyn, and not pets.
>>
>> Perhaps you would be so kind as to be specific as to what kinds of
>> problems you believe the OP will encounter using SDCC ?
>>
>
> Please feel free to defend SDCC Terry.

Thank you, I do :)

> Varied and divergent opinion is a
> very good thing. Just as you are free to state your opinion, readers of this
> forum are free to formulate opinions and take actions based on  your
> recommendations.

Of course, and I urge those readers to intelligently examine what you have
said and evidence proffered, before they assume what you write is
gosphel.

>
> Zelda is fine if you want to write a few lines of code. I have found however
> that for larger programs, the 'mystery' error rate increases exponentially
> with the size of the code. I can't really tell you what's wrong with it -
> maybe 'starts out happy, but eventually won't go' sums it up appropriately.

Perhaps. It may also be another way of describing, fear uncertainty
and doubt ?

Free Software is different to closed source, it requires that we *all*
make it better by verifying bugs and then if we can't fix it ourselves,
lodging a bug report with the maintainer.

It seems to me (and I could be wrong) that you used SDCC, didn't know
what you were doing, didn't read the manual and just gave up ?

Did you determine what wasn't happening correctly, did you submit
a bug report ?

> I'm not beyond stating that my experience may have been due to inexperience.

Such an admission may not have gone astray in your original post I
submit.

> I wonder whether contributions to the associated manual from experienced
> users such as yourself, wouldn't have helped to avoid some of the more
> obvious pitfalls in Zelda's use.


We all have only so much time Mr Van Luyn, and mine is committed
elsewhere right now, although as you can see I do have a short article
regarding SDCC and screen shot on my current web page.

For a few years I also maintained a page that described using the SDCC
simulator with DDD the GUI debuger.

>
> The price is right, and I have a great deal of admiration for the clever
> developers responsible for SDCCs creation. Use it though, and if you are a
> sane and rational person, I categorically guarantee that you will abandon it
> within a very short space of time.

SDCC is used by many people and the SDCC list is highly active. So I can't
take your predictions seriously. 

> Failing that, I guess you could always
> defend it to your dying breath.

I haven't had anything to defend in this case, I simply asked for reasons
regarding your negative claims of SDCC, and so far you have not offered one
tangible reason.

Your SDCC inexperience hardly qualifies as valid criticism imho.

>
> I'm sorry Terry. I genuinely just don't want anyone else to waste the 3
> painful weeks that I did.

I understand and sympathise Mr Van Luyn, however experiences differ, as
do users of software.

Please be aware Mr Van Luyn, I'm not trying to start a flame war with
you over this, all I'm asking for are *reasons* for your criticism of
SDCC.



-- 
              Kind Regards from Terry 
    My Desktop is powered by GNU/LinuX, Gentoo-1.4_rc2   
         New Homepage: http://milkstone.d2.net.au/          
 ** Linux Registration Number: 103931,  http://counter.li.org **

In article <usv7d1-vnn.ln1@gronk.porter.net>, Terry
<tjporter@gronk.porter.net> writes
>M.R.Van Luyn. threw some tea leaves on the floor
> and this is what they wrote:
>Free Software is different to closed source, it requires that we *all*
>make it better by verifying bugs and then if we can't fix it ourselves,
>lodging a bug report with the maintainer.

Therefore YOU as the user  are responsible for all the code you ship
compiled with it. The FDA rules on software will make it cheaper to use
the Keil than the SDCC for any medical project.

>It seems to me (and I could be wrong) that you used SDCC, didn't know
>what you were doing, didn't read the manual and just gave up ?

I have come across other experienced embedded engineers who tried SDCC
and have found problems with it.  It is apparently better than it was
but nowhere near the same level of the commercial 8051 compilers.

>Did you determine what wasn't happening correctly, did you submit
>a bug report ?

Why? I am paid to write code NOT debug the tools. This is the problem
with this sort of tool. If you find a bug you are expected to spend time
and effort fixing it or hoping that some one else might some time. 

>> I wonder whether contributions to the associated manual from experienced
>> users such as yourself, wouldn't have helped to avoid some of the more
>> obvious pitfalls in Zelda's use.
>
>We all have only so much time Mr Van Luyn, and mine is committed
>elsewhere right now, although as you can see I do have a short article
>regarding SDCC and screen shot on my current web page.

This is the point. The commercial companies do fix problems and work
with customers.  Though a LOT of the problem sI see are due to
programmers who don't fully understand embedded C or the 8051
architecture that well. Much less how a compiler actually works.

>> The price is right, and I have a great deal of admiration for the clever
>> developers responsible for SDCCs creation. Use it though, and if you are a
>> sane and rational person, I categorically guarantee that you will abandon it
>> within a very short space of time.
>
>SDCC is used by many people and the SDCC list is highly active. So I can't
>take your predictions seriously. 

Many people use SDCC for two very important technical reasons.... it's
free and it runs on Linux.....  the other one is that it is open source.
This makes it UN-USABLE for much of the work I do. I have no guarantees
that it has not been "adjusted" buy some well meaning idiot.

Has it been run on either of the main C test suites? 
How does it cope with the paranoia test?
What testing has been done on it? 

>> Failing that, I guess you could always
>> defend it to your dying breath.
>
>I haven't had anything to defend in this case, I simply asked for reasons
>regarding your negative claims of SDCC, and so far you have not offered one
>tangible reason.
>Your SDCC inexperience hardly qualifies as valid criticism imho.

How much experience does he need to know it doesn't work?

>> I'm sorry Terry. I genuinely just don't want anyone else to waste the 3
>> painful weeks that I did.
>
>I understand and sympathise Mr Van Luyn, however experiences differ, as
>do users of software.
>
>Please be aware Mr Van Luyn, I'm not trying to start a flame war with
>you over this, all I'm asking for are *reasons* for your criticism of
>SDCC.

It doesn't work anything like as well as the commercial compilers, code
density etc.
It seems to have some serious short comings when compared to commercial
compilers.
It has not AFAIK passed anything like the Plum-Hall or Perennial tests.

Does it correctly handle structures? (It was mentioned to me a couple of
days ago it did not)
 




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"M.R.Van Luyn." <vanluynm@nospam.ses.curtin.edu.au> wrote in message 

> I'm sorry Terry. I genuinely just don't want anyone else to waste the 3
> painful weeks that I did.
> 

Hi Murray,
I was wondering if that was recent.
According to the CVS log quite a lot has been done recently.

Regards
Robert

"Robert Gush" <robert@suesound.co.za> wrote in message
news:a0f35ea5.0401110831.3ce6ed@posting.google.com...
> Hi Murray,
> I was wondering if that was recent.
> According to the CVS log quite a lot has been done recently.
>
> Regards
> Robert

Thanks Robert.

Yes this was just a few weeks ago. I started out with the DOS version
1.2.2.1 2001/09/19 (oh, now I'm really asking for it, aren't I?), and then
moved to the latest Linux distribution. No improvement I'm afraid. I also
had a brief look at the CVS source. Highly impressive, but I couldn't figure
out how to compile it for my system.

I also tried Wickenhauser's C compiler. I found it a bit quirky, but an
overall improvement. I was a bit worried about the manual's claims that it
produced smaller, faster code, though. My programs always ran slow. It
looked like pretty good value.

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au

Chris Hills threw some tea leaves on the floor
 and this is what they wrote:

> In article <usv7d1-vnn.ln1@gronk.porter.net>, Terry
><tjporter@gronk.porter.net> writes
>>M.R.Van Luyn. threw some tea leaves on the floor
>> and this is what they wrote:
>>Free Software is different to closed source, it requires that we *all*
>>make it better by verifying bugs and then if we can't fix it ourselves,
>>lodging a bug report with the maintainer.
>
> Therefore YOU as the user  are responsible for all the code you ship
> compiled with it.

Are you not responsible for your code Chris ?

> The FDA rules on software will make it cheaper to use
> the Keil than the SDCC for any medical project.

I don't doubt you, but how is the FDA relevant in this thread ?

>
>>It seems to me (and I could be wrong) that you used SDCC, didn't know
>>what you were doing, didn't read the manual and just gave up ?
>
> I have come across other experienced embedded engineers who tried SDCC
> and have found problems with it.  It is apparently better than it was
> but nowhere near the same level of the commercial 8051 compilers.

I understand that, and I haven't claimed it is.

>
>>Did you determine what wasn't happening correctly, did you submit
>>a bug report ?
>
> Why? I am paid to write code NOT debug the tools.

A bug report is *not* debuging the tools.


> This is the problem
> with this sort of tool. If you find a bug you are expected to spend time
> and effort fixing it or hoping that some one else might some time. 

Your ignorance about Free Software is astounding at times.

For every current Free Software package there is always a maintainer,
and that person or persons fixes bugs. 

>
>>> I wonder whether contributions to the associated manual from experienced
>>> users such as yourself, wouldn't have helped to avoid some of the more
>>> obvious pitfalls in Zelda's use.
>>
>>We all have only so much time Mr Van Luyn, and mine is committed
>>elsewhere right now, although as you can see I do have a short article
>>regarding SDCC and screen shot on my current web page.
>
> This is the point. The commercial companies do fix problems and work
> with customers.

Do they ?

They certainly take your money. They certainly go broke or get taken
over and dismantled, they certainly have key personel leave etc.

> Though a LOT of the problem sI see are due to
> programmers who don't fully understand embedded C or the 8051
> architecture that well. Much less how a compiler actually works.
>
>>> The price is right, and I have a great deal of admiration for the clever
>>> developers responsible for SDCCs creation. Use it though, and if you are a
>>> sane and rational person, I categorically guarantee that you will abandon it
>>> within a very short space of time.
>>
>>SDCC is used by many people and the SDCC list is highly active. So I can't
>>take your predictions seriously. 
>
> Many people use SDCC for two very important technical reasons.... it's
> free and it runs on Linux.....  the other one is that it is open source.
> This makes it UN-USABLE for much of the work I do.

Why ?

> I have no guarantees
> that it has not been "adjusted" buy some well meaning idiot.

You have no such guarantees with proprietary software either.
In fact you have *less* guarantees as you don't have the source to
check what's changed.

>
> Has it been run on either of the main C test suites? 
> How does it cope with the paranoia test?
> What testing has been done on it?

Good questions, how do you answer them for your proprietary software ?

>
>>> Failing that, I guess you could always
>>> defend it to your dying breath.
>>
>>I haven't had anything to defend in this case, I simply asked for reasons
>>regarding your negative claims of SDCC, and so far you have not offered one
>>tangible reason.
>>Your SDCC inexperience hardly qualifies as valid criticism imho.
>
> How much experience does he need to know it doesn't work?

Are you claiming that SDCC "doesn't work" now ?

>
>>> I'm sorry Terry. I genuinely just don't want anyone else to waste the 3
>>> painful weeks that I did.
>>
>>I understand and sympathise Mr Van Luyn, however experiences differ, as
>>do users of software.
>>
>>Please be aware Mr Van Luyn, I'm not trying to start a flame war with
>>you over this, all I'm asking for are *reasons* for your criticism of
>>SDCC.
>
> It doesn't work anything like as well as the commercial compilers, code
> density etc.

I don't doubt you, but why is this an issue ?

> It seems to have some serious short comings when compared to commercial
> compilers.

That remark is so general, I'll just ignore it.


> It has not AFAIK passed anything like the Plum-Hall or Perennial tests.

Irrelevant for Free Software because of the proprietary nature of these
test suites.

The Plum Hall test suite requires licensing and hence it is not
acceptable to Free Software. Same for the PERENNIAL Validation Suites.

>
> Does it correctly handle structures? (It was mentioned to me a couple of
> days ago it did not)

Perhaps you would like to show why it does not ?



-- 
              Kind Regards from Terry 
    My Desktop is powered by GNU/LinuX, Gentoo-1.4_rc2   
         New Homepage: http://milkstone.d2.net.au/          
 ** Linux Registration Number: 103931,  http://counter.li.org **

M.R.Van Luyn. threw some tea leaves on the floor
 and this is what they wrote:

> "Robert Gush" <robert@suesound.co.za> wrote in message
> news:a0f35ea5.0401110831.3ce6ed@posting.google.com...
>> Hi Murray,
>> I was wondering if that was recent.
>> According to the CVS log quite a lot has been done recently.
>>
>> Regards
>> Robert
>
> Thanks Robert.
>
> Yes this was just a few weeks ago. I started out with the DOS version
> 1.2.2.1 2001/09/19 (oh, now I'm really asking for it, aren't I?), and then
> moved to the latest Linux distribution. No improvement I'm afraid. I also
> had a brief look at the CVS source. Highly impressive, but I couldn't figure
> out how to compile it for my system.

The released version is really quite old compared to the CVS version.



-- 
              Kind Regards from Terry 
    My Desktop is powered by GNU/LinuX, Gentoo-1.4_rc2   
         New Homepage: http://milkstone.d2.net.au/          
 ** Linux Registration Number: 103931,  http://counter.li.org **

On 2004-01-12, Terry <tjporter@gronk.porter.net> wrote:

>>>Did you determine what wasn't happening correctly, did you
>>>submit a bug report ?
>>
>> Why? I am paid to write code NOT debug the tools.
>
> A bug report is *not* debuging the tools.

And you'd have to do the same thing with commercial tools
anyway [and then the bug doesn't get fixed for a year or two].

>>>We all have only so much time Mr Van Luyn, and mine is
>>>committed elsewhere right now, although as you can see I do
>>>have a short article regarding SDCC and screen shot on my
>>>current web page.
>>
>> This is the point. The commercial companies do fix problems and work
>> with customers.
>
> Do they ?

Not in my experience.

I've gotten far, far, better support for the Gnu toolchain that
I ever got for any commercial product. For example, the bug I
found in the ARM assembler was fixed within hours of my
reporting it [and it was a very obscure bug].  

When I discovered there was a feature I wanted that wasn't
supported by the H8 linker, somebody told me exactly where/what
to do. Within a few hours, the feature was working.  A day
later my code had been reviewed, tweaked, and committed to the
official CVS tree by a maintainer.

>> I have no guarantees that it has not been "adjusted" buy some
>> well meaning idiot.
>
> You have no such guarantees with proprietary software either.

Apparently he never reads the license for that software stating
that it's "not guaranteed fit for anything. At all.  Ever."

> In fact you have *less* guarantees as you don't have the
> source to check what's changed.

-- 
Grant Edwards                   grante             Yow!  BARBARA STANWYCK
                                  at               makes me nervous!!
                               visi.com            

In article <ualad1-3ak.ln1@gronk.porter.net>, Terry
<tjporter@gronk.porter.net> writes
>Chris Hills threw some tea leaves on the floor
> and this is what they wrote:
>
>> In article <usv7d1-vnn.ln1@gronk.porter.net>, Terry
>><tjporter@gronk.porter.net> writes
>>>M.R.Van Luyn. threw some tea leaves on the floor
>>> and this is what they wrote:
>>>Free Software is different to closed source, it requires that we *all*
>>>make it better by verifying bugs and then if we can't fix it ourselves,
>>>lodging a bug report with the maintainer.
>>
>> Therefore YOU as the user  are responsible for all the code you ship
>> compiled with it.
>
>Are you not responsible for your code Chris ?

Yes. But my code does not include the compiler and validating it as
well. 


>> The FDA rules on software will make it cheaper to use
>> the Keil than the SDCC for any medical project.
>I don't doubt you, but how is the FDA relevant in this thread ?

I have to work to FDA guidelines with some code. the requirements for
validating the compiler mean that I can use a validated commercial
compiler but could not afford to validate something like the SDCC. 

>> This is the point. The commercial companies do fix problems and work
>> with customers.
>Do they ?

Yes.

>They certainly take your money. They certainly go broke or get taken
>over and dismantled, they certainly have key personel leave etc.

But in a company you can change personal and not loose anything. It is
not the same as passing an open source project around. Besides the
embedded tools companies tend to vet people working on their tools.

>> Many people use SDCC for two very important technical reasons.... it's
>> free and it runs on Linux.....  the other one is that it is open source.
>> This makes it UN-USABLE for much of the work I do.
>
>Why ?

If it is open source, I have to test and validate the version I have. I
have no idea if the one I have is the tested version of if some well
meaning idiot has "adjusted" the source and re-compiled it. 

>> I have no guarantees
>> that it has not been "adjusted" buy some well meaning idiot.
>
>You have no such guarantees with proprietary software either.
>In fact you have *less* guarantees as you don't have the source to
>check what's changed.

Far more guarantees... unless you are suggesting the the commercia
companies lie? 


>> Has it been run on either of the main C test suites? 
>> How does it cope with the paranoia test?
>> What testing has been done on it?
>
>Good questions, how do you answer them for your proprietary software ?

Yes. I can even quote the Plum-Hall Licence number for the compiler test
suite.  


>> How much experience does he need to know it doesn't work?
>
>Are you claiming that SDCC "doesn't work" now ?

Not to the same level the commercial compilers do. 

>I don't doubt you, but why is this an issue ?

this is where we started...  It is probable (I don't have the chapter
and verse to quote so I wont say it is the case exactly) that Keil
compiler for example will produce executable that is half the size of
the SDCC. More to the point with data overlaying and correct handling of 
integer promotion there are a lot of programs that will fit on chip in
an 8, 61, 32 or64K single chip part that wouldn't fit with the SDCC.
External memory is expensive.  Also of course you loose port pins. that
could push the cost of the design up by a few dollars.. say one or
two.... now multiply that by a run of 10,000 units. Your "free" compiler
has just cost you 10,000 dollars.


>> It seems to have some serious short comings when compared to commercial
>> compilers.
>That remark is so general, I'll just ignore it.
I am glad you can afford to.


>> It has not AFAIK passed anything like the Plum-Hall or Perennial tests.
>Irrelevant for Free Software because of the proprietary nature of these
>test suites.
>The Plum Hall test suite requires licensing and hence it is not
>acceptable to Free Software. Same for the PERENNIAL Validation Suites.

This is like the primitive tribes (all long since gone) that said the
bullets of the un-believers could not hurt them. 

I am not interested in your political/phiosophical beliefs. Which
industry accepted  tests have been applied to the SDCC compiler? which
has it passed?

None. In other words it is not an industrial C compiler? your "opinion"
does not count. Can yo finds anyone (suitably qualified) who would
support that the SDCC compiler (as it is now) is suitable for industrial
use?

A test is a test 2+2=4 regardless if it is calculated with a FSF program
or a commercial one. Any program that gives an incorrect answer is
wrong. It is no use you whining that you don't like the test. the Plum-
Hall and Perennial are the industry wide test suites. If you want o play
in the industrial world you have to pass these. Or of course come up
with your own (Free) test suite that is also accepted as a test for
compilers.

The SDCC has very poor code density and is untested by any accepted
industry test suite. Therefore it is not relevant for any industrial
use. Just hobby use.

I think that is what I said to start with.

I think for anyone who wants to experiment with a compiler, learn
parsing etc it is a great learning tool but I would not use it for any
commercial software.


BTW as it happens I am involved in doing a test suite that will be GPL.
It is not for compilers though.


Regards
        Chris.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> 
.... snip ...
> 
> I think for anyone who wants to experiment with a compiler, learn
> parsing etc it is a great learning tool but I would not use it
> for any commercial software.
> 
> BTW as it happens I am involved in doing a test suite that will
> be GPL. It is not for compilers though.

I believe there exists a GPL C test suite for gcc.  I know no
details.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In article <hqFap7CV0vAAFA8k@phaedsys.demon.co.uk>, Chris Hills wrote:

> If it is open source, I have to test and validate the version I have.

How is that any different than having to test and validate the
verion you have of a commecial product?

> I have no idea if the one I have is the tested version of if
> some well meaning idiot has "adjusted" the source and
> re-compiled it. 
> 
>>> I have no guarantees that it has not been "adjusted" buy some
>>> well meaning idiot.
>>
>>You have no such guarantees with proprietary software either.
>>In fact you have *less* guarantees as you don't have the source to
>>check what's changed.
> 
> Far more guarantees... unless you are suggesting the the commercia
> companies lie? 

No, but their software has more bugs than open-source
equivalents according to a number of fairly extensive studies.
[Of course if you can't find an open-source equivalent, it's
moot.]

-- 
Grant Edwards                   grante             Yow!  -- I can do
                                  at               ANYTHING... I can
                               visi.com            even... SHOPLIFT!!

In article <4003746c$0$547$a1866201@newsreader.visi.com>, Grant Edwards
<grante@visi.com> writes
>In article <hqFap7CV0vAAFA8k@phaedsys.demon.co.uk>, Chris Hills wrote:
>
>> If it is open source, I have to test and validate the version I have.
>
>How is that any different than having to test and validate the
>verion you have of a commecial product?

Because it has already been tested with the plum hall suite and passed
so I don't have to do it.

>> I have no idea if the one I have is the tested version of if
>> some well meaning idiot has "adjusted" the source and
>> re-compiled it. 
>> 
>>>> I have no guarantees that it has not been "adjusted" buy some
>>>> well meaning idiot.
>>>
>>>You have no such guarantees with proprietary software either.
>>>In fact you have *less* guarantees as you don't have the source to
>>>check what's changed.
>> 
>> Far more guarantees... unless you are suggesting the the commercia
>> companies lie? 
>
>No, but their software has more bugs than open-source
>equivalents according to a number of fairly extensive studies.
>[Of course if you can't find an open-source equivalent, it's
>moot.]

I suppose you have figures to back that up?  BTW this is for embedded
compilers.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Terry" <tjporter@gronk.porter.net> wrote in message
news:usv7d1-vnn.ln1@gronk.porter.net...

> It seems to me (and I could be wrong) that you used SDCC, didn't know
> what you were doing, didn't read the manual and just gave up ?

I did indeed give up on Zelda. I can assure you that for the 20 or so days
that I struggled with it, that I made very good use of the manual. I cranked
out only 70K of source in that time (very slow going), and on the last 3
days I got nowhere.

> Did you determine what wasn't happening correctly, did you submit
> a bug report ?

You reach a point with Zelda at which it is just impossible to tell why the
compiler hangs, generates bizarre code, or gives you insensible error
messages. Ultimately no amount of 'working around' problems or re-ordering
code will please the compiler. I'm not sure about bug reports, but I sent a
few queries in.

ie. Why does this hang the compiler?

unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
{
    unsigned char no_more = FALSE;
    xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];

    do
    {
        no_more = (*buffer_loader)(packet_data_buffer);

etc.

I sent in a few queries regarding the printf() function too. There's
basically nothing in the manual regarding this, and the mailing list replies
weren't altogether what I had hoped for.

Incidentally, the Keil compiler has no problem with the above snippet. Nor
the 'curious truth', nor printing floating point numbers, nor passing
structures, nor....

> SDCC is used by many people and the SDCC list is highly active. So I can't
> take your predictions seriously.

Yes, I subscribed to the mailing list for a month. On average there were 2
postings a day (most 6, least 0). Highly active? There seems to be a few
postings between the dedicated developers who are working feverishly to
improve Zelda, and then the predictable stream of "Gee, this is great...oh,
it's buggy...good luck guys. Seeya" type messages.

> I haven't had anything to defend in this case, I simply asked for reasons
> regarding your negative claims of SDCC, and so far you have not offered
one
> tangible reason.

I have no problem with that. I guess if I had logged each and every of the
numerous hiccups that I encountered, then I might be able to make a more
salient argument.

As it should be, it is then up to readers to make up their own minds. By all
means try SDCC. If you only use it as a lazy compiler (quite admirable in a
busy world, and with well resourced microcontrollers) then Zelda might be
for you. If you reach a level of familiarity at which you can appreciate the
'nick' Zelda, then you might think to cut your losses.

Regards,
Murray.
 _____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au

M.R.Van Luyn. wrote:

> "Terry" <tjporter@gronk.porter.net> wrote in message
> news:usv7d1-vnn.ln1@gronk.porter.net...
> 
>> It seems to me (and I could be wrong) that you used SDCC, didn't know
>> what you were doing, didn't read the manual and just gave up ?
> 
> I did indeed give up on Zelda. I can assure you that for the 20 or so days
> that I struggled with it, that I made very good use of the manual. I
> cranked out only 70K of source in that time (very slow going), and on the
> last 3 days I got nowhere.
> 

Now I *know* you are a troll.

Ian

"M.R.Van Luyn." wrote:
> 
.... snip ...
> 
> ie. Why does this hang the compiler?
> 
> unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> {
>     unsigned char no_more = FALSE;
>     xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> 
>     do
>     {
>         no_more = (*buffer_loader)(packet_data_buffer);

For one thing, you are giving buffer_loader a parameter of type:

  xdata unsigned char   /* whatever that may be */

when it requires:

  unsigned char *

so at most you are complaining about compiler error handling.  If
another compiler handles that without complaint it must be faulty.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:400535C6.9911425B@yahoo.com...
> "M.R.Van Luyn." wrote:
> >
> ... snip ...
> >
> > ie. Why does this hang the compiler?
> >
> > unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> > {
> >     unsigned char no_more = FALSE;
> >     xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> >
> >     do
> >     {
> >         no_more = (*buffer_loader)(packet_data_buffer);
>
> For one thing, you are giving buffer_loader a parameter of type:
>
>   xdata unsigned char   /* whatever that may be */
>
> when it requires:
>
>   unsigned char *

Thanks Chuck. I always enjoy your posts.

I was pretty sure that I was passing the address in memory of the first
element of the packet_data_buffer array, to the function pointed to by
buffer_loader (which has as it's formal parameter a pointer to an element of
type unsigned char). Neither Borland C++ (minus the xdata part), nor the
Keil toolset seemed to mind.

I will look it up, though. I recognise that the first stage in effective
learning is to admit that I may not know everything, and am sometimes wrong.

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au

On Wed, 14 Jan 2004 15:47:39 +0800, "M.R.Van Luyn."
<vanluynm@nospam.ses.curtin.edu.au> wrote:

[...]
>ie. Why does this hang the compiler?

I've never tried SDCC, I don't know its ins and outs, but as far as
Keil is concerned...

>
>unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
>{
>    unsigned char no_more = FALSE;
>    xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
>
>    do
>    {
>        no_more = (*buffer_loader)(packet_data_buffer);
>

It is a strange piece of code...

You are requesting a local auto variable be located in xdata.  I
wasn't aware Keil would accept that silently.  From the limited
context you've provided, I can't tell for sure, , but I would expect
you meant "static xdata unsigned char..."  Perhaps thats what Keil
actually does.

Note that (in Keil) "unsigned char *" is a three-byte type, but "xdata
unsigned char *" is only a two-byte type.  Presumably Keil isn't
complaining because it coerces the type conversion.  Make sure that
any function you pass to xmodem_tx expects an "unsigned char *" and
not "xdata unsigned char *".

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

"Dave Hansen" <iddw@hotmail.com> wrote in message
news:40055603.159257904@News.CIS.DFN.DE...
> I've never tried SDCC, I don't know its ins and outs, but as far as
> Keil is concerned...
>
> >
> >unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> >{
> >    unsigned char no_more = FALSE;
> >    xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> >
> >    do
> >    {
> >        no_more = (*buffer_loader)(packet_data_buffer);
> >
>
> It is a strange piece of code...

Yes it is. Perhaps I should place it in a wider context. I wanted a module
that would xmodem transfer a file through the serial port, and which was
sufficiently modular to be readily incorporated into any application,
whether it be the current project or some later development. The only
external requirement for this module was to be an application specific
function that would refill a data buffer until all data had been
sent. I pass the address of this external function into the finished and
tested xmodem module when I want to send the file, so that I don't have to
screw about with the xmodem library module each time I use it. Nothing
ground-breaking, just trying to think about code management.

> You are requesting a local auto variable be located in xdata.  I
> wasn't aware Keil would accept that silently.  From the limited
> context you've provided, I can't tell for sure, , but I would expect
> you meant "static xdata unsigned char..."  Perhaps thats what Keil
> actually does.

Hmm. Keil seems to compile it like this without any fuss. If it stayed as an
auto I couldn't see a problem accessing the buffer from within the called
loader routine. Keil is quite probably doing something with it that I don't
understand just yet. Maybe the manual will shed some more light. There's
really no way for me to tell what Zelda does in this situation.

> Note that (in Keil) "unsigned char *" is a three-byte type, but "xdata
> unsigned char *" is only a two-byte type.  Presumably Keil isn't
> complaining because it coerces the type conversion.  Make sure that
> any function you pass to xmodem_tx expects an "unsigned char *" and
> not "xdata unsigned char *".

Yes your quite right about the "unsigned char *" being a 3 byte, generic
pointer in Keil. I believe that such a pointer can be used to point to
variables in any data space, including xdata. At run time, when you pass it
a memory location, the type of memory space is recorded in the third byte.
It's apparently a slower method than Keil's 2 byte pointer access, but has
the advantage that my external buffer filling function need not be modified
if I subsequently choose to store the packet data buffer elsewhere in
memory. The same code will just as easily work with a buffer located in the
data memory space as in the xdata space. As you have suggested, I will be
careful to only pass a function that expects an "unsigned char *" to the
xmodem_tx function as above.

Gee, a good compiler manual makes you sound like a real expert. Well, at
least it doesn't leave you looking such a prawn.

The discrepancy  between an "xdata unsigned char" address being passed as an
actual parameter to the *buffer_loader function (which expects the address
of an "unsigned char") looks more and more like a stuff-up when viewed as
SDCC code. I remember being quite certain at the time of submitting it to
the SDCC mailing list, that this was how I had to address the situation with
Zelda, given my experience at that time. It looked odd when I re-posted it
here, but I left it that way. I really don't know now. To tell you the
truth, I don't think Zelda minds too much what a pointer references. The
snipet crashes the compiler no matter how you address the matter, so I guess
it's of no consequence.

Thanks for that one Dave.

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph:   +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au