Which PIC18 C Compiler?

In message , Peter Harrison writes

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.

These MCU are no more or less real than PIC.

Unlike your bias to "real processors"

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.

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.

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.

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

This has been discussed add infinitum.

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?

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

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

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.

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

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.

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

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.

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.

... snip ...

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.

... snip ...

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

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

In message , FreeRTOS.org writes

Bloody good question!

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.

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

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 , DJ Delorie writes

Do you get the source for it?

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

In message , DJ Delorie writes

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

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

Of course. I have my copy.

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

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

Robert

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

C90 requires

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

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.

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

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.