C Compiler for 8051 microcontroler

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].

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.

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

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

In article , Terry writes

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

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.

Yes.

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.

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.

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

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

Not to the same level the commercial compilers do.

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.

I am glad you can afford to.

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 /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

... snip ...

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.
     USE worldnet address!

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

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!!

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

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

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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.

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....

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.

one

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: snipped-for-privacy@iinet.net.au snipped-for-privacy@cs.curtin.edu.au

Now I *know* you are a troll.

Ian

... snip ...

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.
     USE worldnet address!

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: snipped-for-privacy@iinet.net.au snipped-for-privacy@cs.curtin.edu.au

[...]

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

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.

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.

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.

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: snipped-for-privacy@iinet.net.au snipped-for-privacy@cs.curtin.edu.au