Which PIC18 C Compiler?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
and C language, but I am struggling figure out the development tools to get.
Do you have any experience with the CCS compiler running with MPLAB and
ICD2? ($175 solution)

Thanks,
Talal



Re: Which PIC18 C Compiler?
Quoted text here. Click to load it
get.

Where I used to work we used the Hi-Tech compiler for the PIC18, and had
relatively few problems. The Microchip compiler was unusable. They have
probably improved it.

Leon
--
Leon Heller, G1HSM
http://www.geocities.com/leon_heller



Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

If you're going for C on the PIC18, the only professional-quality
solution is the IAR compiler.  It's expensive, but you get what you pay
for. Microchip's compiler lags it significantly on code density and
quality, and (IMHO) CCS takes too many liberties with the standard to
actually be called C. It's a C subset with some semantic differences and
some PIC-specific enhancements. This might not matter to you if you're
just using it instead of assembler to save the hassle of low-level
programming, but if you have any interest in migrating C code to/from
the PIC, IAR is the one and only choice.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

I respectfully disagree.  The Hitech C compiler for the PIC18 seems to
be professional and of very high quality.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it


It isn't proper C though, it gets the semantics of automatic variables
wrong (treats them like statics rather than allocating on the stack)
and you therefore can't write reentrant code with it. (At least, you
couldn't last time I looked).

Yes, it's a better product than CCS. But it's not a serious C compiler.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: Which PIC18 C Compiler?



Quoted text here. Click to load it

Actually Putting Variables on the stack is not a C requirement.  It is just
the most common implementation.
If you are writing reentrant code on a small 8 bit cpu, you are looking for
trouble (i.e. slow and big).
If you want pure ANSI C you will trade it for code size.
my $0.02



Re: Which PIC18 C Compiler?
Quoted text here. Click to load it



It is true that the C Standard does not require them to be on a stack.
But it does require that if they are declared with no linkage and
without the storage specifier "static", that they be of storage class
"automatic".  The standard further explains that if the block with which
the automatic variable is associated is entered recursively, a new
instance of the instance of the object is created each time.
(see ISO/IEC 9899:1999 (E) section 6.2.4 paragraphs 4 and 5)

If the Hitech compiler treats automatic variables as static, Pete is
correct that this violates the C standard.  I have not verified Pete's
claim.

Neil further wrote:
Quoted text here. Click to load it

That's a separate issue.  If you're writing code for an 8-bit CPU,
perhaps you should explicitly declare variables to be static, rather
than expecting the compiler to violate the C standard and do it for you.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

On further consideration, it seems like it would be nice to mark a
function declaration as being non-reentrant, so that the compiler is
allowed to treat automatic variables specially (but not necessarily the
same as static variables).  If the function *did* get called reentrantly,
all bets would be off.

Alternatively, a new storage class for local variables could be defined
to have that effect.

But it seems unlikely that the next version of the C standard would
include such an extension, since the committee is not focused on the
requirements of very small systems.

Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

You don't need a new storage class to do this. The compiler just needs to be
intelligent enough to analyse the code, determin that a function is not
reenterent and allocate locals accordingly. The problem with allocating
local variables off the stack is one of RAM re-use. If you have a large
number of functions each allocating its locals as static then your RAM
requirements grow considerably. The way to get around this is to make the
compiler more intelligent and get it to generate the locals on a static
stack. This way RAM is re-used between functions. The upside is that PIC
code runs a hell of a lot faster using a static stack than using a dynamic
(runtime) stack. The XCSB compiler does this but it is not a C compiler.

Regards
Sergio Masci



Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

The compiler doesn't really have enough information to deternine that.
Suppose you have a source file like this:

  extern void func1 (int c);

  static void func2 (int b)
  {
    int foo = b % 6;
    // do some stuff with foo
    func1 (foo - 7);
    // do some other stuff with foo
  }

  void func3 (int a)
  {
    func2 (a + 3);
  }

