[LLVMdev] llvm backend

[Jim Grosbach]

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

On May 10, 2011, at 7:08 AM, Roberto Rodríguez-Rodríguez wrote:

> I have been analyzing the implementation for some backend (PIC16, MIPS, SPARC and MSP430) my main problem is that they are so much different, I mean obviously they are describing different architectures, but the file structure is not the same. So it is difficult to get a pattern.
> 
> I have checked the available documentation files, also the video from Cardoso about how to write a backend for the MIPS but the problem is the same, all the documention said what the files have to contain but not the details about write them.
> 
> I need to write a backend for the PIC24, our processor is based on it, so I started analyzing the files for the implementation of the PIC16, all was ok until I analyzed the files PIC16ILowering.cpp and PICInstrInfo.td, this files have defined many things like SDTypeProfile and SDNode and other things I don't have idea from where they come. I mean I tried to find this info from other files, llvm.org and google and no idea. 
> 
> I have checked the documentation, after read it I thought the implementation will be a not to difficult job, but analyzing the files I realized I didn't have idea about the magnitude of the problem. 
> 
> Any suggestion will be appreciated. 
> 
> Best Regards
>              Roberto
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110510/9ba140da/attachment.html>