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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110510/3a823231/attachment.html>
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>
Hi, I think this is a very ashamed question
I have modified the version of the MSP430, after many problems it compiled,
now I want to see is the changes generate what I want, but I don't know how
for example with llc -march msp430 foo.ll -o newfoo.ll generates a file for
the msp430 and actually did it.
but I want to load my changes the --load option is supposed to do that, but
the only new files that the compiling process did are:
llvm-2.8/Release/lib/libLLVMMSP430Info.a
llvm-2.8/Release/lib/libLLVMMSP430AsmPrinter.a
llvm-2.8/Release/lib/libLLVMMSP430CodeGen.a
and none of them work.
is It possible to load a backend as a new pass, for practicing I have worked
on create passes like deadcode analysis and it is possible to load them with
opt, but I don't know how to generate code for my new backend. Thank you.
Best Regards
Roberto
2011/5/10 Jim Grosbach <grosbach at apple.com>
> 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/20110511/561ec712/attachment.html>
2011/5/10 Jim Grosbach <grosbach at apple.com>> Hi Roberto, > > That said, that does mean that LLVM is a much more reasonable fit to target > the PIC24 (and dsPIC) than it is for PIC16. > > > >Hi Roberto, PIC16 was full of challenges and we had to do very unconventional things to get it generate PIC16 code. One of the most difficult thing was that we wanted 16-bit pointers which is an 'illegal' type size on the target. There were so many more things other than that. You may find some of the discussions in the archives. Having said that, PIC24 and PIC16 are entirely different and PIC24 might be more suited for LLVM port. - sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110514/ee2d995e/attachment.html>