C Compiler for 8051 microcontroler

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