Hi Roberto,
The PIC24 family of devices share very little commonality with PIC16 beyond the naming convention. They’re a register-based 16-bit architecture, unlike the PIC16. That said, that does mean that LLVM is a much more reasonable fit to target the PIC24 (and dsPIC) than it is for PIC16.
Modeling your target files after the MSP430 or Blackfin backend is likely your best bet to get up and running relatively quickly. When you run into things you need to model that aren’t represented in your reference backend, then it’s time to look at others to see if there’s something similar there.
Your biggest challenges on the PIC24 will be with regards to program memory data pointers. The ISA level Harvard architecture stuff isn’t handled by LLVM very well at the moment. Address spaces get you part of the way there, but not completely. You may be able to work around that, depending on how much memory your devices have, by using the 32k window that maps program memory into data memory. Similarly, program memory pointers and data memory pointers aren’t the same size, and LLVM isn’t fond of that notion. It wants all pointers to be the same size. You could use a super-set pointer size that’s big enough for either, but that results in each pointer taking two registers, whether it needs to or not, which is pretty much a deal-breaker as it would make for horrible code size and performance, both. More likely you’ll want to go the other way and have universal 16-bit pointers and deal with the upper bits of program memory addresses with attributes and some kind of back-end cooperation with the linker. For additional “fun”, have a look at the Microchip port of binutils with regards to the so-called “phantom byte” in program memory.
Getting a basic, mostly functional port for the PIC24 should be relatively straightforward. Its instruction set is well suited for compilers. Filling in around the edges to make it a full-featured production quality compiler, on the other hand, will be quite the challenge. The rough edges on the architecture are very rough indeed from a compiler’s perspective.
Microchip supplies a port of GCC for the architecture which, while somewhat dated, is robust and well maintained. Even if the compiler itself isn’t suitable for your needs, I would highly recommend having a look at it, both the documentation and the source code, for more in depth background. The source code should be available on Microchip’s web site. If you have any trouble locating it, or just have some questions about the architecture, compiler, or what-have-you, contacting the Microchip compiler team would be a good way to go. They’re good folks.
Regards,
-Jim