!!!!! Warning !!!!!

This Small C PIC compiler is still considered as Work in Progress! The code
generated by the present codepic.c PIC code generator hasn't been
extensively tested. When it finally gets to a usable stage, it will be slow
and inefficient, at least compared to straight assembly language code.

It seems Ian Stedman just got started on the conversion of the code
generator and libraries to Microchip syntax. Consequently, I thought it
would be better to start with a fresh version of John Favata's PIC code
generator, rather than taking over Ian's unfinished work.

I rewrote the code generator, the libraries, the test programs, added some
documentation and fixed one or two small details in the rest of the package.

Also note that PICs are poorly suited to the general CPU model assumed by
this Small C compiler: stack handling is awkward and the compiler really
wants two general purpose registers/accumulators, whereas the PIC's single W
register cannot even be thought of as a standard accumulator. Sometimes code
that can be handled with a single assembler mnemonic in Z80 assembler takes
5 or more instructions in PIC assembler. Oh well...

PICs excel at bit handling (I have to write a lib for that, BTW), but they
shouldn't be used in applications where a modern 16 or 32-bit processor is
really needed, IMHO.

IOW, don't expect the performance of a 600MHz 64-bit Alpha out of an 18-pin
$5 chip. But for most PIC applications, performance is _not_ critical and
programming in C saves time. A good deal of code can be crammed in the 16x84
1k word instruction memory.

Tips
----

If performance is somehow important and/or code size matters, assembler
statements can be mixed with the C source code or one can take a look at the
resulting .asm file and edit it as required (the -r "trace" compiler command
line switch may help here).

The C routines should better be kept relatively small, since the compiled +
assembled executable files tend to grow quite fast as the compiler is not
very efficient. A neat way to circumvent this is to #include various assembly
language routines from specific libraries, and only write the program
skeleton using C.

I noticed that global variables tended to save code space, compared to local
variables and all the stack shuffling required to pass them around.

Compile the small test programs and visually inspect the assembled code.
It's very instructive, specially with the -r switch. I simulated all the
test programs using xnitpic by Dave Madden, a neat X Window visual simulator
for the 16x84.

Andrew D. Balsa <andrebalsa@altern.org>
November 15, 1998.
