On Sat, 20 Mar 2004, xavier.montagne wrote:

> For technical reason GCC cannot be ported to a PIC18 target....

The only technical reason I know is the skill of the programmer performing
the port. Instead, you could say that for 'practical' reasons it's
difficult to port GCC to the PIC architecture and that SDCC is more
suitable. When I first started the SDCC PIC port a few years ago, one of
the reasons I chose it is because the GNUPIC tools already had support for
an assembler, linker, and debugger. Targetting GCC would mean that a good
portion of those would have to be recreated. (I know, technically you
don't have to port gas and ld too, but to be consistant with the tool
chain it's a good idea).

I haven't performed any serious work with on SDCC in the last year and a
half. I had taken to what I say would be 'alpha' level. Most of the basic
stuff worked just fine. Since then, Vangelis Rokas has started a pic16
port ( a sort of fork from the pic14 port). A few people have patched the
pic14 port to work better with gplink. The last timed I tried the SDCC pic
port, I was disappointed to see that the regression tests no longer pass.
In fact, the compiler generates garbage. So now I'd say it sits in
pre-alpha (operand types are no longer processed correctly for some
reason). I don't know about the state of the pic16 port.

I don't have any major near term plans to fix SDCC.

If I did, this is what I'd do:

 1) fix the current regression tests
 2) move the pcode optimizer to the linker
 3) move the call tree analyzer to the linker
 4) move the register allocation to the linker


Scott

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu