I know virtually nothing about how to build a C compiler, but
my vague understanding is that most of them develop pseudo code and then
a module for the particular processor containing a description of all the
rules translates that pseudo code in to OP codes or possibly mnemonics
for an assembler to change in to op codes.

        It would seem that for GCC or any other full C compiler, most of the
memory management functions like malloc would have to be turned off for
PIC's since there is such a small amount of memory to work with.  Such things
as printf and all that whole family of functions would almost have to go away
because there is not a standard output as such.  What exactly is left besides
the math routines and possibly string handling routines?

        Another set of routines that would be nice to have in a C compiler
for PIC's but which may simply be too much of a memory hog are all the time
and date building functions.  They are absolutely clever and while Y-2K
compliant will die in 2037 when the 32-bit counter runs out.  That is of
course unless somebody writes a new version of the routine with a new epochal
time at which point, you get another 68 or so years.

        All you need for a clock is a 32-bit counter and the software does
all the rest.  Setting the clock involves a formula that is the reverse
of the first formula.  It calculates how many seconds to put in to the
counter based on the epoch date and the date you told it to set.  These
routines also can understand time zones and even Daylight Savings time rules.

        On another part of this same thread, the usual problem that people
run in to porting C source to a given platform is that of differences
between libraries.  AIX, for example has something called sys/select that
has a lot of network code in it.  You can get programs that call for this
library to compile on Solaris, but you must specify a different set of
libraries when building your Makefile or when you compile a single program
you have written that needs these libs.  What you otherwise get is a flood
of unresolved references and undeclared variable errors for things you never
heard of and certainly didn't put in your program.  Actually, you did put
them there by virtue of using the libraries and the new system you are trying
to port this code to sees that you need these things and they aren't there.
Sometimes, it is as easy as finding out which libraries do provide what you
need and including them in the compilation.  Other times, it gets to be a
grand mess, but that is one of the most common headaches you will run in to.


Martin McCormick WB5AGZ  Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group