We've got a project for a 18F6527 that will be using the Microchip TCP/IP
stack with Microchip's ENC28J60 MAC/PHY. The customer has previously used
the HiTech C compiler. We were planning on using that for the TCP/IP stack
and some higher level control and assembler for some lower level stuff
including task management and the associated unnatural acts it will perform
on the stack.

Unforatunately it turns out that HiTech is not compatible with the MPLAB
tools. They have their own assembler and linker, and it seems there is no
way for the compiler to produce either MPASM source or object files
compatible with MPLINK. This means the large amount of existing assembler
we were planning on using is inaccessible.

So the question is, is C18 up to the job? A bunch of years ago C18 was
definitely behind, and I even had Microchip people tell me the HiTech
compiler was better. This lingering feeling is why the customer got HiTech
in the first place, not knowing about the incompatibilities with
MPASM/MPLINK. It's been a bunch of years, and Microchip could well have
made C18 better by now. Does anyone have experience with both? Anyone
found pitfalls in C18? Unless there is a good reason not to, we would like
to switch to C18 (the cost of the compiler isn't a big deal, and we get a
big discount we can pass on to the customer anyway). The TCP/IP stack is
specifically supported on both compilers, so that's not an issue either.

On 1/27/06, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTembedinc.com> wrote:
>
> Unforatunately it turns out that HiTech is not compatible with the MPLAB
> tools. They have their own assembler and linker, and it seems there is no
> way for the compiler to produce either MPASM source or object files
> compatible with MPLINK. This means the large amount of existing assembler
> we were planning on using is inaccessible.
>
> So the question is, is C18 up to the job? A bunch of years ago C18 was
> definitely behind, and I even had Microchip people tell me the HiTech
> compiler was better. This lingering feeling is why the customer got HiTech
> in the first place, not knowing about the incompatibilities with
> MPASM/MPLINK. It's been a bunch of years, and Microchip could well have
> made C18 better by now. Does anyone have experience with both? Anyone
> found pitfalls in C18? Unless there is a good reason not to, we would like
> to switch to C18 (the cost of the compiler isn't a big deal, and we get a
> big discount we can pass on to the customer anyway). The TCP/IP stack is
> specifically supported on both compilers, so that's not an issue either.
>

I used Hitech PICC (for PIC16C/16F) before and I think it is very good. I do
not have much experience with Hitech PICC 18 though. Therefore I can only
tell you the opinions of some people I know. I think C18 is not bad but I
have not used it in production.

It is said that PICC18 is better than C18 according to one of my colleague.
He used C18 for a research project using 18F4620 and told me C18 is junk
compared to Renesas M16C C (he has experience with M16C) . He told me
the major problem is the quality of the C18 library.

I got the impressions from other users that PICC18 is still much better in
terms of code generation quality. It is said that dsPICC is not as good as
C30 though.

I think in your case, you can always use C18 and replace those bad
codes with your own assembly since you know the assembly very well.
And I think the Hitech assembly is not that different from MPASM.

> Unforatunately it turns out that HiTech is not compatible with the MPLAB
> tools. They have their own assembler and linker, and it seems there is no
> way for the compiler to produce either MPASM source or object files
> compatible with MPLINK. This means the large amount of existing assembler
> we were planning on using is inaccessible.

Are you sure about this? I'm not a C person so I may be talking through my hat, but in MPLAB you can point it
to the Hitech PICC toolsuite (and PICC-18), in "Registered Tools" under Project / Set Language Tool Locations.
This imples to me that it is compatible with MPLAB - otherwise what's the point of pointing to it?

