Which PIC18 C Compiler?

In message <wpMIi.17907$c_1.3018@text.news.blueyonder.co.uk>, 
FreeRTOS.org <noemail@address.com> writes
>
>What makes a standard?  What a committee publishes but nobody uses, or what
>a large user base use, comply with, and expect to see?

Bloody good question!

>It is always amusing watching language 'gurus' cut their teeth in the
>embedded word, fall flat on their faces, then blame the compiler for not
>implementing the 'standard'.  They know which page of which standard a
>particular construct is described, but have no idea how to create an
>embedded system.  Which is the most useful skill?
>
>[expecting to be flamed]

Not my me!  I agree completely .

This is a major problem with some people on standards committees they 
have absolutely no industrial or embedded experience.




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

Chris Hills <chris@phaedsys.org> writes:
> Also GCC is OLD technology.
> 
> It looses out on 16 bit systems

As the author of the R8C/M16C/M32C port for gcc, I disagree.  Our
benchmarks and code comparisons show gcc's 16 bit port is similar to
Renesas's other compiler (the NC series), and the users agree, some
even claiming it produces better code for their application.

In addition, if you buy the 16-bit development kit from Microchip, it
*is* gcc.

Also, the gcc core is *constantly* undergoing improvements and
replacements to keep up with (or even invent) the latest technology.
I'm not sure how that qualifies as "old".

In message <xnejgsrth9.fsf@delorie.com>, DJ Delorie <dj@delorie.com> 
writes
>
>In addition, if you buy the 16-bit development kit from Microchip, it
>*is* gcc.
>

Do you get the source for it?


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

In message <xnejgsrth9.fsf@delorie.com>, DJ Delorie <dj@delorie.com>
writes
>
>Also, the gcc core is *constantly* undergoing improvements and
>replacements to keep up with (or even invent) the latest technology.
>I'm not sure how that qualifies as "old".

As I am involved in compiler validation and know several people who
validate and analyse compilers (all of whom are under NDA with  various
compiler companies)  I am being told with evidence that GCC is 5-10
years behind current compiler development. It does not "invent the
latest technology" far from it.


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

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:EpPLWiPVs98GFAg9@phaedsys.demon.co.uk...
> In message <xnejgsrth9.fsf@delorie.com>, DJ Delorie <dj@delorie.com> 
> writes
>>
>>In addition, if you buy the 16-bit development kit from Microchip, it
>>*is* gcc.
>>
>
> Do you get the source for it?

Naturally.  Otherwise their huge legal department would not be doing their 
job properly.

-- 
Regards,
Richard.

+ http://www.FreeRTOS.org
13 official architecture ports, 1000 downloads per week.

+ http://www.SafeRTOS.com
Certified by T&#4294967295;V as meeting the requirements for safety related systems. 

Chris Hills <chris@phaedsys.org> writes:
> >In addition, if you buy the 16-bit development kit from Microchip, it
> >*is* gcc.
> 
> Do you get the source for it?

Of course.  I have my copy.

In article <tiZx0HKMcn8GFAFU@phaedsys.demon.co.uk>, Chris Hills says...
> In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker 
> <rw@shadowrobot.com> writes
> >Chris Hills <chris@phaedsys.org> writes:
> >
> >>
> >> You will not get a fully  ISO C compliant compiler for the PIC. It's 
> >>architecture will not permit
> >> it.  You need to write C for the PIC not portable C is you want to 
> >>get any sort of efficiency out of
> >> it.
> >
> >Just out of interest, which bits of ISO C can't the PIC do?
> 
> Which ISO C?
> 
> This is not a trick question.

OK Chris, now you have me curious.  Your question implies that the 
standards differ in their requirements of the processor and that the PIC 
can meet at least some in one version but not another. Otherwise the 
question would be moot.  

So what are the differences that would place different requirements on 
the underlying processor that change whether or not the PIC can meet 
them?

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

In article <87y7f0peoc.fsf@cordelia.devereux.me.uk>, John Devereux 
says...
> Chris Hills <chris@phaedsys.org> writes:
> > The techniques used in modern embedded compilers are 5-10 years ahead
> > of GCC
> >
> > Also GCC has it's own standard, not ISO C.
> 
> Misleading (as usual). If you want to limit gcc to an ISO subset, you
> can easily choose that option when running the compiler, using
> e.g. -ansi, -std=c89, -std=c99 etc.
> 
> An uninformed reader might take your comment to mean gcc is not "good
> enough" to support ISO. In fact it is only *commercial* compilers that
> often cannot support ISO C. PIC, 8051 and Rabbit spring to mind.

Zworld's compiler for the Rabbit doesn't even support K&R, although 
Softools claims C90 support for their compiler for the Rabbit.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

In message <MPG.215e07c1bc89aeb09897c2@free.teranews.com>, Robert Adsett 
<sub2@aeolusdevelopment.com> writes
>In article <tiZx0HKMcn8GFAFU@phaedsys.demon.co.uk>, Chris Hills says...
>> In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker
>> <rw@shadowrobot.com> writes
>> >Chris Hills <chris@phaedsys.org> writes:
>> >
>> >>
>> >> You will not get a fully  ISO C compliant compiler for the PIC. It's
>> >>architecture will not permit
>> >> it.  You need to write C for the PIC not portable C is you want to
>> >>get any sort of efficiency out of
>> >> it.
>> >
>> >Just out of interest, which bits of ISO C can't the PIC do?
>>
>> Which ISO C?
>>
>> This is not a trick question.
>
>OK Chris, now you have me curious.  Your question implies that the
>standards differ in their requirements of the processor and that the PIC
>can meet at least some in one version but not another. Otherwise the
>question would be moot.

This is true. You will have to compare the PIC compiler specs, along 
with C99 and C90 to be specific.

C90 requires
15 levels of nesting ,
31  arguments in functions calls,
  32K bytes in an object  (I assume all PICS have more than 32K of code 
memory? )

127  members in a single union or structure.

etc etc

C99 different minimum constraints  all or which are equal or greater 
than C90 mot larger


>
>So what are the differences that would place different requirements on
>the underlying processor that change whether or not the PIC can meet
>them?

The standards have changed over the years.  The PIC compilers tend to 
adhere to C90  some to C95  not AFAIK to C99

There are many things due to the small physical constraints to the 
device you cant fit into a PIC

As has been mentioned re-entrancy is one, teh C99  long long is probably 
another, a lot of the maths would, I think be impossible to do.

Also I thin the PIC has extensions that are not part of the C standard.



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

On 2007-09-23, Chris Hills <chris@phaedsys.org> wrote:
> C90 requires
>   32K bytes in an object 

Not unless you consider the PIC to be a hosted environment.

> (I assume all PICS have more than 32K of code memory? )

No, some have 256 words.  The term "PIC" isn't really meaningful given
the broad range of PIC cores, including 16-bit parts with lots of RAM
and code space and a real stack.  But when people say "PIC" they are
usually referring to the 14-bit cores, which have a maximum of 8K
words of code space and 512 bytes of data memory.

-- 
John W. Temples, III