Which PIC18 C Compiler?

In message <m3bqbxnnhw.fsf@shadow.org.uk>, Rich Walker 
<rw@shadowrobot.com> writes
>CBFalconer <cbfalconer@yahoo.com> writes:
>
>> Chris Hills wrote:
>>> 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.
>>
>> Yes it is.

I was thinking C89
C90
C90+A1
C95  (C90+A1 &TC's)
C95+
C99

>> Try just section 5.2.4.1 of the C99 standard.  For a
>> starter.

Are there any C99 compilers for a PIC?

>Isn't this the "we're assuming you've got 512KB of ram on the target"
>section?

:-)

How much memory on  a PIC.



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

In message <TnzIi.52037$rr5.17561@newsfe1-win.ntli.net>, Peter Harrison 
<peter_harrison@ntlworld.com> writes
>[heavily snipped]
>---8<---
>Chris Hills wrote:
>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho 
>><drwho@mailinator.com> writes
>>> otherwise use GCC
>>  Not a chance.
>>
>---8<---
>One of my maxims is "If you can't handle the answer - don't ask the 
>question". So, with some trepidation I ask...
>
>Why not? What is the problem with GCC?
>
>There, I have done it now.

Walter has given a good answer

Also GCC is OLD technology.

It can complete to a point on 32 bit systems,
It looses out on 16 bit systems
It can no compete in the 8 bit area.

The techniques used in modern embedded compilers are 5-10 years ahead of 
GCC

Also GCC has it's own standard, not ISO C.



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

In message <46f36a48$0$27840$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>FreeRTOS.org wrote:
>> "Peter Harrison" <peter_harrison@ntlworld.com> wrote in message 
>>news:TnzIi.52037$rr5.17561@newsfe1-win.ntli.net...
>>> [heavily snipped]
>>> ---8<---
>>> Chris Hills wrote:
>>>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho 
>>>><drwho@mailinator.com> writes
>>>>> otherwise use GCC
>>>> Not a chance.
>>>>
>>> ---8<---
>>> One of my maxims is "If you can't handle the answer - don't ask the 
>>>question". So, with some trepidation I ask...
>>>
>>> Why not? What is the problem with GCC?
>>>
>>> There, I have done it now.
>>>
>>> Pete
>>   For a start - there is no GCC implementation for the PIC18 that I 
>>am aware  of - although there is a good one for the PIC24 and dsPIC.
>>
>
>The original suggestion was to "use GCC with a real processor like and 
>(sic) AVR, MSP, or ARM7".

These MCU are no more or less real than PIC.

>> You can search this group for posts by Chris to see his opinion on GCC.
>>
>
>Chris has been known to post on reflex whenever he sees the three 
>letters "g", "c", and "c" together, at least in the context of small 
>microcontrollers.  Hence the reply apparently came *before* he'd read 
>to the end of the sentence.

Unlike your bias to "real processors"


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

Chris Hills <chris@phaedsys.org> writes:

> In message <TnzIi.52037$rr5.17561@newsfe1-win.ntli.net>, Peter
> Harrison <peter_harrison@ntlworld.com> writes
>>[heavily snipped]
>>---8<---
>>Chris Hills wrote:
>>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho
>>> <drwho@mailinator.com> writes
>>>> otherwise use GCC
>>>  Not a chance.
>>>
>>---8<---
>> One of my maxims is "If you can't handle the answer - don't ask the
>> question". So, with some trepidation I ask...
>>
>>Why not? What is the problem with GCC?
>>
>>There, I have done it now.
>
> Walter has given a good answer
>
> Also GCC is OLD technology.
>
> It can complete to a point on 32 bit systems,
> It looses out on 16 bit systems
> It can no compete in the 8 bit area.
>
> 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.

-- 

John Devereux

Chris Hills wrote:
> In message <46f36a48$0$27840$8404b019@news.wineasy.se>, David Brown 
> <david@westcontrol.removethisbit.com> writes
>> FreeRTOS.org wrote:
>>> "Peter Harrison" <peter_harrison@ntlworld.com> wrote in message 
>>> news:TnzIi.52037$rr5.17561@newsfe1-win.ntli.net...
>>>> [heavily snipped]
>>>> ---8<---
>>>> Chris Hills wrote:
>>>>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho 
>>>>> <drwho@mailinator.com> writes
>>>>>> otherwise use GCC
>>>>> Not a chance.
>>>>>
>>>> ---8<---
>>>> One of my maxims is "If you can't handle the answer - don't ask the 
>>>> question". So, with some trepidation I ask...
>>>>
>>>> Why not? What is the problem with GCC?
>>>>
>>>> There, I have done it now.
>>>>
>>>> Pete
>>>   For a start - there is no GCC implementation for the PIC18 that I 
>>> am aware  of - although there is a good one for the PIC24 and dsPIC.
>>>
>>
>> The original suggestion was to "use GCC with a real processor like and 
>> (sic) AVR, MSP, or ARM7".
> 
> These MCU are no more or less real than PIC.
> 

