>-----Original Message-----
>From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] 
>Sent: 27 August 2006 22:46
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Your Favorite PIC C Compiler.
>
>
>On Sun, 2006-08-27 at 11:05 -0400, Gerry Duprey wrote:
>> Howdy,
>> 
>> >>>For the PIC 16 there is no good compiler from any source.  You 
>> >>>might
>> >>
>> >>I guess I would disagree.  I've been using the HiTech C 
>compiler for 
>> >>the 16
>> >>series for about a year.  Before that, I coded many 
>projects in ASM and while 
>>  >
>> > I then found two bugs in the compiler. One case was the compiler 
>> > didn't
>> 
>> Yeah -- I ran into a bank switching bug too.  I guess to be fair, 
>> trying to
>> merge banking stuff on the PIC (which is pretty oddly worked 
>between the 
>> difference in RAM access and FSR access) with C is tough, 
>but then again, 
>> that's why you pay.  HiTech took care of it as soon as I 
>identified it 
>> (granted, as you say, identifying it was the tough part).
>
>Interesting. When I found it I looked up the forums for a 
>solution. The bug didn't seem to be mentioned anywhere. So I 
>simply worked around it (set the bank manually) and completed 
>the project. 
>
>> > I'm sure both those bugs were fixed LONG ago, but based on the 
>> > amount of time I wasted tracing down those compiler bugs I decided 
>> > to NEVER AGAIN use a HiTech C product.
>> 
>> It was a pain to be sure, but I have to imagine there is other 
>> software you
>> use that has had bugs and you continue to use it?  One 
>(understandably 
>> frustrating) bug seems like a pretty low bar to expel a 
>piece of software. 
>
>Very true, and had it been only one bug, I would have been OK 
>with the tool. The problem was it was TWO bugs, both VERY 
>SIMPLE things. It's not like I was doing anything complicated. 
>The first was the FSR banking bug, a BEAR to figure out.
>
>The second bug was a result of an integer divide, something like:
>	i = 25/x;
>
>The result was clearly wrong, but only THAT LINE of my code 
>was wrong, all other divides seemed to work fine. This was a 
>similar train of events as I found with the banking bug, all 
>other SFRs had their banking bits set properly, but ONE line 
>didn't work right. I replaced the divide with a for loop and 
>my routine worked fine after that. (the ICD2 was EXTREMELY 
>helpful in figuring this one out, for the first bug I didn't 
>have the ICD2 making it that much harder to figure out what 
>was going wrong).
>
>One bug I can stand. Two bugs, in the span of less then a 
>month, was my tipping point. Some might consider that harsh, 
>but so be it. In actuality that was also the last hobby 
>project I did with a 16F part.
>
>> For myself, with that sort of bar, I'd probably not be able 
>to turn on 
>> my
>> computer :-)
>
>The bar is variable. It's not the NUMBER of bugs that will tip 
>the scale with me, it's the amount of time I waste BECAUSE of 
>a bug that counts. In the case of windows it took way more 
>then 2 bugs to cause me to switch, but that point eventually 
>came, and now I'm basically exclusively Linux. Linux surely 
>has bugs as well, but I've found that solving them is actually 
>possible, and very easy to figure out (google is your best 
>friend for Linux problems IMHO).

I don't think I would have a single compiler availble to me if I took that view.  C18 was riddled with bug a few years back, the AVR port of GCC that I've been using has numerous bugs and examples of appalling lack of optimisation (though it's not the very latest version).

Personaly I think their is only one sensible way in which to judge a compiler, at least from a commercial point of view: support.  It doesn't matter is you only wasted an hour finding a compiler bug if the vendor won't fix it.  I have reported a couple of bugs in HiTechs compilers and either it was a known issue and a patch was already available or one was made available very quickly.

Best Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist