I have pushed almost all the changes for the mips16 port and it passes about 90% of the single source tests from test-suite. It is still an experimental port but I am working hard to finish up the last details as soon as possible. Some things that are incomplete: 1) It is using soft float at this time. I did not like the gcc mips16 floating point design and will do something much better for llvm but I need to make some non trivial changes in the target independent part of llvm and will do that after I pass all the tests. Mips16 does not have floating point instructions and you have to switch to mips32 mode to do that. 2) Currently only pic is supported. It will be easy to add non pic, I just have not had the time. 3) Large frames (>15 bits size) are not supported yet. I hope to finish this up this week. 4) Exception handling is working but I'm waiting on approval of a patch that includes a target independent patch for part of LLVM. 5) Direct object emitter not working with it yet. For those doing new ports, you might be interested to study how I did the td files for mips16. There is still some cleanup I will do but essentially I have cleanly layered the abstraction into four layers: 1) machine formats 2) assembly syntax 3) instructions (none with patterns) 4) patterns. At many levels, it seemed to me much cleaner to make these distinct abstraction layers, especially separating the definition of instructions from the selection of DAG patterns. There are a few shortcomings that I would like to address in tablegen related to this approach and will do that when I'm done with this base port. 1) Enable the Pattern class (currently only Pat and ComplexPattern work in tablegen). 2) Add some more macro/template like capabilities for patterns as currently exist for instructions.
> For those doing new ports, you might be interested to study how I did the td > files for mips16. There is still some cleanup I will do but essentially I > have cleanly layered the abstraction into four layers: > 1) machine formats > 2) assembly syntax > 3) instructions (none with patterns) > 4) patterns.Maybe you could write a bit more in-depth about this? <http://www.llvm.org/docs/SphinxQuickstartTemplate.html> -- Sean Silva On Mon, Nov 5, 2012 at 12:50 PM, Reed Kotler <rkotler at mips.com> wrote:> I have pushed almost all the changes for the mips16 port and it passes about > 90% of the single source tests from test-suite. It is still an experimental > port but I am working hard to finish up the last details as soon as > possible. > > Some things that are incomplete: > 1) It is using soft float at this time. I did not like the gcc mips16 > floating point design and will do something much better for llvm but I need > to make some non trivial changes in the target independent > part of llvm and will do that after I pass all the tests. Mips16 does not > have floating point instructions and you have to switch to mips32 mode to do > that. > 2) Currently only pic is supported. It will be easy to add non pic, I just > have not had the time. > 3) Large frames (>15 bits size) are not supported yet. I hope to finish this > up this week. > 4) Exception handling is working but I'm waiting on approval of a patch that > includes a target independent patch for part of LLVM. > 5) Direct object emitter not working with it yet. > > For those doing new ports, you might be interested to study how I did the td > files for mips16. There is still some cleanup I will do but essentially I > have cleanly layered the abstraction into four layers: > 1) machine formats > 2) assembly syntax > 3) instructions (none with patterns) > 4) patterns. > > At many levels, it seemed to me much cleaner to make these distinct > abstraction layers, especially separating the definition of instructions > from the selection of DAG patterns. > > There are a few shortcomings that I would like to address in tablegen > related to this approach and will do that when I'm done with this base port. > 1) Enable the Pattern class (currently only Pat and ComplexPattern work in > tablegen). > 2) Add some more macro/template like capabilities for patterns as currently > exist for instructions. > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Okay. I will. Good idea. Didn't know about this quick start template. Reed On 11/05/2012 10:21 AM, Sean Silva wrote:>> For those doing new ports, you might be interested to study how I did the td >> files for mips16. There is still some cleanup I will do but essentially I >> have cleanly layered the abstraction into four layers: >> 1) machine formats >> 2) assembly syntax >> 3) instructions (none with patterns) >> 4) patterns. > > Maybe you could write a bit more in-depth about this? > > <http://www.llvm.org/docs/SphinxQuickstartTemplate.html> > > -- Sean Silva > > On Mon, Nov 5, 2012 at 12:50 PM, Reed Kotler <rkotler at mips.com> wrote: >> I have pushed almost all the changes for the mips16 port and it passes about >> 90% of the single source tests from test-suite. It is still an experimental >> port but I am working hard to finish up the last details as soon as >> possible. >> >> Some things that are incomplete: >> 1) It is using soft float at this time. I did not like the gcc mips16 >> floating point design and will do something much better for llvm but I need >> to make some non trivial changes in the target independent >> part of llvm and will do that after I pass all the tests. Mips16 does not >> have floating point instructions and you have to switch to mips32 mode to do >> that. >> 2) Currently only pic is supported. It will be easy to add non pic, I just >> have not had the time. >> 3) Large frames (>15 bits size) are not supported yet. I hope to finish this >> up this week. >> 4) Exception handling is working but I'm waiting on approval of a patch that >> includes a target independent patch for part of LLVM. >> 5) Direct object emitter not working with it yet. >> >> For those doing new ports, you might be interested to study how I did the td >> files for mips16. There is still some cleanup I will do but essentially I >> have cleanly layered the abstraction into four layers: >> 1) machine formats >> 2) assembly syntax >> 3) instructions (none with patterns) >> 4) patterns. >> >> At many levels, it seemed to me much cleaner to make these distinct >> abstraction layers, especially separating the definition of instructions >> from the selection of DAG patterns. >> >> There are a few shortcomings that I would like to address in tablegen >> related to this approach and will do that when I'm done with this base port. >> 1) Enable the Pattern class (currently only Pat and ComplexPattern work in >> tablegen). >> 2) Add some more macro/template like capabilities for patterns as currently >> exist for instructions. >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev