[LLVMdev] mips 16 port available

[Reed Kotler]

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