I was quoting the OP, not stating my own opinion.  I am well aware that 
the PIC is a "real" processor.  It is a horrible cpu architecture to 
work with (at least on the PIC16 and PIC14 which I have used), is 
severely limited, C-unfriendly, and has some of the least intuitive and 
most unpronounceable assembly opcodes I've come across, and I certainly 
don't like the cpu - but it's still a "real" processor, and is still 
useful for real work.

>>> You can search this group for posts by Chris to see his opinion on GCC.
>>>
>>
>> Chris has been known to post on reflex whenever he sees the three 
>> letters "g", "c", and "c" together, at least in the context of small 
>> microcontrollers.  Hence the reply apparently came *before* he'd read 
>> to the end of the sentence.
> 
> Unlike your bias to "real processors"
> 

I doubt if I am more free from bias than your average c.a.e. poster, but 
in this case you've simply misread my post.

Chris Hills wrote:
> In message <TnzIi.52037$rr5.17561@newsfe1-win.ntli.net>, Peter Harrison 
> <peter_harrison@ntlworld.com> writes
>> [heavily snipped]
>> ---8<---
>> Chris Hills wrote:
>>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho 
>>> <drwho@mailinator.com> writes
>>>> otherwise use GCC
>>>  Not a chance.
>>>
>> ---8<---
>> One of my maxims is "If you can't handle the answer - don't ask the 
>> question". So, with some trepidation I ask...
>>
>> Why not? What is the problem with GCC?
>>
>> There, I have done it now.
> 
> Walter has given a good answer

Walter gave a good answer regarding recursion in 8051 compilers, totally 
unrelated to gcc and/or sdcc (since there is no gcc port for the 8051).

> 
> Also GCC is OLD technology.
> 

We've been through this before.  There are certainly some optimisations 
that gcc does not currently support which good commercial embedded 
compilers *do* support.  In particular, there is only limited support 
for whole-program optimisations, and link-time optimisations are still 
under development.  These are very relevant to small 8-bit compilers, 
but much less so for large 32-bit systems (which we all agree is gcc's 
main target area).

> It can complete to a point on 32 bit systems,

On many 32-bit systems, it is the standard (and sometimes the only) 
compiler.  Of course, there is plenty of variation according to the 
specific target - there are many different 32-bit cpus.  But in my 
experience on ColdFire's and PPC's, it has generated similar to or 
better than the few commercial compilers I have seen.

> It looses out on 16 bit systems

The 16-bit market is very small - there is the msp430 (for which the gcc 
port is perfectly good, but based on a rather old version of gcc and 
therefore missing many recent improvements), some Freescale devices (I 
don't know if there is a gcc port there), and various devices from the 
far east (again, I don't know about gcc there).

> It can no compete in the 8 bit area.
> 

There is only one serious 8-bit target for gcc, and that's the AVR.  The 
port is good, and generates good code.  It's not perfect, and I'm sure 
that the biggest and best commercial compilers still generate tighter 
code.  But avr-gcc is close enough to be perfectly good for serious 
professional work - that's why Atmel support it.

> The techniques used in modern embedded compilers are 5-10 years ahead of 
> GCC
> 

No - some commercial compilers have some techniques that gcc does not 
use, and some of these techniques may have been in use for years.  There 
is a big difference here - there is no doubt that for example Byte Craft 
use optimisation and compilation techniques that are well beyond what 
gcc can do at the moment.  But that does not imply that gcc is 
equivalent to a 5 or 10 year old embedded compiler!

No one would (sensibly) expect a hypothetical 8051 gcc port to compete 
with Byte Craft's in quality of code - such a device needs the type of 
optimisation that Byte Craft specialise in in order to get the best from 
it.  But on the other hand, I would not except Byte Craft to be able to 
port their compiler to an Intel Core Duo and get the same speed as gcc, 
without an enormous amount of effort.  gcc's awareness of cache 
locality, pipeline stalls, vectorisation, and other such things are 
years ahead of Byte Craft's - simply because these are relevant to gcc's 
main targets, but irrelevant to Byte Craft's.

Devices like the AVR fall somewhere in between most small cpus and 
32-bit devices in terms of suitability of a gcc port - thus the port is 
pretty good, but not as tight as is theoretically possible.


Finally, in all this discussion, you are missing out the concept of 
"good enough".  Suppose that, say, IAR's AVR compiler generates 20% 
smaller and faster code than avr-gcc.  So what?  For some projects, 
that's relevant - if it means a large production run can use a smaller 
flash then you have saved a lot of money.  But for many commercial 
developments, it's not going to make a big difference.  Similarly, even 
if we guess that Keil's 8051 compiler is twice as good as sdcc, there 
are still plenty of professional projects where that is not a problem. 
Of course, there may be other issues involving development time, 
debugger support, reliability, or certification - I haven't used sdcc, 
and can't comment there.

> Also GCC has it's own standard, not ISO C.
> 

gcc supports the C standards to a similar degree to most commercial 
compilers - i.e., it seldom has 100% compliance, is generally late in 
reaching almost-complete compliance, and it has its own extensions. 
What is unusual about gcc is that it has more extensive extensions than 
many other compilers (in the interests of generating better code, or 
allowing higher quality source code).  Many of these extensions 
pre-dated newer C standards (such as some crosses between C and C++), 
and many have later been copied by other compilers.

>> It looses out on 16 bit systems
>
> The 16-bit market is very small - there is the msp430 (for which the gcc 
> port is perfectly good, but based on a rather old version of gcc and 
> therefore missing many recent improvements), some Freescale devices (I 
> don't know if there is a gcc port there), and various devices from the far 
> east (again, I don't know about gcc there).

I'm repeating myself here just for the record - but the PIC24 and dsPIC 
(16bit devices) have a good GCC port.


> No - some commercial compilers have some techniques that gcc does not use, 
> and some of these techniques may have been in use for years.  There is a 
> big difference here - there is no doubt that for example Byte Craft use 
> optimisation and compilation techniques that are well beyond what gcc can 
> do at the moment.  But that does not imply that gcc is equivalent to a 5 
> or 10 year old embedded compiler!

<snip>

This has been discussed add infinitum.


>> Also GCC has it's own standard, not ISO C.


What makes a standard?  What a committee publishes but nobody uses, or what 
a large user base use, comply with, and expect to see?

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]

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

David Brown wrote:
> 
... snip ...
> 
> I was quoting the OP, not stating my own opinion.  I am well aware
> that the PIC is a "real" processor.  It is a horrible cpu
> architecture to work with (at least on the PIC16 and PIC14 which I
> have used), is severely limited, C-unfriendly, and has some of the
> least intuitive and most unpronounceable assembly opcodes I've
> come across, and I certainly don't like the cpu - but it's still a
> "real" processor, and is still useful for real work.

While it may be horrible for C, it is quite natural and useful for
assembly language.  Which, considering the size of applications
that can be handled, is the appropriate language for these chips. 
But don't expect to use a clone of other popular chips assembly
language.  This is about PIC14 and PIC16.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



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

Chris Hills wrote:
> Peter Harrison <peter_harrison@ntlworld.com> writes
>
... snip ...
>
>> Why not? What is the problem with GCC?
>>
>> There, I have done it now.
> 
> Walter has given a good answer.  Also GCC is OLD technology.
> 
> It can complete to a point on 32 bit systems,
> It looses out on 16 bit systems
> It can no compete in the 8 bit area.
> 
> The techniques used in modern embedded compilers are 5-10 years
> ahead of GCC.  Also GCC has it's own standard, not ISO C.

"gcc -W -Wall -ansi -pedantic" is an ISO C90 compiler. 
Modifications to "-ansi" make it a slightly incomplete C99
compiler.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>


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

In message <46f383bf$0$27835$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Chris Hills wrote:
>> In message <46f36a48$0$27840$8404b019@news.wineasy.se>, David Brown 
>><david@westcontrol.removethisbit.com> writes
>>> The original suggestion was to "use GCC with a real processor like 
>>>and  (sic) AVR, MSP, or ARM7".
>>  These MCU are no more or less real than PIC.
>>
>
>I was quoting the OP, not stating my own opinion.  I am well aware that 
>the PIC is a "real" processor.  It is a horrible cpu architecture to 
>work with (at least on the PIC16 and PIC14 which I have used), is 
>severely limited, C-unfriendly, and has some of the least intuitive and 
>most unpronounceable assembly opcodes I've come across, and I certainly 
>don't like the cpu - but it's still a "real" processor, and is still 
>useful for real work.

Can't disagree there.  However the problems with the architecture mean 
you really have to look at the compiler manual not K&R to program it 
efficiently.

Personally I still love the 68K


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