I think you will end up close to targeting gcc to a 32-bit
architecture and interpreting that architecture on the PIC.
But of course I am prejudiced because I choose a different
route. I'd be interested in your experiences!
(I once stared targeting gcc to some weird space-grade
processor but I had to give up because there wasn't even a
good assembler or CPU decription available.)

Keep a few things in mind when you target PICs:
- the 8 (or even 2) level stack is a real trouble,
  so consider to
     - check the amount of stack needed at compiler time
     - replace tail calls with jumps
     - inline at least the single-called routines
     - provide some alternative (store a return indication
       and use a goto insetad of a call)
- accessing all data via some index register is
  slow and uses lots of code; a static-stack
  requires more work from the compiler (and
  cannot cope with recusion) but is otherwise
  much better

regards,
Wouter
----------
> From: Michel Van den Bergh <vdbergh@ZOLA.LUC.AC.BE>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: PICLIST Digest - 13 Jan 1999 to 14 Jan 1999
> Date: Saturday, January 16, 1999 13:05
>
> Hi,
>
> Well, I have been reading the gcc manual (the one that comes with the
> source) and I have been studying Otto
> Lind's port of gcc to the 68HC11. As far as I can see there is nothing
> that would make porting gcc to the PIC 16F84 impossible or unfeasible.
>
> Sure the Pic has no builtin stack, so you have to simulate one in RAM.
But
> gcc's optimization seems to be so good that most stack invokations are
> eliminated anyway.
>
> Furthermore the Pic has only one register, so you have to work with
> virtual registers (as is the case for the 68HC11 port). This has the
> potential of generating unnecessary store's and load's, but again gcc
> seems to optimize these away. In fact the optimization power of gcc seems
to
> be truly awesome!
>
> The fact that the Pic is 8bit, does not make it impossible to work with
> 16bit (or higher) variables. Gcc will store these in consecutive
> (virtual)registers or stack locations.
>
> One thing I was worried about was the implementation of the "const"
> directive (this should be implemented through a lookup
> table). However  gcc will place constant array's in
> code space (see the 68HC11 port), with the correct directive to make
> them lookup tables.
>
> As far as needing a new linker, I don't see why. The compiler would
> generate MPASM files, which can be linked with Microchip's MPLINK and
> MPLIB. I think there is enough code around to make a good standard 16
> bit library.
>
> To port gcc one would only need to write three files:
>
>
> picxxxx.md : The machine description: describes the types of
> instructions availabe. This is a kind of rule based expert system.
>
> picxxxx.h : Macro definitions describing the stack outline, register
> usage, memory addressing schemes, function prologue and epilogue,
> passing of arguments in registers, etc...
>
>
> picxxxx.c : Support for picxxxx.h (some things are a little to
> complicated to be implemented as macros). Also, when using makefiles,
> it is better to have a .c file than a .h file. The latter tends to
trigger
> recompilation of everything.
>
> If I find the time then I plan to try write some of these. I wouldn't
> follow the 68HC11 port too closely, since I think Otto Lindt might have
missed some
> potential optimizations (like the possibility of eliminating entirely a
stack
> frame for a function, which will happen quite often I think).
>
> If other people are interested please email me (people from gnupic?). But
please read the
> manual (Richard Stallmann's "Using and porting gcc") and study the 68HC11
port first (a
> search with altavista for the words 68hc11 and gcc will turn up the
latter).
>
>
> Regards,
> Michel