Searching \ for '% Porting from one C compiler to another.%' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ios.htm?key=port
Search entire site for: 'Porting from one C compiler to another.'.

_Sub string match.
PICList Thread
'[PICLIST] Porting from one C compiler to another.'
2001\12\30@025605 by Mark Newland

flavicon
face
The last thing I want to do is create yet another holy war on the great
aspects of one C compiler over another.  What I would like to ask is the
complexity involved with re-writing my old CCS code to someother
compiler such as Hi-Tech.  I know that there is some work involved when
going to/from Microchips native assembly language (*.asm) and Techtools
CVASM (*.src) for instance.  However, it is not beyond a little time to
do so.  Would converting from my old CCS code to Hi-Tech be better,
worse, or about the same as going from a *.asm file to a *.src file?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@093450 by Gerhard Fiedler

flavicon
face
At 22:57 12/29/2001 -0800, Mark Newland wrote:
>The last thing I want to do is create yet another holy war on the great
>aspects of one C compiler over another.  What I would like to ask is the
>complexity involved with re-writing my old CCS code to someother
>compiler such as Hi-Tech.  I know that there is some work involved when
>going to/from Microchips native assembly language (*.asm) and Techtools
>CVASM (*.src) for instance.  However, it is not beyond a little time to
>do so.  Would converting from my old CCS code to Hi-Tech be better,
>worse, or about the same as going from a *.asm file to a *.src file?

I guess it depends a lot on how you wrote your code. I'm not intimately
familiar with the CCS compiler (test-drove it a few years back and then
used HiTech), but in any case you'd have to provide routines for all of the
special commands. Many declarations are different, too, especially the bit
types.

Much of it can probably be addressed by providing library routines with a
functionality simulating the CCS special commands and some smart use of the
C preprocessor to translate the most common constructes form one to the
other. But I'd expect to have to inspect each line of code. This is the
price for the very high non-compliance of the CCS compiler.

ge

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@124029 by Dale Botkin

flavicon
face
Mark Newland <spam_OUTapeTakeThisOuTspamESKIMO.COM> said:

> The last thing I want to do is create yet another holy war on the great
> aspects of one C compiler over another.  What I would like to ask is the
> complexity involved with re-writing my old CCS code to someother
> compiler such as Hi-Tech.  I know that there is some work involved when
> going to/from Microchips native assembly language (*.asm) and Techtools
> CVASM (*.src) for instance.  However, it is not beyond a little time to
> do so.  Would converting from my old CCS code to Hi-Tech be better,
> worse, or about the same as going from a *.asm file to a *.src file?

I've tried to convert code written for CC5X to CCS, from Hi-Tech to CC5X, and
from Hi-Tech to CCS, with varying degrees of success.  Going from anything to
CC5X I had no luck due to the limitations of CC5X, though I understand it's
much improved since I tried it.  Going from Hi-Tech to CCS and back you will
run into a couple of issues:

1. CCS has built-in functions that HT doesn't, so some code will have to be
written/re-written from scratch.  For example, with CCS I say:

setup_adc(ADC_CLOCK_DIV_32);
setup_ccp1(CCP_CAPTURE_RE);
setup_timer_1(T1_INTERNAL | T1_DIV_BY_1);

With HT I'd have to rewrite all that to set individual control register bits.
I could probably actually write functions in an #included file and leave the
original source untouched.  If it's a lot of CCS code, though, you may find
there are a LOT of functions you will need to write from scratch.  Those
builtin functions, as well as an extensive driver library, are a couple of the
reasons I selected CCS...

2. I *think* -- and I'm sure someone will correct me if I'm wrong -- HT
considers int to be 16 bits and short to be 8 bits, as opposed to 8 and 1 bits
in CCS.  I also seem to recall HT has no single-bit type (maybe booloean?).
Some typedefs might be needed to get past this.

In short, if you've used none of CCS' compiler-specific features, it may not
be a real big job.  Otherwise it would probably be more of a line-by-line
rewrite than simply making a few minor changes.  Still not too difficult, of
course, they are both C.

As for going from .asm to C source...  rotsa ruck, never heard of an animal
like that.  It would seem that writing such a beast would be an order of
magnitude more difficult than writing a compiler.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@141524 by Mark Newland

flavicon
face
Thanks Dale and Gerhard,

That kind of tells me what I needed to know.  I don't actually have CCS yet but
getting tired of writing in assembler.  Not that I hate writing in assembler and
am fairly familiar with it, it's just that I can see the speed / time advantages
in switching to C.  I was hoping that I could get CCS now and upgrade to Hi-Tech
later when I can afford it a little more.  Sounds like that may not be the best
option.  Therefore, I can see my options as follows (someone feel free to add
more):

1) Buy CCS and deal with it.  Assume that I will use it forever.

2) Buy CCS and write it for easy porting to HT later (that should be FUN, haha!!).

3) Buy something else such as FED which is "ANSI-C compilant" (or so they say) and
port over to HT from there. Altho I didn't see that it supports the 12-bit cores.

4) Bite my nails and wait for SDCC. Unfortunately, I have a customer (my first
one) waiting for his project

5) Go into debt and give Don (Hi Don!!) $750 and buy HT (kind of leaning towards
this way)

The big issue here is not what is the best complier for the money.  I have heard
many dicussions about this and the information was great, thanks.  The question
that I have is more on being trapped to one compiler after I buy it.  I haven't
seen many discussions about the portability of one to another.  Compiler "X" may
be twice as good and half the price as compiler "Y", but is compiler "X"
compatible with anything else?  Sounds like CCS is more like compiler "X" with
twice the functions at at a great price but as Gerhard said, it has a "... very
high non-compliance ..." compared to others.


Dale Botkin wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@145958 by Scott Dattalo

face
flavicon
face
On Sun, 30 Dec 2001, Mark Newland wrote:

> 4) Bite my nails and wait for SDCC. Unfortunately, I have a customer (my first
> one) waiting for his project

Mark,

That's too much risk. As the primary author of the PIC port of SDCC, I'd
recommend NOT depending on SDCC right now. As I've said before, I expect a
beta version to be ready around March.

If you want to write compiler independent code then you're going to need
the help of the C-preprocessor. I'd suggest creating an include file that
defines all of the basic types:

(NOTE: I don't own these compilers, so I'm not sure if the sizes are
correct or not)


#ifdef HITECH

#define u8  unsigned char
#define s8  signed char
#define u16 unsigned int
#define s16 signed int
...

#endif

#ifdef CCS

#define u8  unsigned int
#define s8  signed int
#define u16 unsigned long
#define s16 signed long

#endif



Then in your code, if you need an unsigned 8 bit variable, you can do
this:

u8 var1;


As far as the built in functions, well, your basically stuck rolling your
own.


Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@155544 by Gerhard Fiedler

flavicon
face
At 11:16 12/30/2001 -0800, Mark Newland wrote:
>Therefore, I can see my options as follows (someone feel free to add more):
>
>2) Buy CCS and write it for easy porting to HT later (that should be FUN,
>haha!!).

This might be a real option. Well structured code, some standardizing
typedefs and macros and consistent use of the special features makes this
easier.

>5) Go into debt and give Don (Hi Don!!) $750 and buy HT (kind of leaning
>towards this way)

Apparently this is what I did... But I got it cheaper, I was a beta user
back then :)


>Dale Botkin wrote:
> > setup_adc(ADC_CLOCK_DIV_32);
> > setup_ccp1(CCP_CAPTURE_RE);
> > setup_timer_1(T1_INTERNAL | T1_DIV_BY_1);

Stuff like this, for example, should be possible to handle with macros.
Even more so if you already do it with macros (that expand to the above) in
CCS, and then just replace to what the macros expand when moving to a
different compiler.

ge

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\30@165737 by Mark Newland

flavicon
face
After looking at my checkbook about 30 times and hitting my head against the
wall shortly after, I think going with HT is the best way for me long term.
However Gerhard, you did bring up a good idea with the macros and such.  It
might make good business sense for the CCS guys to write up some include file
(filled with macros) to make things slightly more compatable.

Gerhard Fiedler wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\31@004704 by Dale Botkin

flavicon
face
Mark Newland <apespamKILLspamESKIMO.COM> said:

> twice the functions at at a great price but as Gerhard said, it has a "...
very
> high non-compliance ..." compared to others.

I just have to ask...  compliance with what, exactly, and why?  It's
compiling code for a very unique hardware environment, so one would think
that the addition of functions in support of that environment would be a good
thing.  Remember that the mere fact that there exists a predefined function
for (for example) setup_adc() doesn't mean one is required to use it.  I
could, if I wanted absolute portability, write defines and whatever else for
Compiler X in such a way that Compiler Y would compile the same code.  Too
inconvenient, you say?  Hmm...  I felt the same way about writing all those
functions for Compiler Y before being able to do anything useful with it.
Six of one, half dozen of the other.