>-----Original Message-----
>From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu]
>Sent: 27 January 2006 16:44
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] C18 versus HiTech compiler?
>
>
>Olin,
>
>On Fri, 27 Jan 2006 09:23:49 -0500, Olin Lathrop wrote:
>
>> Unforatunately it turns out that HiTech is not compatible with the
>> MPLAB tools. They have their own assembler and linker, and it seems
>> there is no way for the compiler to produce either MPASM source or
>> object files compatible with MPLINK. This means the large amount of
>> existing assembler we were planning on using is inaccessible.
>
>Are you sure about this? I'm not a C person so I may be
>talking through my hat, but in MPLAB you can point it
>to the Hitech PICC toolsuite (and PICC-18), in "Registered
>Tools" under Project / Set Language Tool Locations.
>This imples to me that it is compatible with MPLAB - otherwise
>what's the point of pointing to it?

That just means MPLAB knowns about the HiTech command line options etc. Olin is saying that the HiTech assembler and linker are not compatible with the HiTech tools, i.e. you cannot use MPLINK to link some MPASM and HiTech object files. The HiTech assembler syntax is also somewhat different to the MPASM syntax.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

> Olin,
>
> On Fri, 27 Jan 2006 09:23:49 -0500, Olin Lathrop wrote:
>
> > Unforatunately it turns out that HiTech is not compatible with the MPLAB
> > tools. They have their own assembler and linker, and it seems there is no
> > way for the compiler to produce either MPASM source or object files
> > compatible with MPLINK. This means the large amount of existing assembler
> > we were planning on using is inaccessible.
>
> Are you sure about this? I'm not a C person so I may be talking through my hat, but in MPLAB you can point it
> to the Hitech PICC toolsuite (and PICC-18), in "Registered Tools" under Project / Set Language Tool Locations.
> This imples to me that it is compatible with MPLAB - otherwise what's the point of pointing to it?
>
> Cheers,
>
>
> Howard Winter
> St.Albans, England
>
>

Howard Winter wrote:
> Are you sure about this? I'm not a C person so I may be talking
> through my hat, but in MPLAB you can point it to the Hitech PICC
> toolsuite (and PICC-18), in "Registered Tools" under Project / Set
> Language Tool Locations. This imples to me that it is compatible with
> MPLAB - otherwise what's the point of pointing to it?

Yes, it's compatible with MPLAB. That's how the customer builds and debugs
now. The issue however is not MPLAB compatibility, but MPASM/MPLINK. I
have looked thru the PICC 18 docs, and they have their own assembler (with
different enough syntax to be a pain), their own object file format, and
their own linker. I don't see any way of mixing MPASM and PICC 18 code in
the same project. If anyone has actually done this, I'd really like to hear
how.

It hadn't occurred to me that any compiler vendor would be so brain dead as
to make their suite incompatible with MPASM/MPLINK, but apparently HiTech
is. Please show me I'm wrong.

> Unforatunately it turns out that HiTech is not compatible with the MPLAB
> tools. They have their own assembler and linker, and it seems there is
> no way for the compiler to produce either MPASM source or object files
> compatible with MPLINK. This means the large amount of existing
> assembler we were planning on using is inaccessible.

Maybe there's a reasonably simple way to make your MPASM sources compatible
with HiTech (rather than the other way round, which is what you seem to
have been looking into)?

The reason I'm suggesting this is that usually, when integrating assembler
with C code, there is some work to be done anyway, even when the assembler
and linker are the same. The assembler modules need to conform to the
compiler's calling (and sometimes linking) conventions. There are a few
different ways to achieve that, but all of them usually require at least
some massaging of the assembler code.

So it may be that when considering this (which would be required for either
compiler), adapting your existing assembler code to properly assemble and
link with HiTech's assembler and linker may turn out to not be that much
extra work.

2006/1/27, Olin Lathrop <EraseMEolin_piclistspam_OUTTakeThisOuTembedinc.com>:
> Unforatunately it turns out that HiTech is not compatible with the MPLAB
> tools. They have their own assembler and linker, and it seems there is no
> way for the compiler to produce either MPASM source or object files
> compatible with MPLINK. This means the large amount of existing assembler
> we were planning on using is inaccessible.

I am a stranger when talking about Hi-Tech compiler, but the last time
I read through their documentation, I think I read something about
PICC uses "compiled stack". Well I might be wrong here but I really
get the felling that it would prevent any chance to mix-languages
programming. I think I was at the same position as you're now: to
select one from Microchip C18 and Hi-Tech PICC. The custom linker
tool of the latter made me picked my choice - C18 then stand better
for me.

> So the question is, is C18 up to the job? A bunch of years ago C18 was
> definitely behind, and I even had Microchip people tell me the HiTech
> compiler was better.

I can't tell on this one because I am not familiar with Hi-tech
compiler. But I guess all those comparison were made with a pure C
project, I mean not a mix-language project. Probably Hi-Tech is doing
'brightly' because of their custom linker tool. In some cases like you
want a mix-language project, I think the custom linker tool might be
disadvantageous - perhaps nearly make it impossible to reuse your
existing asm code.

I might be wrong on the Hi-tech opinion. I would be happily be
corrected if I am wrong. But I would say this: I am doing
mix-language project comfortably with C18!

> This lingering feeling is why the customer got HiTech
> in the first place, not knowing about the incompatibilities with
> MPASM/MPLINK. It's been a bunch of years, and Microchip could well have
> made C18 better by now.

Had you ever thought that this "brain dead" vendor already had a well defined and implemented toolset in existance for many other targets which was retained when then they introduced their PIC compilers? Why on earth would they suddenly want to break compatibility with the rest of their tools just for one micro family?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

On Fri, 2006-01-27 at 09:23 -0500, Olin Lathrop wrote:
> So the question is, is C18 up to the job? A bunch of years ago C18 was
> definitely behind, and I even had Microchip people tell me the HiTech
> compiler was better. This lingering feeling is why the customer got HiTech
> in the first place, not knowing about the incompatibilities with
> MPASM/MPLINK. It's been a bunch of years, and Microchip could well have
> made C18 better by now. Does anyone have experience with both? Anyone
> found pitfalls in C18? Unless there is a good reason not to, we would like
> to switch to C18 (the cost of the compiler isn't a big deal, and we get a
> big discount we can pass on to the customer anyway). The TCP/IP stack is
> specifically supported on both compilers, so that's not an issue either.

My experience with C18 isn't very vast, but so far I've encountered zero
problems with the compiler itself.

I have encountered some issues with the peripheral libraries, but my
solution to that was to simply write my own routines! :) I'm so used to
the PIC peripherals that writing my own routines was far easier then
trying to figure out what was going wrong with what I was trying to do.

Considering your experience level I see zero chance you'd have a problem
creating your own peripheral routines, so I don't think you'll have a
problem.

> It hadn't occurred to me that any compiler vendor would be so brain dead
> as to make their suite incompatible with MPASM/MPLINK, but apparently
> HiTech is. Please show me I'm wrong.

You are right (with the incompatibility). Whether that's "brain dead" is
another question. Maybe there are some features in their assembler/linker
that the Microchip combo doesn't support?

If you look at it from the HiTech angle, there may be other concerns that
play a role. For example the fact that they make compilers for a number of
micros -- there may be some internal code sharing that may have contributed
to their (at least once) leading role.

I think that for most users this incompatibility is not really a biggie --
compared with moving to C. Once you decide to use a C compiler, you tend to
use less and less assembler. For the asm routines you use, you have to
rewrite their interface in any case (even with a compiler that uses
MPASM/MPLINK), to satisfy the C compiler's calling conventions -- the
additional work to adapt it to HiTech C may not be that much more. Have you
looked at what you would have to do with C18?

>>It hadn't occurred to me that any compiler vendor would be so
>>brain dead as to make their suite incompatible with
>>MPASM/MPLINK, but apparently HiTech is. Please show me I'm wrong.
>
> Olin please *think* before writing, as you often advise others to do.
>
> Had you ever thought that this "brain dead" vendor already had a well
> defined and implemented toolset in existance for many other targets which
> was retained when then they introduced their PIC compilers? Why on earth
> would they suddenly want to break compatibility with the rest of their
> tools just for one micro family?
>

I'd like to add a little history to this. Hi-Tech was making pic compilers
before MPLAB supported relocatable code. They had no reason to break from
their way of doing things. So there's no way anyone could find fault with
Hi-Tech here - actually more reason to find fault with Microchip for not
following Hi-Tech's way of doing things when the time came to bring MPLAB
up to date.

But really, it doesn't matter. It'll be easier for Olin to use C18 because
he has lots of code that won't need to be altered very much.

> My experience with C18 isn't very vast, but so far I've
> encountered zero problems with the compiler itself.
> I have encountered some issues with the peripheral libraries, but my
> solution to that was to simply write my own routines!

Same with me. Note that de default for parameters and local variables is
'on stack', which is re-enetrant but consumes a lot of code space and
cpu time.

> WH Tan wrote:
>> I recalled that I asked a hi-tech fun about the possibility to do
>> mix-language with Hi-Tech. The answer I got was: you'll never need asm
>> with Hi-Tech.
>
> Hmm. I don't know if that is "if you can't fix it, feature it.", or just
> plain arrogance. Either way it doesn't say much for HiTech.

Doesn't say much at all. Not sure if I would base any decision on what an
anonymous "fan" says, even if it's wrong... :)

Just for the record: You can mix asm with C just fine with HiTech. As you
know, they do have an assembler and a linker, and both seem not to be less
capable than Microchip's tools. You can write assembler files, assemble
them and link them in. You can also embed assembler sections or single
assembler commands in your C code.

That all is pretty plain standard with C compilers, and not different at
all than with many others, and I assume pretty similar to how C18 does it.
Just the tool set is a different one, and that may be the decisive point
here. (Well, that or the opinion of an anonymous "fan" :)

Well Olin, I was talking specifically to your goal - a mix language
project. I think the most important point in the mix language project
is a well documented calling convention, which I think the C18
developers did it well.

>
> Hmm. I don't know if that is "if you can't fix it, feature it.", or just
> plain arrogance. Either way it doesn't say much for HiTech.

I think he meant he didn't know it and didn't need to learn it anyway.
Perhaps I shouldn't say it at all.

> Same with me. Note that de default for parameters and local variables is
> 'on stack', which is re-enetrant but consumes a lot of code space and
> cpu time.

That is not a limitation actually. You can code your function
non-reentrant and had all data allocated globally. If you have void
function(void), the only instruction generated is "call function".
But if a compiler doesn't support re-reentrant, you'll find yourself
have a hard job when you really need it. Though I am not saying this
is the case for HiTech PICC18. But the term "compiled stack" sounds
like something in the middle.

> Doesn't say much at all. Not sure if I would base any decision on what an
> anonymous "fan" says, even if it's wrong... :)

Hi,

I think I should not make those comment without put in my own view.
Actually I was asking about how to mix asm and C with hi-tech, but I
bet the answer I got was actually refer to he didn't know and didn't
need it anyway, or didn't bother to figure it out.

> Just for the record: You can mix asm with C just fine with HiTech. As you
> know, they do have an assembler and a linker, and both seem not to be less
> capable than Microchip's tools. You can write assembler files, assemble
> them and link them in. You can also embed assembler sections or single
> assembler commands in your C code.
>
> That all is pretty plain standard with C compilers, and not different at
> all than with many others, and I assume pretty similar to how C18 does it.
> Just the tool set is a different one, and that may be the decisive point
> here. (Well, that or the opinion of an anonymous "fan" :)

I believe so. My comment is a bit harsh as I know little about
Hi-Tech compiler.

On the other hand, C18 uses a "real stack", something similar to the
x86 processor - a stack pointer + a frame pointer to access locals and
parameters. And one of my goal is same as Olin's - reuse existing
ASM without much pain rework. That all made me believe that C18 suits
me better.

On Sat, 2006-01-28 at 09:42 +0100, Wouter van Ooijen wrote:
> > My experience with C18 isn't very vast, but so far I've
> > encountered zero problems with the compiler itself.
> > I have encountered some issues with the peripheral libraries, but my
> > solution to that was to simply write my own routines!
>
> Same with me. Note that de default for parameters and local variables is
> 'on stack', which is re-enetrant but consumes a lot of code space and
> cpu time.

