> Does anyone know if there exists any WORKING C-compilers for PIC
> microcontrollers.  I have been using MPLAB-C for a while, and it is simply
> the WORST C-compiler I have ever tried.  The compiler crashes if you do not
> carefully insert spaces and comments at all critical places in your code.
> If you are lucky enough to be able to run the compilator on your code, you
> can be quite shure that the code it produces is wrong.
>
> So, is this the only option out there??
>
> HŒvard

> From: Rick Miller <spamBeGonerdmillerspamBeGoneexecpc.com>
> To: TakeThisOuTPICLISTEraseMEspam_OUTmitvma.mit.edu
> Subject: Re: C-compilers for PIC
> Date: Monday, June 09, 1997 5:46 AM
>
> I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> doesn't have all those nasty limitations.  Want multi-dimensional arrays?
> No problem!  Want more than two arguments for a function?  No problem!
> Check it out:
>
>   http://www.execpc.com/~ccs/
>
> Mark, the author, knows his stuff.  It's much better than any other C
> compiler I've seen for the PIC.  And Cheryl (an incredibly beautiful

>Date:    Mon, 9 Jun 1997 16:07:25 +0200
>From:    Eric Martens <EraseMEemarKNOWARE.NL>
>Subject: Re: C-compilers for PIC
>
>Hello Havard
>
>|Does anyone know if there exists any WORKING C-compilers for PIC
>|microcontrollers.  I have been using MPLAB-C for a while, and it is simply
>|the WORST C-compiler I have ever tried.  The compiler crashes if you do not
>|carefully insert spaces and comments at all critical places in your code.
>|If you are lucky enough to be able to run the compilator on your code, you
>|can be quite shure that the code it produces is wrong.
>
>|So, is this the only option out there??
>
>I have here a C compiler (freeware) i haven't had any time to test it out. The
> complete
>zip file is 112KB big. If you'd like i can email it to you. It looks
> interesting, maybe
>this is what you are looking for.
>
>I know that a friend of mine (who does a lot of pic programming(it is his job
> !!!)) has
>been grumbling about the MPLAB-C program for a while now. He says the same
>thing as you do.
>He always says "It's just like a small child, you have to help it to get the
>job right"

> > "correct" changed apparently on a whim?  Don't want docs?
> >
> > And that's my short list.
>
> As a user of the CCS compiler, I will readily admit that the problems you
> describe are indeed annoying.  On the other hand, compared with my MPLABC
> experience I'd say CCS is pretty good (if you call tech support because
> the compiler mis-evaluates an expression, would you rather get a response
> of "Yeah, it has that problem.  We may fix that in a month or two," or
> "Oops, that doesn't seem to work right.  I'll try to get it fixed by
> tomorrow."

>At 07:46 AM 6/9/97 -0500, you wrote:
>>I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
>>doesn't have all those nasty limitations.  Want multi-dimensional arrays?
>>No problem!  Want more than two arguments for a function?  No problem!
>
>Want bugs?  Want a new release every day?  Want operation and definition of
>"correct" changed apparently on a whim?  Don't want docs?
>
>And that's my short list.
>
>Andy
>
>==================================================================
>Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
>          Hardware & Software for Industry & R/C Hobbies
>        "Go fast, turn right, and keep the wet side down!"
>==================================================================
>
>

> 0 to 65535.
>
> Much as I like the CCS compiler, its handling of multiplies is IMHO quite
> broken.  An 8x8->16 multiply is not significantly slower than 8x8->8, but
> unless you write your on multiply (as I usually do) the only way to get a
> 16 bit result from the multiply is to do a 16x16 multiply (MUCH slower!)
>
> > period=(timer_value+(long)nr_overflow*255)/x;
> >
> > This cast will force the promotion of the first arithmetic operation to
> > occur as 16 bit.  All following will happen that way as well.
>
> Faster would be this:
>
> typedef struct TWOBYTES {char l, h;};
> typedef union BYTEHL {long w; TWOBYTES b;};
>
> long mult255(ub val)
> {
>   BYTEHL temp;
>
>   temp.b.h=val; temp.b.l = 0;
>   temp.w -= val;
>   return temp.w;
> }

> > of "Yeah, it has that problem.  We may fix that in a month or two," or
> > "Oops, that doesn't seem to work right.  I'll try to get it fixed by
> > tomorrow."
> >
>
> The tolerance you guys seem to have amazes me.
>
> If one of these compilers mis-evaluates an expression, it can take
> hours if not days to discover where the code is going wrong. To then
> have someone on the phone say they'll *try* and fix it by tomorrow
> doesn't seem to be enough in the way of compensation.

> From: Andrew Warren <RemoveMEfastfwdKILLspamTakeThisOuTIX.NETCOM.COM>
> To: spamBeGonePICLIST@spam@MITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Thursday, 12 June 1997 06:32
>
> terogers <RemoveMEtrogersspam_OUTtimetech.com> wrote:
>
> > I've documented a lot of the behavior of the CCS stuff that I
> > didn't like to the people at CCS. .... I have yet to see a
> > mis-evaluation; in every case that I haven't seen what I expect,
> > the compiler is operating as designed. Sometimes it follows the
> > original K&R style, and sometimes the behavior is related to the
> > implementation.
>
> Tom:
>
> Six months ago, I thought I'd give the CCS compilers a try... It
> took about an hour to find a HUGE number of errors and problems,
> including the following cases where the compiler (PCM version 2.204)
> generated incorrect code:
>
>         long v,w;   // v and w are 16-bit (unsigned) words.
>         int x;      // x is an 8-bit (unsigned) word.

> > Much as I like the CCS compiler, its handling of multiplies is IMHO quite
> > broken.  An 8x8->16 multiply is not significantly slower than 8x8->8, but
> > unless you write your on multiply (as I usually do) the only way to get a
> > 16 bit result from the multiply is to do a 16x16 multiply (MUCH slower!)

> Much faster!  I use that TWOBYTES trick to split WORDS (long) into BYTES,
> without the need to do two divides (well, one is a modulus op, but it calls
> the same 16bit divide routine.)  I haven't actually looked at CCS's mult
> /divide routines carefully, you really think they're bad? (as in slow, not
> necessarily inaccurate)

>
> ----------
> > From: Andrew Warren <RemoveMEfastfwdKILLspam@spam@IX.NETCOM.COM>
> > To: PICLISTspamBeGone.....MITVMA.MIT.EDU
> > Subject: Re: C-compilers for PIC
> > Date: Thursday, 12 June 1997 17:37
> >
> > I wrote:
> >
> > > > I gave up on the idea of using the CCS compilers for anything
> > > > serious and [have] continued to use MPC.
> >
> > and Mike Smith <KILLspamPICLIST.....MITVMA.MIT.EDU> replied:
> >
> > > MPC seems to have its share of detractors, too.
> >
> >     Name one, Mike... Seriously.
>
> Just have a look at the number of happy, satisfied customers for MPLAB-C -
> Here's a quote from the PicList in the past week...
>
> >> About two weeks ago a Mchip engineer noted that MPLAB-C now also
> >> features this code (at last).
>
> >> I tried Mchip's code yesterday, and it doesn't work (hahahahahahahaha).
> >> I had to use the hacked code for a '74 on a '64a. I am SICK, SICK, SICK
> of
> >> the lack of *ANY* (null, zero, nada, zip) support on MPLAB-C. If it was
> >> a freeware compiler, it would have been ok, but we paid (a lot of) good
> >> money for it.
>
> >> The only upgrades we get on MPLAB-C seems to be new random error
> >> messages.
>
> >> If anybody knows of a Mchip email address where I can lodge a formal
> >> complaint about this, please mail it to me.
>
> (Thanks for the quoted material, Tjaart:)

