Which PIC18 C Compiler?

I've programmed PIC14 and PIC16 (and even a PIC12 once) in assembly - never in C. I guess it's a matter of personal taste, but I found PIC assembly particularly unpleasant compared to the dozen or so other assemblies I have used regularly. With a great deal of macros handling bank switching (amongst other things), along with aliases for things like the "btfsc" instruction (which roll off the tongue *so* easily), it was usable.

The PICs have plenty of nice features - their cpu is not one of them.

mvh.,

David

The 68k has always been my favourite too (as ColdFire these days).

Sorry, I didn't think about these (I always think of "PIC" as PIC12, PIC14 and PIC16 - possibly PIC18. I never had occasion to look at the newer, bigger PIC's more closely).

That's an important point. The C standards are a helpful reference, but since almost *no* compiler seems to implement all of any given standard, and none of the standards are sufficient for embedded programming, they are only an indication of language support. For example, if the compiler is approximately C99 compliant, you know you can mix declarations and statements in a function (if you thought that was a good idea...). And if you know you are sticking to gcc, it is safe to use gcc extensions (some of which can be very useful). The standards make life easier, but by no means easy, for writing cross-target code.

David,

My bias is well known in this area. One of the real advantages of a C compiler especially with PIC's is the compiler only has to get it right once :)

To follow up on a couple of your points. Memory management support can be a real pain both for compilers and asm programs. The compiler can track the current state of the RAM and ROM memory management and that helps. Some very interesting things start to happen when an application gets to almost filling the available ROM. As the ROM fills up the probability of an off page jump or call becomes higher and the application subsequently slows down.

The RAM memory management on a PIC is actually better than most. Some RAM has multiple forms of alaising that can be used by the compiler to reduce the amount required generated code to support it. The ROM memory management on the other hand requires preloading the memory management in eager anticipation that a conditional branch will branch and is followed by more code that is needed to restore ROM memory management in the case the condition fails. Some of these sequences have significant overhead.

The last point to comment on is PIC12 (or PIC10 series) that have both limited stack and no interrupt support. (There are other processors with a similar characteristics like the RS08). We started adding execution threads, execution that is triggered by some logical sequence. This approach flattens the structure of an application and statistically reduces subroutine return stack and off page references.

Regards

Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751

I found bank switching (for RAM and ROM) to be a pain - the PIC made most sense for really small programs which did not need any bank switching. But with some clever macros, I managed to get automatic setting of the bank select bits fairly optimal (erring on the side of caution). I still had to manually choose which function and which data goes in which bank, however - it's that kind of thing that your C compiler can do better than an assembly programmer in most cases (assuming the assembly program is going to be maintainable over time!).

I used to have macros for easy use of goto's instead of call/return pairs, as a way of saving stack space (and time and code space) for functions that were only ever called from one place (if the function is called from two places, I got a linker error). Again, a good compiler will go one step further and inline such functions, but it was possible to get by with macros and assembly.

I also once wrote a small program for an AVR Tiny which has a 3 level hardware stack and no RAM - the 32 8-bit registers was all the memory it had (along with some eeprom). I used avr-gcc - with a little care, such as specifying registers for global variables and avoiding any library code, it all worked out fine (including interrupt functions).

mvh.,

David

... snip ...

What I have done in the past is to run most of the time with interrups disabled. There is a master routine, which enables interrupts, then disables, allowing any interrupts to occur in that hole (which may be repeated). This means that the main code knows no interrupts will disturb it, and the full stack depth can be used. It also means that interrupt routines have to be short and leave flags for other routines to process. Proper execution also requires that the execution time of the main loop be well known, and limited.

A useful characteristic to annotate the source with is the maximum running time for a routine.

But none of those would appear to me to allow the the creation of a compiler for the PIC that would meet the constraint if using one version of the ISO standard but dissallow it for a different version. ISTM that all of these constraints fail regardless of version.

Well long long is a new addition but I don't see why it would be impossible to implement on a PIC. It might even be useful for some people.

Re-entrancy doesn't introduce different requirements from version to version does it though? I don't see that it qualifies as an answer.

True, but that's the case for extensions for all other processors as well. Nothing to do with what differences there are in the various versions of the standard that would enable a PIC to meet a constraint in one version but not another though and that is the question I asked.

Robert