Ahh, thanks, that also reminds me of another thing that I didn't expect:
integer promotion is NOT enabled by default. I'm not sure if PIC
compilers for smaller parts enable it by default, I just know I was
surprised it wasn't enabled.

>> You can code your function non-reentrant and had all data allocated
>> globally. [...] But the term "compiled stack" sounds like something in
>> the middle.
>
> I don't know what you meant by that. A 'compiled stack' (I prefer the
> term 'static stack') is what most 14-bit core compilers do. Compact code
> and fast, but not reentrant.

A compiled stack is significantly different from allocating data globally.
Globally allocated data occupies space always; data on the compiled stack
occupies data only when needed.

On 1/27/06, Olin Lathrop <spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote:
> We've got a project for a 18F6527 that will be using the Microchip TCP/IP
> stack with Microchip's ENC28J60 MAC/PHY. The customer has previously used
> the HiTech C compiler. We were planning on using that for the TCP/IP stack
> and some higher level control and assembler for some lower level stuff
> including task management and the associated unnatural acts it will perform
> on the stack.

I just downloaded the TCP/IP stack fro ENC28J60 and it is interesting to
know that C18 actually generates smalle hex file than PICC 18. This
does not necessarily mean C18 is better than PICC18 but it seems to
me that C18 is a better choice for your case since this stack may be
more optimized for MPLAB C18 than HiTech PICC18.

> It hadn't occurred to me that any compiler vendor would be so brain dead as
> to make their suite incompatible with MPASM/MPLINK, but apparently HiTech
> is.

I can understand your frustration but this comment is just so wrong.

Brain dead would be blindly following everyone else without looking at the
benefits of doing things another way. Brain dead would be to accept the
limitations of old technology without taking advantage of new improvements
in hardware (PC) speed and memory capacity.

Speaking as someone you would label as a brain dead compiler vendor, my
non-MPASM assembler generates debug info which is incompatible with
MPASM, MPLINK and MPSYM and as a consequence my simulator can detect
invalid register access (RP0 and RP1 set incorrectly when a register is
accessed). There are MANY other things that my XCASM assembler can do that
MPASM cannot.

> I think that for most users this incompatibility is not really a biggie --
> compared with moving to C. Once you decide to use a C compiler, you tend to
> use less and less assembler. For the asm routines you use, you have to
> rewrite their interface in any case (even with a compiler that uses
> MPASM/MPLINK), to satisfy the C compiler's calling conventions -- the
> additional work to adapt it to HiTech C may not be that much more. Have you
> looked at what you would have to do with C18?

Another aspect of using seperate assembler modules and inline assembler
statements is that you are reducing the compilers ability to understand
what you are trying to do and consequently hampering the compiler's
ability to optimise your code.

There are situations where a compiler can adapt its calling conventions to
suit the context of the call and the function being called. In some
cases it could reduce the call to a few inline instructions eliminating
the call overhead and a seperate function body. In other cases it can
eliminate the need to pass parameters at all. You kill this ability if you
hard code a function in assembler.

> On 1/27/06, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com> wrote:
> > We've got a project for a 18F6527 that will be using the Microchip TCP/IP
> > stack with Microchip's ENC28J60 MAC/PHY. The customer has previously used
> > the HiTech C compiler. We were planning on using that for the TCP/IP stack
> > and some higher level control and assembler for some lower level stuff
> > including task management and the associated unnatural acts it will perform
> > on the stack.
>
> I just downloaded the TCP/IP stack fro ENC28J60 and it is interesting to
> know that C18 actually generates smalle hex file than PICC 18. This
> does not necessarily mean C18 is better than PICC18 but it seems to
> me that C18 is a better choice for your case since this stack may be
> more optimized for MPLAB C18 than HiTech PICC18.
>