>
> >
> >     I'm not implying that MPC has no detractors, of course; I'm only
> >     suggesting that a discussion like this should include comments
> >     from people who've actually used the compilers in question and
> >     who can point out SPECIFIC shortcomings.
> >
>
> I haven't, and with comments like the above quote and others, am unlikely
> to pay the rather high price.

> >         The problem occurs when you try to perform any MATH on the
> >         pointer.  Let's say, for instance, that you want to fill 10
> >         contiguous locations with 0x1234... You'd probably do
> >         something like this:
> >
> >             long far *p;    // In MPC, "long" is a 16-bit word.
> >
> >             p = 0x1000;
> >
> >             for (x = 10; x != 0; --x)
> >             {
> >                 *p = 0x1234;
> >                 ++p;
> >             }
> >
> >         In C, "incrementing" a pointer doesn't necessarily add 1 to
> >         it; rather, it adds the SIZE of the object to which the
> >         pointer points.  That is, if you have a pointer to a 10-byte
> >         structure at address 0, "incrementing" that pointer will make
> >         it point to address 10.
> >
> >         For "near" pointers (which MPC uses to point to addresses in
> >         the register space), pointer math works fine.
> >
> >         When math is performed on "far" pointers, however, MPC
> >         fails: In the "for" loop above, p is erroneously incremented
> >         by TWO at each iteration, since it's a pointer to a "long"
> >         and MPC doesn't realize that each location in the program
> >         space is SIXTEEN bits wide, not eight.
>
> I don't get it.  You are storing a 2 byte value at a pointer location, then
> incrementing the pointer.  If it only increments the pointer by one, or
> indeed any other number but two, the pointer will be pointing at the wrong
> location.  Maybe its a mis-understanding on my part of MPC, and its use of
> the far modifier, or ignorance of the 17xxx parts.  Can you do accesses to
> program space in them, unlike the 16cxx's?

> how do the various compilers handle negative numbers?  This
> question originally comes from a comment Andy Warren made a number
> of months ago regarding how the PIC doesn't really handle negative
> numbers.
> ....
> For example, say you were going to add -5 (which is defined as an 8
> bit byte) by 7 (which is defined as a 16 bit word) and put the
> result in a 16 bit word; what would your answer be?
>
> The [Parallax BASIC Stamp I] converts all parameters to sixteen
> bit values before executing an arithmetic opertor.
>
> So, -5 is actually 0x0FB (or $FB in PBASIC Speak), which is treated
> as 0x000FB when the add operator code is called.
>
> The result is 0x0102 ($102) and not 2 as logic would dictate.
> ....
> What do the PIC C Compilers do and is this where people have been
> saying you have to look at the actual output code to make sure
> issues like this are avoided?

> >         Unlike all other PICs, the 17Cxx parts allow reads
> >         and writes to the PROGRAM memory; in MPC, those
> >         program-space accesses are accomplished through the
> >         use of "far pointers".
> >
> > [example snipped]
> >
> >         When math is performed on "far" pointers, however,
> >         MPC fails: In the "for" loop above, p is erroneously
> >         incremented by TWO at each iteration, since it's a
> >         pointer to a "long" and MPC doesn't realize that each
> >         location in the program space is SIXTEEN bits wide,
> >         not eight.
>
> I don't get it.  You are storing a 2 byte value at a pointer
> location, then incrementing the pointer.  If it only increments the
> pointer by one, or indeed any other number but two, the pointer will
> be pointing at the wrong location.  Maybe its a mis-understanding on
> my part of MPC, and its use of the far modifier, or ignorance of the
> 17xxx parts.  Can you do accesses to program space in them, unlike
> the 16cxx's?

