[LLVMdev] mips 16 port available

[Sean Silva]

> 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