Are the PICC18 hex files pure intel hex or do they contain other info? Are
the hex formats the same? I remember some time ago someone asking about
determining the size of an executable by looking at the size of the hex
file AND someone else jumping on him for this.

Not the Intel hex files, at least not to my knowledge. I don't think they
/can/ contain other info, can they?

> I remember some time ago someone asking about determining the size of an
> executable by looking at the size of the hex file AND someone else
> jumping on him for this.

I'm not sure, but I don't think there's a clear relationship between the
size of a hex file and the size of the executable. AFAIK the hex file could
contain one byte per line (hex file rather big) or the executable could
contain "holes" (hex file relatively smaller than for an executable without
holes).

> sergio masci wrote:
>
> > Are the PICC18 hex files pure intel hex
>
> Yes, they can be. (Supports other formats, too.)
>
> > or do they contain other info?
>
> Not the Intel hex files, at least not to my knowledge. I don't think they
> /can/ contain other info, can they?

I don't know if it's legal but I have seen it done. Since each record has
a start of record indicator (the ':' char which must be the first char on
a new line), a record length and a checksum, anything outside a valid
record can either be treated as noise to be ignored or a fault condition.
I'm not sure what the "official" spec says.

>
> > I remember some time ago someone asking about determining the size of an
> > executable by looking at the size of the hex file AND someone else
> > jumping on him for this.
>
> I'm not sure, but I don't think there's a clear relationship between the
> size of a hex file and the size of the executable. AFAIK the hex file could
> contain one byte per line (hex file rather big) or the executable could
> contain "holes" (hex file relatively smaller than for an executable without
> holes).

Also, many years ago there was a programming language called PL9 for the
6809. There was a "one pass" compiler for this that generated motorola hex
files (S19) and it would add "address fixes" to the end of the hex file.

On 1/31/06, Gerhard Fiedler <RemoveMElistsTakeThisOuTconnectionbrazil.com> wrote:
> > I remember some time ago someone asking about determining the size of an
> > executable by looking at the size of the hex file AND someone else
> > jumping on him for this.
>
> I'm not sure, but I don't think there's a clear relationship between the
> size of a hex file and the size of the executable. AFAIK the hex file could
> contain one byte per line (hex file rather big) or the executable could
> contain "holes" (hex file relatively smaller than for an executable without
> holes).
>

In the case of MPLAB C18 and HiTech PICC18, both create rather similar
format of hex files (most lines contain 16bytes of program memory). In
fact most of the Microchip tools are doing the same thing.

I should have mentioned the real program memory usage than the hex
file size though. From the map file, it is really true that MPLAB C18
generates smaller hex file than HiTech PICC 18 in this paticular case.
That is why I think this stack is rather optimized for MPLAB C18.

>
> I should have mentioned the real program memory usage than the hex
> file size though. From the map file, it is really true that MPLAB C18
> generates smaller hex file than HiTech PICC 18 in this paticular case.
> That is why I think this stack is rather optimized for MPLAB C18.

Is this version of PICC18 an eval or full version?

Also, do you know if PICC18 is using the new FSR2 relative addressing mode
to compile this program (maybe this is a compiler option)?

Microchip supplied the hex files for both C18 and PICC18. I
do not have the PICC 18 compiler but my friend confirmed that
full version of PICC18 (something like 8.35PL1) produced the
same result with full optimization.

Take note I do not say C18 is better than PICC18. In fact
I guess PICC18 is still better than C18 in some aspects.
I can only guess that this stack is more optimized for C18.
Maybe HiTech can produce a better version if they want to do
that. To be honest, I think C18 and C30 are gaining market
share from HiTech and IAR since there are much more examples
for C18 and C30 and their student versions help a lot for
beginners.

> Also, do you know if PICC18 is using the new FSR2 relative
> addressing mode to compile this program (maybe this is a
> compiler option)?

I am not so sure since I do not have access to a proper
version of PICC18. Maybe someone with PICC18 can try it.
And I hear that HiTech will sell a new version of PICC18
called HI-TECH PICC18 Pro compiler which will presumably
be better than the standard version.