>> In its most-current incarnation (version 1.30d), MPC has very few
>> problems... The only code-generation bug that I've seen involves
>> "long far pointer" math on the 17Cxx parts:
>>
>>     Unlike all other PICs, the 17Cxx parts allow reads and
>>     writes to the PROGRAM memory; in MPC, those program-space
>>     accesses are accomplished through the use of "far pointers".
>>
>>     If you want to read or write the entire 16-bit word at a
>>     program-space address, you need to use "long" far
>>     pointers... To write 0x1234 to address 0x1000, for example,
>>
>>     The problem occurs when you try to perform any MATH on the
>>     pointer.  Let's say, for instance, that you want to fill 10
>>     contiguous locations with 0x1234... You'd probably do
>>     something like this:
>>
>>         long far *p;    // In MPC, "long" is a 16-bit word.
>>
>>         p = 0x1000;
>>
>>         for (x = 10; x != 0; --x)
>>         {
>>             *p = 0x1234;
>>             ++p;
>>         }
>>
>>     In C, "incrementing" a pointer doesn't necessarily add 1 to
>>     it; rather, it adds the SIZE of the object to which the
>>     pointer points.  That is, if you have a pointer to a 10-byte
>>     structure at address 0, "incrementing" that pointer will make
>>     it point to address 10.
>>
>>     When math is performed on "far" pointers, however, MPC
>>     fails: In the "for" loop above, p is erroneously incremented
>>     by TWO at each iteration, since it's a pointer to a "long"
>>     and MPC doesn't realize that each location in the program
>>     space is SIXTEEN bits wide, not eight.

> I don't get it.  You are storing a 2 byte value at a pointer location, then
> incrementing the pointer.  If it only increments the pointer by one, or
> indeed any other number but two, the pointer will be pointing at the wrong
> location.

> From: Andrew Warren <TakeThisOuTfastfwdRemoveME@spam@IX.NETCOM.COM>
> To: EraseMEPICLISTRemoveMEMITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Friday, 13 June 1997 07:48
>
> Mike Smith <spamPICLIST.....spamMITVMA.MIT.EDU> wrote:
>
> > > MPC seems to have its share of detractors, too.
>
> I replied:
>
> > Name one, Mike.
>
> and Mike replied:
>
> > Just have a look at the number of happy, satisfied customers for
> > MPLAB-C
>
>     Mike:
>
>     MPLAB-C is NOT the same as MPC.
>
>     MPC is Bytecraft Limited's compiler; MPLAB-C, Microchip's
>     compiler, is based on (and still almost identical to) a VERY old
>     version of MPC.
>

> > >         Unlike all other PICs, the 17Cxx parts allow reads
> > >         and writes to the PROGRAM memory; in MPC, those
> > >         program-space accesses are accomplished through the
> > >         use of "far pointers".
> > >
> > > [example snipped]
> > >
> > >         When math is performed on "far" pointers, however,
> > >         MPC fails: In the "for" loop above, p is erroneously
> > >         incremented by TWO at each iteration, since it's a
> > >         pointer to a "long" and MPC doesn't realize that each
> > >         location in the program space is SIXTEEN bits wide,
> > >         not eight.
> >
> > I don't get it.  You are storing a 2 byte value at a pointer
> > location, then incrementing the pointer.  If it only increments the
> > pointer by one, or indeed any other number but two, the pointer will
> > be pointing at the wrong location.  Maybe its a mis-understanding on
> > my part of MPC, and its use of the far modifier, or ignorance of the
> > 17xxx parts.  Can you do accesses to program space in them, unlike
> > the 16cxx's?
>
>     Um, yeah.  Re-read the first paragraph of my description of the
>     problem.
>
> > 0x1000 12 <- pointer starts here
> > 0x1001 34
> > 0x1002 12 <- pointer after one iteration
> > 0x1003 34
>
>     No... Since the 17Cxx program-memory is 16 bits wide, THIS is
>     what actually happens when the pointer's erroneously incremented
>     by two:
>
>         0x1000 1234 <-- pointer starts here
>         0x1001 0000
>         0x1002 1234 <-- pointer after one iteration
>         0x1003 0000
>

> >another day and test it for interactions guys.
> >
> >> Remember, C is not new and these compilers are a few years old. There
> >> really is no excuse.
> >>
> >
> >Windows is a few years old, and is, of course, bug free.  Windows is
> >written by an organisation with programmers numbered in  the 1000's  CCS
> >has 1, so the codebase size comparison is reasonable.
>
> Mike, I'm not sure if you're being facetious by this comment.