As for porting old projects to a new compiler...  I  have tried that on
several occasions, not limited to PIC or C projects.  I see it every day at
work, where extensive development is done with C, C++, Java, VB, Oracle and
other languages/platforms.  I see code that isn't portable from one *version*
of the same vendor's compiler to the next (Sun V4 to V5 or V6, for example),
let alone from one vendor to another (like Sun's C compiler to GCC).  Yes, in
theory one could write strictly to some spec like ANSI C.  In theory, there
is no difference between theory and practice; in practice, there is a big
difference.  In the end, when I finish a project I have taken to archiving
the project code along with the compiler that was used to make it work.
It's the only really safe way to maintain the code later if you need to.

Anyway...  having said that, I have still not noticed a terrible lack of ANSI
compliance with CCS, at least not that can't be eliminated with some typedefs
and such.  I'm not an expert on such matters, but you won't find a PIC C
compiler that *is* completely ANSI compliant, I don't think a single one of
them allows recursion for a start.  And I'm not trying to make an argument
for one compiler over another (though I make no secret of my favorite, and my
reasons).  I just hate to see decisions made based upon flawed logic, or
those made that ignore the difference between theory and practice.

Dale
(My neighbor drives a far more expensive car than mine.  I'm convinced mine
is a far better choice than his.  He's equally convinced his is better than
mine in every respect.)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


'[PICLIST] Porting from one C compiler to another.['
2001\12\31@011346 by steve b

flavicon
face
I really wish someone would port the GCC compiler to the PIC line.  I have
used it with 68K variants with good luck.

Any Volunteers??



Have fun and a very happy new year to all.



In theory there is no difference between theory and practice.  In practice
there is a whole bunch of difference.  I pick practice.

Bad things like software bugs do not come one at a time but in bunches and
groups.  My apologies to Mr Shakespeare.

Steve B


{Original Message removed}

2001\12\31@022551 by Mark Newland

flavicon
face
I can't speak for others but one of the main things I am looking at is NOT
learning 4+ versions of 'C'.  I want to eventually learn 'C' so I can do some
programming for the palm pilot (take advantage of the IrDA port).  I may also
want to learn some 'C' (maybe visual 'C') for the desktop environment (maybe do
IrDA programming there too or some test routines).  Maybe even be able to do some
'C' one day in the future for Linux.  I know that these 3 versions of 'C' are not
going to be compatible with each other but they are at least simular (I least I
think they are).  What I don't want is to learn a 'C' language for the PIC that
is dis-simular to the other 3.

From what I understand, Hi-Tech would be more simular to these others than CCS
would be (at least out of the box).  Your right in that I don't have to use the
built in functions of CCS but now a question based on that.

1) Am I to assume that if I don't use the built-in functions, I would have to
write the functions myself from scratch or could I truely just have a creative
set of defines and macros?

2) If I have to write functions for CCS, are these functions not already included
in the higher price tag of Hi-Tech 'C'?

3) If I don't have to write functions for CCS to match the functions in Hi-Tech
'C', why is Hi-Tech still in business at the outrages prices they have?

I agree that CCS is probally the best compiler in it's price range and if I
wasn't trying to compare it with other 'C' packages that I would have to learn, I
would probally buy it. The way I see it right now is that it comes down to a
simple "cost of the libraries" decision. The question of what is worth more to
me, good compiler with pre-written libraries or cheaper (but still good) compiler
without the libraries.

Again, someone please PLEASE tell me that I am completely confused and have no
idea what I am talking about.

Dale Botkin wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@040127 by uter van ooijen & floortje hanneman

picon face
> I really wish someone would port the GCC compiler to the PIC line.  I have
> used it with 68K variants with good luck.
>
> Any Volunteers??

Has been discusses to death. And that is IMHO the only fate for such an
attempt: the architecture of gcc and PIC as too far apart. As far as gcc is
concenred AVR or 8051 are almost mainstream architectures, while PIC is a
strange beast. But luck if you want to try yourself! Be sure to consult with
Scott first, I'm sure he has considered gcc before thking on sdcc.

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.voti.nl/jal
PICs kopen? http://www.voti.nl/shop

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@070137 by Gerhard Fiedler

flavicon
face
At 05:45 12/31/2001 +0000, Dale Botkin wrote:
>Mark Newland <RemoveMEapeTakeThisOuTspamESKIMO.COM> said:
> > twice the functions at at a great price but as Gerhard said, it has a "...
>very
> > high non-compliance ..." compared to others.
>
>I just have to ask...  compliance with what, exactly, and why?  It's
>compiling code for a very unique hardware environment, so one would think
>that the addition of functions in support of that environment would be a good
>thing.  Remember that the mere fact that there exists a predefined function
>for (for example) setup_adc() doesn't mean one is required to use it.

One thing that bugged me about CCS (a few years ago, though -- I'm not up
to date with CCS at all) was the fact that it implemented only the basic C
syntax and not much more of C's structure. For example, in a more compliant
C compiler, the special functions would be implemented as library files,
with a combination of macros (in header files) and library functions -- a
more transparent method, you don't have to learn a new language element,
you just look at the library implementation and know how it is done. From
the special functions I've seen, I don't see a reason why this can't be
done. But the creator of CCS has chosen not to use the standard way,
without a need that I can see.

I don't work exclusively in PIC C, and when I do, using a compiler that is
more "normal" in all its ways helps me tremendously to avoid having to get
up to speed each time I get into it. This is one of the functions of
standards, and that's why for me a certain standard compiance is an
advantage. I'm not talking about whether int is 8 bit or 16 bit -- this is
the small stuff that can be fixed easily. I'm talking about the thinking
behind the compiler. If the creator doesn't think in C, structure-wise, I
don't have a common language with him. I've also used Dynamic C (because of
a client requirement), which is another of those C compilers that implement
only the basic C syntax but have a completely different structure than
standard C. Makes it more difficult than necessary for me to tune to that
thing everytime I have to.

(Note that this is highly personal, just to answer your question
"compliance why?". It's not an objective evaluation :)

ge

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@073256 by Gerhard Fiedler

flavicon
face
At 23:27 12/30/2001 -0800, Mark Newland wrote:
>I can't speak for others but one of the main things I am looking at is NOT
>learning 4+ versions of 'C'.

What you will have to learn are 4+ different sets of libraries -- which are
way more complex than the language itself, and change a lot faster. That's
the trouble, and I know no way around it (other than to give up programming
and start to simply make money :)

> From what I understand, Hi-Tech would be more simular to these others
> than CCS
>would be (at least out of the box).

As stated in more extent in another message, for me the standard structure
how the compiler works (header include files, separate compiling of library
files, linking for example) makes working with HiTech a lot easier for me.
Your mileage may vary.

>1) Am I to assume that if I don't use the built-in functions, I would have to
>write the functions myself from scratch or could I truely just have a creative
>set of defines and macros?

If you don't use them, you have to write something to replace them for
yourself. Can probably be (sometimes simple) macros in many cases, a
combination of macros and normal code (IIRC always included in CCS, never
linked) in other cases.

>2) If I have to write functions for CCS, are these functions not already
>included
>in the higher price tag of Hi-Tech 'C'?

Some, probably not all. HiTech provides a number of example libraries,
which I usually modify to suit my needs. But I _can_ modify them (because I
have the full source code) -- there's no way to modify the code generated
by the built-in functions of CCS, there's not even a simple way to use them
as a base for writing your own (other than copying from the generated
assembler listing). And if you want to inspect them, you have to look at
the generated assembler code, not at the source C code. One of the reasons
why I prefer libraries over built-in functions (and one of the reasons why
standard C was designed that way).

>3) If I don't have to write functions for CCS to match the functions in
>Hi-Tech
>'C', why is Hi-Tech still in business at the outrages prices they have?

No answer here... :)  When I evaluated CCS amd HiTech a few years back, I
got scared by the amount of bug fixes the CCS author published each week.
That was a constant flow, which also means that there were, with a high
probability, still many many weeks of bugs to fix in the compiler I was
using at any time. Which in a way does not shed a good light on the quality
of the compiler design.

ge

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@093545 by Lawrence Lile

flavicon
face
Log onto the hi-tech support board and look for a long thread by me entitled
"12 step program for CCS users"  It details nuts and bolts the agonies and
ecstacies of porting from CCS to Hitech C.  http://www.htsoft.com/    Hitech
Support Board

There are several main Gotchas:

1. Words, ints, longs etc. are not the same number of bits from Hitech to
CCS.  I have started declaring "int8" instead of "byte" or "word" in CCS,
because someday when I port it, this will translate correctly.  An int is 16
bits in Hitech, 8 bits in CCS, IFIRC

2.  Hitech's paradigm about Printf is different, and printf'ing will
generate more PIC code bloat in Hitech than CCS.

3.  Hitech has a minimalist attitude toward providing non-ansi functions.
Other people have posted them around, things such as a packaged A/D function
specific for the PIC.  OTOH, CCS tries to support all the PIC functions,
with various leves of success.  If you are re-writing CCS's PIC specific
functions over to suit your taste, you need to be using Hitech IMHO.

4.  I was able to feel confident about porting CCS code to Hitech after a
coupla days of head scratching.

5. Virtually all of CCS's PIC specific functions have to be hacked or
re-written to port to Hitech.  (stuff like read_eeprom(), set_pwm_duty_1()
and so on. )  I ended up scrapping them and writing my own.  There will be
some code which would need extensive revision, esp. if you could not pull
off a function that duplicates CCS' syntax exactly.  Mostly I just wrote a
function that uses the same syntax, so it could substitute.  But not having
infinite time, I would always end up with functions that only worked on one
PIC, and maybe not others.  OTOH, the effort put into this could make a nice
little personal library.

6. Advice? You will probably be able to produce projects from here to
eternity with either compiler.  I've used (and cussed) CCS for maybe 4
years, and despite all the cussing I am still writing new projects with it.
More than likely you'll stick with whatever you learn first.


--Lawrence Lile





{Original Message removed}

2001\12\31@095054 by Tim McDonough

flavicon
face
Mark Newland wrote...


> I can't speak for others but one of the main things I am looking at is NOT
> learning 4+ versions of 'C'.  I want to eventually learn 'C' so I can do
some
> programming for the palm pilot (take advantage of the IrDA port).  I may
also
> want to learn some 'C' (maybe visual 'C') for the desktop environment
(maybe do
> IrDA programming there too or some test routines).  Maybe even be able to
do some
> 'C' one day in the future for Linux.  I know that these 3 versions of 'C'
are not
> going to be compatible with each other but they are at least simular (I
least I
> think they are).  What I don't want is to learn a 'C' language for the PIC
that
> is dis-simular to the other 3.

> Again, someone please PLEASE tell me that I am completely confused and
have no
> idea what I am talking about.

My experience is that C is only portable until you write the first line of
code that is specific to the target hardware/operating system. It doesn't
matter whether it is a PIC, 8051, C167, Windows, Linux, Palm, etc. You could
choose to use only the strict ANSI features of any vendors compiler and
write your own platform specific code, but why? The end result, other than
the non-standard API you invent, would still only be useable on one
platform. All the extra coding, testing, documentation, and debugging would
probably take far longer than learning the pragmatic features of a specific
vendors compiler.

I'm not meaning to bash C or your questions. If you learn C well adjusting
to the various vendor specific features, etc. will be fairly painless.

Tim

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@095720 by Lawrence Lile

flavicon
face
> >3) If I don't have to write functions for CCS to match the functions in
> >Hi-Tech
> >'C', why is Hi-Tech still in business at the outrages prices they have?
>
> No answer here... :)  When I evaluated CCS amd HiTech a few years back, I
> got scared by the amount of bug fixes the CCS author published each week.
> That was a constant flow, which also means that there were, with a high
> probability, still many many weeks of bugs to fix in the compiler I was
> using at any time. Which in a way does not shed a good light on the
quality
> of the compiler design.
>

I used to get  frustrated at the constant stream of CCS bug fixes, which
have never stopped from day one.  OTOH, they can fix a problem really fast
if it is MY problem, then that is a good thing, making me not so frustrated.
CCS does not buy into the normal rhythm of major revision, alpha test, beta
test, release.  They bang out code and ship it.   They bust a lot of other
paradigms as well, in their business model.   They charge by the year for
updates and support, but have a low entry-fee.  All us developers should
take a lesson from thier business model, it makes a lot of long term sense
for the developer and eats into the market share of the competition.   I can
say that their code becomes more stable over time, and less stable after a
major release.  Don't get the latest big revision 3.000, wait for version
3.050 which will come out in 50 days or less.

Hitech's business and software release paradigm is more normal.  That's why
they are still in business.

--Lawrence

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@101413 by Dale Botkin

flavicon
face
On Sun, 30 Dec 2001, Mark Newland wrote:

> I can't speak for others but one of the main things I am looking at is NOT
> learning 4+ versions of 'C'.  I want to eventually learn 'C' so I can do some
> programming for the palm pilot (take advantage of the IrDA port).  I may also
> want to learn some 'C' (maybe visual 'C') for the desktop environment (maybe do
> IrDA programming there too or some test routines).  Maybe even be able to do some
> 'C' one day in the future for Linux.  I know that these 3 versions of 'C' are not
> going to be compatible with each other but they are at least simular (I least I
> think they are).  What I don't want is to learn a 'C' language for the PIC that
> is dis-simular to the other 3.
>
> >From what I understand, Hi-Tech would be more simular to these others than CCS
> would be (at least out of the box).  Your right in that I don't have to use the
> built in functions of CCS but now a question based on that.
>
> 1) Am I to assume that if I don't use the built-in functions, I would have to
> write the functions myself from scratch or could I truely just have a creative
> set of defines and macros?

Hmmm...  I never use macros, personally...  but from the looks of it you
could do most of the "setup_this_register()" type functions as macros
quite easily.  Some of the more complex functions I guess could be done
either way.

> 2) If I have to write functions for CCS, are these functions not already included
> in the higher price tag of Hi-Tech 'C'?

The other way around, I think.  There are a lot of functons included with
CCS that you'd have to write for Hi-Tech.  Most of what I'm talking about
are device drivers and such...  LCD, matrix keypad, Dallas 1-wire,
external ADC, EEPROM, plus all of the internal peripherals are supported
by CCS built-in functions or included driver and/or example files.

> 3) If I don't have to write functions for CCS to match the functions in Hi-Tech
> 'C', why is Hi-Tech still in business at the outrages prices they have?

Dunno.  Why is Acura still in business selling overpriced Hondas?  I'd say
probably a mixture of personal preference, a different approach that some
people prefer, and possibly a little bit of "best tool = most expensive
tool"  thinking.  Hi-Tech also seems to at least give the impression of
having their act together a little better when releasing new versions...
CCS seems to be run by programmers, which has its good and bad points.

> I agree that CCS is probally the best compiler in it's price range and if I
> wasn't trying to compare it with other 'C' packages that I would have to learn, I
> would probally buy it. The way I see it right now is that it comes down to a
> simple "cost of the libraries" decision. The question of what is worth more to
> me, good compiler with pre-written libraries or cheaper (but still good) compiler
> without the libraries.

If you're talking about stdio.h, stdlib.h, string.h, math.h, ctype.h,
they're there.  I don't know what libraries weren't there a few years ago,
but I've taken code snippets back and forth between CCS and GCC to debug
stuff on my Linux machine.  All the functions I've used have worked the
same on both systems.

I'm no expert on C or C compilers, as I have said before.  I'm not sure
what the advantages are of having the libraries compiled separately and
linked by a linker...  have never used a PIC compiler that did that,
frankly.  I just #include the libraries I need and compile, which is
the same thing I do with GCC.  It's true that some of the built-in
functions are actually built in, not in a library, and I don't have access
to the source for those...  but if I find one I don't like, I can always
write my own and not use CCS'.  I have looked at the generated .ASM code
for about all of them and have yet to find one I thought I could do
better, so it hasn't been an issue for me.

I've heard the library & linker thing before...  others have pointed out
that CCS doesn't have a linker (it does, it's just not separate so I don't
have to mess with it).  My car doesn't have a hand crank for starting
either, I haven't missed it so far.  I also like letting the compiler
worry about where to put variables and such.  But then again I'm someone
who hasn't got a CS degree or a formal programming education, maybe I was
just never taught to care as much about the process of how the code gets
generated as I do about just writing the code.  Perhaps if I were taught
the internals of compiler design on larger systems I might care more about
the differences.

Having looked at the compiler comparisons (http://www.ccsinfo.com/compare.html if
you're interested), I'm even more convinced I made the right choice for
what I do.  The last project I did involved extensive user interaction,
and a less-useful printf() function would have killed me for sure.  Of
course that would not have been an issue for some people.  I also *really*
like the fact that unused functions are simply not compiled with CCS - so
if I use only one function from a library, I get only the code for that
function and not the whole library.  If I understand correctly, this is
not the case with some other compilers, using one function from math.c
would get the whole library dropped into my code.  That would be a killer
for some of my projects.

> Again, someone please PLEASE tell me that I am completely confused and have no
> idea what I am talking about.

How would I know?  I'm in the same boat...  'cept I can almost guarantee
I don't kow what I'm talking about.  8-)

Dale

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@101619 by Bob Ammerman

picon face
After quite a bit of experience I find the following three layered technique
to work the best for keeping my C and C++ code portable:

1: Write as much of the code as possible using ANSI standards. This should
include all the code that does not directly depend on the operating system
or hardhware environment.

2: Route all interface to the OS/Hardware thru a middle layer with a well
defined interface.

3: The middle layer code is system dependent and is replaced as needed on
different platforms to interface with the underlying hardware or OS (the
third layer).

Bob Ammerman
RAm Systems

{Original Message removed}

2001\12\31@103834 by Scott Dattalo

face
flavicon
face
On Mon, 31 Dec 2001, wouter van ooijen & floortje hanneman wrote:

> > I really wish someone would port the GCC compiler to the PIC line.  I have
> > used it with 68K variants with good luck.
> >
> > Any Volunteers??
>
> Has been discusses to death. And that is IMHO the only fate for such an
> attempt: the architecture of gcc and PIC as too far apart. As far as gcc is
> concenred AVR or 8051 are almost mainstream architectures, while PIC is a
> strange beast. But luck if you want to try yourself! Be sure to consult with
> Scott first, I'm sure he has considered gcc before thking on sdcc.

There are two reasons I chose SDCC over gcc. SDCC has been optimized for
tiny processors and their built in obscurities. For example, the mid range
PIC's have no data stack for passing parameters or storing temporaries.
SDCC deals with this quite conveniently by allowing PORT specific ways for
passing parameters (I sacrificed recursion and decided to pass function
parameters through local variables). The other reason I chose SDCC is that
I didn't want to support binutils in gpasm and gpsim. I suppose gcc can be
coerced into ignoring binutils, but SDCC again handles this well.

One person has contacted me about a PIC gcc port. However, after they
realized the amount of effort involved I believe they gave up.

BTW, SDCC's syntax parser is derived from gcc...

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@104252 by Gerhard Fiedler

flavicon
face
At 08:54 12/31/2001 -0600, Lawrence Lile wrote:
>I used to get  frustrated at the constant stream of CCS bug fixes, which
>have never stopped from day one.  OTOH, they can fix a problem really fast
>if it is MY problem, then that is a good thing, making me not so frustrated.

I've had about one project breaking bug per year with HiTech, and after I
found it, they usually fixed it within one or two days. One time it took
two or three iterations of this. I find it extremely frustrating to chase a
bug and then first start to suspect, then do a lot of research and later
know that it is a compiler bug. If I knew how to do it less often, I'd
probably go that route.

ge

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@115256 by Douglas Butler

flavicon
face
I am not a programmer but I play one at work, when I am not playing an
EE, machinist, or janitor.  I am puzzled by the following question &
answer:

{Quote hidden}

Which CCS functions are not available as C source?  The STDIO, X10, LCD,
and Dallas touch functions are all plain text C source files.  Something
like Setup_counters() is just some defines and stuffing the results into
registers.  You are never going to write PIC C code without the uP
datasheet at hand anyway so I don't need the compiler to tell me which
registers the counters use.  I don't understand the problem.

I would also add that I have never run into a bug in CCS that I couldn't
code around, like changing a case statement to a string of if-thens or
simillar.  Usually when I do code around what I thought was a bug I find
it was really pilot error after all.  A bug would have to be pretty
catastrophic for me to sit on my hands and wait for the compiler authors
to fix it.  My customers aren't that patient!

Sherpa Doug

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@145500 by steve b

flavicon
face
Is the PIC port of the SDCC completed yet?

In theory there is no difference between theory and practice.  In practice
there is a whole bunch of difference.  I pick practice.

Bad things like software bugs do not come one at a time but in bunches and
groups.  My apologies to Mr Shakespeare.

Steve B


{Original Message removed}

2001\12\31@152122 by Gerhard Fiedler

flavicon
face
At 11:50 12/31/2001 -0500, Douglas Butler wrote:
>Something like Setup_counters() is just some defines and stuffing the
>results into registers.  You are never going to write PIC C code without
>the uP datasheet at hand anyway so I don't need the compiler to tell me
>which registers the counters use.  I don't understand the problem.

There's no problem, if you're happy with your compiler -- I just happen not
to like the way the CCS compiler works. There must be others who think the
same way, or else all except CCS would by now be out of business.

I also don't think I need the compiler to tell me which registers to use --
that's why I don't value the special commands like Setup_counters() that
high -- that is, at all. I rather read the PIC datasheet and set the
registers I need than to read both the compiler handbook and the PIC
datasheet and wonder whether the compiler actually sets the registers I
want to set :)

>I would also add that I have never run into a bug in CCS that I couldn't
>code around, like changing a case statement to a string of if-thens or
>simillar.  Usually when I do code around what I thought was a bug I find
>it was really pilot error after all.  A bug would have to be pretty
>catastrophic for me to sit on my hands and wait for the compiler authors
>to fix it.  My customers aren't that patient!

Well, I don't know... I don't like to code around compiler bugs in the
first place. And then, there must be _something_ to fix, or else they
wouldn't have been able to hold up the rate of bug fixes (and prolly most
of them actually are bugs :) for years now. Or are you saying that they're
spending all their time for those fixes on nothing really worth fixing? :)

Again, there's no problem. It seems you're happy with your compiler, and I
am, too -- at least most of the time. And I've seen the CCS compiler and am
pretty sure I wouldn't be happier with it than I am with what I have. So
there's no problem at all :)

ge

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@202140 by Scott Dattalo

face
flavicon
face
On Mon, 31 Dec 2001, steve b wrote:

> Is the PIC port of the SDCC completed yet?

No, As I said two posts ago :). Beta ~ March 2002.

If you're anxious to see what's supported, then check out:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/src/regression/

The pic port of SDCC properly compiles every C file on this web page.

The major thing I'll be attacking next is banked RAM. But before this is
solved, I need to write some more infrastructure code to assist in flow
analysis.


Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\31@204051 by steve b

flavicon
face
Sorry, Scott:

I did not catch that.  I saw your site some time ago and have been
(Impatiently) waiting for the PIC implementation.  I looked at the
implementation and I liked what I saw for the other controllers.  I was
(actually thinking about starting a GCC for the PIC but then saw your site)
I  have used GCC for the 68HC11&12 and the M68K Coldfire.

Thanks for the update.  If you need help with beta testing or if I can be of
any assistance please feel free to contact me.  On sourcefroge I am
dbergersonSTOPspamspamspam_OUTusers.sourceforge.net.

Have a wonderful new year.



In theory there is no difference between theory and practice.  In practice
there is a whole bunch of difference.  I pick practice.

Bad things like software bugs do not come one at a time but in bunches and
groups.  My apologies to Mr Shakespeare.

Steve B


{Original Message removed}

2001\12\31@214008 by Mark Newland

flavicon
face
Lawrence Lile wrote:

> Log onto the hi-tech support board and look for a long thread by me entitled
> "12 step program for CCS users"  It details nuts and bolts the agonies and
> ecstacies of porting from CCS to Hitech C.  http://www.htsoft.com/    Hitech
> Support Board
>
> There are several main Gotchas:
>
> 1. Words, ints, longs etc. are not the same number of bits from Hitech to
> CCS.  I have started declaring "int8" instead of "byte" or "word" in CCS,
> because someday when I port it, this will translate correctly.  An int is 16
> bits in Hitech, 8 bits in CCS, IFIRC

Good, this tells me it won't be as hard to go either way >IF< I declare things properly
from the beginning.

> 2.  Hitech's paradigm about Printf is different, and printf'ing will
> generate more PIC code bloat in Hitech than CCS.

Score one point for CCS

> 4.  I was able to feel confident about porting CCS code to Hitech after a
> coupla days of head scratching.

Another point for CCS knowing that I can upgrade later to Hi-Tech if I really wanted
to.

> 5. Virtually all of CCS's PIC specific functions have to be hacked or
> re-written to port to Hitech.  (stuff like read_eeprom(), set_pwm_duty_1()
> and so on. )  I ended up scrapping them and writing my own.  There will be
> some code which would need extensive revision, esp. if you could not pull
> off a function that duplicates CCS' syntax exactly.  Mostly I just wrote a
> function that uses the same syntax, so it could substitute.  But not having
> infinite time, I would always end up with functions that only worked on one
> PIC, and maybe not others.  OTOH, the effort put into this could make a nice
> little personal library.