Even though func2() is declared static, and even though there is only a
single place that calls func2(), the compiler cannot determine whether it
can be called recursively because it has no way to know whether the
external func1() might call func3().  The best the compiler can do in
this case is decide that func2 *might* be called recursively, and thus
take the proper actions to guarantee that local variable foo meets the
defined semantics for the automatic storage class.  Typically this would
involve storing foo in a stack frame, or pushing it prior to the call
to func1() and restoring it afterward, though other mechanisms not
involving a stack could also be used.

If you restrict the program to a single compilation, or get the linker
involved, you can statically determine which functions are not recursively
called provided that you don't use function pointers.

The point of my suggestion is that the programmer generally has some idea
as to whether the function can be called recursively (though he or she may
be mistaken), and it is much easier for the programmer to provide a hint
to the compiler than for the compiler to figure it out.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

It does, but not when compiling a separate file. Classic C compilers
don't do much when sperately compiled files are linked, but that is
the moment such information is available. One more argument against
separate compilation for (small) embedded programs.




Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

snipped-for-privacy@voti.nl (Wouter van Ooijen (www.voti.nl)) writes:
Quoted text here. Click to load it

Yes, I explained that in my post if you'll read it carefully.  However,
in most non-trivial C programs there is some use of function pointers.
If a pointer to a function anywhere but at the leaves of the call graph
is stored, it is unlikely that the compiler can then prove that functions
that are not leaves are not called recursively.

I have yet to see any C compilation system for the PIC that does
interprocedural optimization, let alone optimization across multiple
source files, so the ability to provide hints to the compiler as I
suggested would still be useful.  Since it's unlikely to be adopted
as part of the C standard, a compiler vendor that wanted to do this
could provide it as an implementation-defined pragma.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

In a 1k-code microcontroller application you will be happy to
sacrifice the use of function pointers anb recursion for the benefit
of (much) compacter code.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

Re: Which PIC18 C Compiler?
On Mon, 12 Jul 2004 07:57:09 GMT, the renowned snipped-for-privacy@voti.nl (Wouter

Quoted text here. Click to load it

We are talking about the PIC18 though, which comes with up to
128K bytes of code memory/4K of RAM.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

I missed that. But not that not all 18F's are that fat.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

Yes but you still would not want to loose the advantage of the extra code
space by filling it with inefficient code, or the advantage of a faster
processor by giving it unnecessary code to execute.

Regards
Sergio Masci



Re: Which PIC18 C Compiler?
On Tue, 13 Jul 2004 15:21:32 GMT, the renowned "Sergio Masci"

Quoted text here. Click to load it

Ideally, I would like to have the choice, not to have a non-standard
limitation imposed that breaks existing C code.  

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

This is nonsense. You cannot conjure the address of a function out of thing
air. All functions that are invoked by a pointer to function are easily
identified. All function pointers are easily identified. The assignment of a
function address to a function pointer is easily identified. All function
pointers can be easily tracked at compile time. The only way the compiler
would loose track is if the execution path passed through some assembler
code or C code for which the source is not available AND the function
pointer is passed into that code by reference.

There is no way a function address can be computed using a mathematical
expression, you have to look them up. Yes I know you can load an object file
into a running program, locate functions by name and then execute them via a
function pointer BUT this is the same situation I mentioned above where the
compiler does not have access to the source and in any case you wouldn't be
doing this on a small embedded system.

Conclusion: the number of situations where a function cannot be proven to be
either reenterant or non-reenterent is increadibly small and would involve
increadibly complex function pointer manipulation. Such functions could be
treated as reenterant (or flagged by the compiler as being too complex)
while all the other functions in the system would be well defined and
treated accordingly.

Quoted text here. Click to load it

This is complete BS. On the one hand you talk about how things are not done
and on the other how things could be done. You use the argument that
existing compilers don't do blah blah to support your argument for not being
able to gather the information required and you use the argument for adding
new facilities to show how it can only be done your way. This is gibberish.
If you're going to modify a compiler you can make it do what you want. If
you're not going to modify it then what does this "hints" thing mean. Do you
intend shouting at the compiler to get it to do what you want?

Ok, lets say for the sake of argument that you implement this "hints" thing.
Are you going to make the compiler varify that the hint is valid or are you
going to blindly generate code that will crash because the hint is not
valid.?Are you going to analyse the generated code in some way to identify
how "hinted" variable RAM will be re-used or are you going to treat them
like static varaible are not bother with a static stack?

Wouter, Walter and I have all told you that you don't need this "hints"
thing, that all the info is there. Go back and think about how you would
solve the problems you think you have and then tell us why you think it is
impractical (forget impossible).

Regards
Sergio Masci




Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

No.  All functions that *might* be invoked by a pointer are identifiable.
But they are not necessarily identifiable through static analysis of
only the file defining those functions (unless the functions are declared
static).

Quoted text here. Click to load it

No.  I've got real-world examples in two IP router code bases I've
worked on at past jobs.

Quoted text here. Click to load it

The whole point of my suggestion was that the programmer may KNOW that
a particular function with never be called reentrantly, and could give
a hint to the compiler rather than relying on the compiler to possibly
figure it out.

Of course, if the programmer supplies a hint that is wrong, all bets
are off.

Quoted text here. Click to load it

I *never* said it can only be done my way.  I provided a reasonable
argument for why it might be desirable to do it the way I suggest,
though I stated outright that I thought it unlikely that my proposal
would be adopted (only because it doesn't benefit mainstream C users).

You can rant all day about how my idea is "complete BS", but such
ranting is not likely to convince anyone.

Quoted text here. Click to load it

Another very insightful and constructive bit of criticism.

    Truly you have a dizzying intellect.
              -- The Man in Black, "The Princess Bride",
                 screenplay by William Goldman

Quoted text here. Click to load it

Blindly generate code that may produce undesired results.  If the programmer
tells the compiler that it's allowed to do something, then the compiler
is allowed to do it.

    On two occasions I have been asked [by members of Parliament!], "Pray,
    Mr. Babbage, if you put into the machine wrong figures, will the right
    answers come out?' I am not able rightly to apprehend the kind of
    confusion of ideas that could provoke such a question."
              -- Charles Babbage

Of course, if the compiler can prove that the programmer is wrong, it
can ignore the hint and/or produce a compile time warning or error.  In
fact, the compiler can ignore the hint for any reason or none at all.
But if the programmer supplies the hint and the compiler chooses to act
on it, the programmer is responsible for the consequences.

Quoted text here. Click to load it

The compiler is allowed to use the hint to do any sort of optimization
that is guaranteed to still yield the defined C automatic storage class
semantics under the restriction that the function is not called
reentrantly.  The compiler could treat the variable as static, or it
could treat it as automatic, or it could do something else we haven't
thought of.  The C standard doesn't define a specific mechanism by which
an implmentation is required to implement the automatic storage class,
and similarly there is no reason why it would dictate an implementation
mechanism for the proposed hint.

Quoted text here. Click to load it

You have told me it is unnecessary but you have provided no evidence or
concrete argument to counter the code example I provided.  The most
coherent criticism of my proposal that you've managed to produce is the
claim that it is "complete BS".

Quoted text here. Click to load it

I stated myself that it is impractical because the C committee has no
motivation to add a feature that only benefits programmers of very small
embedded systems.

Other than that, speaking as someone who has actually written small
compilers (for special-purpose languages) I am fairly certain that there
is no particular reason why the proposal it is impractical from a
technical perspective.

Eric

Re: Which PIC18 C Compiler?
This is the very reason that we link the intermediate code from the compiler
and don't begin to do code generation until we know the entire structure of
the application. The other similar issue is pointers to functions.

Walter Banks
www.bytecraft.com

Eric Smith wrote:

Quoted text here. Click to load it


Site Timeline