> not the thousands (what does that say about Windows...).  A small team is
> more aware of interactions (and is therefore able to avoid them).
>
> Such things as UNIX, Motif, and VisiCalc are examples of ground breaking
> software that was written by a small team or one person.
>
> This, of course, is no excuse for not thoroughly testing software in a
> logical/structured manner.  It also means that if there are few authors
> involved in the development of a piece of software are locked into what I
> call "the life and death relationship of software support" (ie you're
> supporting it until you die).
>
>

> arithmetic opertor.
>
> So, -5 is actually 0x0FB (or $FB in PBASIC Speak), which is treated as
> 0x000FB when the add operator code is called.
>
> The result is 0x0102 ($102) and not 2 as logic would dictate.
>
> Now, in my trusty Microsoft "C" Compiler on my PC, this can be done
> (defining the variables as "char" and "int) and the answer "2" will be
> produced.  But as I look at the code, a "CBW" (Convert Byte Word)
> instruction, which converts a byte (half register) into a signed word
> (sixteen bits or full register), is executed before the addition takes

>     However... MPC performs no special-case handling of the "long
>     far" pointers that it uses to access program-space memory; it
>     erroneously performs math on those pointers EXACTLY the same way
>     that it (correctly) performs math on the "near" pointers that are
>     used to access the register space.  That is, it increments
>     pointers to "longs" (16-bit objects) by TWO, not one, whether
>     they point to the 8-bit register space OR the 16-bit program
>     space.
>
>     By the way... "char far" pointers (pointers to 8-bit objects in
>     the program space) work fine; MPC stores chars one per address,
>     leaving 8 bits of each program-space memory location unused.

>
>Date:    Wed, 11 Jun 1997 06:56:46 +0200
>From:    Tjaart van der Walt <TakeThisOuTtjaartWASP.CO.ZA>
>Subject: Re: C-compilers for PIC
>
>John Payson wrote:
>>
>> > At 07:46 AM 6/9/97 -0500, you wrote:
>> > >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
>> > >doesn't have all those nasty limitations.  Want multi-dimensional arrays?
>> > >No problem!  Want more than two arguments for a function?  No problem!
>> >
>> > Want bugs? Want a new release every day?  Want operation and definition of
>> > "correct" changed apparently on a whim?  Don't want docs?
>> >
>> > And that's my short list.
>>
>> As a user of the CCS compiler, I will readily admit that the problems you
>> describe are indeed annoying.  On the other hand, compared with my MPLABC
>> experience I'd say CCS is pretty good (if you call tech support because
>> the compiler mis-evaluates an expression, would you rather get a response
>> of "Yeah, it has that problem.  We may fix that in a month or two," or
>> "Oops, that doesn't seem to work right.  I'll try to get it fixed by
>> tomorrow."
>
>Exactly! I've been bitchin' & moanin' for 8 @#%$%(&*%^&*% months about
>the
>^&(&%$*$$^ lack of %*&$&H:\pic\pic archive 2 working interupt service routine context
>saving
>code. I hacked some code from the Bytecraft compiler which worked
>perfectly.
>
>About two weeks ago a Mchip engineer noted that MPLAB-C now also
>features
>this code (at last).
>
>I tried Mchip's code yesterday, and it doesn't work (hahahahahahahaha).
>I had to use the hacked code for a '74 on a '64a. I am SICK, SICK, SICK of
>the lack of *ANY* (null, zero, nada, zip) support on MPLAB-C. If it was a
>freeware compiler, it would have been ok, but we paid (a lot of) good
>money for it.
>

>--
>Friendly Regards
>
>Tjaart van der Walt
>spamtjaartwasp.co.za
> _____________________________________________________________
>| Another sun-deprived R&D Engineer slaving away in a dungeon |
>|             WASP International  http://wasp.co.za           |
>|             GSM and GPS value-added applications            |
>|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
>|_____________________________________________________________|