This kind of supports Dales comment below:
Dale Botkin wrote:

> > 2) If I have to write functions for CCS, are these functions not already included
> > in the higher price tag of Hi-Tech 'C'?
>
> The other way around, I think.  There are a lot of functons included with
> CCS that you'd have to write for Hi-Tech.  Most of what I'm talking about
> are device drivers and such...  LCD, matrix keypad, Dallas 1-wire,
> external ADC, EEPROM, plus all of the internal peripherals are supported
> by CCS built-in functions or included driver and/or example files.

I was originally under the impression that Hi-Tech would have been of more help in this
area.  Sounds like with CCS, I get the drivers, etc and if I don't like them I can
re-write something around them.  With Hi-Tech I don't get them at all.

> 6. Advice? You will probably be able to produce projects from here to
> eternity with either compiler.  I've used (and cussed) CCS for maybe 4
> years, and despite all the cussing I am still writing new projects with it.
> More than likely you'll stick with whatever you learn first.

True, human nature usually dictates this.  Which is why I'm looking at this from the
point of "This is not the only version of 'C' that I'll be useing".  I've had the
headaches of trying to write assembly for too many different PIC's at the same time and
try to keep track of what features went to which PIC.

Dale Botkin also wrote:

> If you're talking about stdio.h, stdlib.h, string.h, math.h, ctype.h,
> they're there.  I don't know what libraries weren't there a few years ago,
> but I've taken code snippets back and forth between CCS and GCC to debug
> stuff on my Linux machine.  All the functions I've used have worked the
> same on both systems.

This is one of the things I was worried about.  Just have heard too many negitive
things about CC5X in this respect and didn't want to fall into that same trap with CCS.

> Having looked at the compiler comparisons (http://www.ccsinfo.com/compare.html if
> you're interested), I'm even more convinced I made the right choice for
> what I do.

I looked as well but noticed it was only one users opinion on that comparison.  Thanks
to the list, I know have many more.

> > Again, someone please PLEASE tell me that I am completely confused and have no
> > idea what I am talking about.
>
> How would I know?  I'm in the same boat...  'cept I can almost guarantee
> I don't kow what I'm talking about.  8-)

I've done 6 hours of reading and research and am still convinced that I know nothing.
Based on that, I have just purchased CCS.  At the very worst, I use it for my one
current project and sell it for half price afterwards (altho I will probally keep it
just to have as a backup).

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body



'[PICLIST] Porting from one C compiler to another.['
2002\01\01@110356 by Scott Dattalo
face
flavicon
face
On Mon, 31 Dec 2001, steve b wrote:

> I did not catch that.  I saw your site some time ago and have been
> (Impatiently) waiting for the PIC implementation.  I looked at the
> implementation and I liked what I saw for the other controllers.  I was
> (actually thinking about starting a GCC for the PIC but then saw your site)
> I  have used GCC for the 68HC11&12 and the M68K Coldfire.

Let's take the GCC conversation off line. I'd like to ask a few detailed
about what you liked.

>
> Thanks for the update.  If you need help with beta testing or if I can be of
> any assistance please feel free to contact me.  On sourcefroge I am
> KILLspamdbergersonspamBeGonespamusers.sourceforge.net.

This would be great! If anyone else cares to test or contribute to the
development please step up! For the time being, you may wish to subscribe
to the SDCC developer's list (fairly low traffic). See

http://sdcc.sourceforge.net/

Specifically:
http://lists.sourceforge.net/lists/listinfo/sdcc-devel

(actually, I didn't see this link on SDCC's web page - oh no, 2000 pic
listers are about to inundate sdcc...)

Scott

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2002\01\01@144256 by Dale Botkin

flavicon
face
Mark Newland <@spam@ape@spam@spamspam_OUTESKIMO.COM> said:

> > Having looked at the compiler comparisons (http://www.ccsinfo.com/compare.html if
> > you're interested), I'm even more convinced I made the right choice for
> > what I do.
>
> I looked as well but noticed it was only one users opinion on that
comparison.  Thanks
> to the list, I know have many more.

That's why I like the list better.  I never trust comparisons posted on
vendor's web sites, since they are by nature biased...  this particular one I
mentioned only because it addressed a few things I know nothing about.  I
also had a hand in one of the camparisons on CCS' site, and I was very
curious to see how they handled it.  From what I saw they were actually more
fair than I expected, having no problem with posting both the plusses and
minuses of their own product.

> I've done 6 hours of reading and research and am still convinced that I
know nothing.
> Based on that, I have just purchased CCS.  At the very worst, I use it for
my one
> current project and sell it for half price afterwards (altho I will
probally keep it
> just to have as a backup).

I'm betting you'll like it, I know I do.  It's not perfect, but then nothing
is.

--
Dale

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...