<div dir="auto"><div dir="auto"><div dir="auto">Hi Mark,<div><br></div><div>To deal with multiple addressing mode instruction selection for same opcodes following can be done :-</div><div><br></div><div>1/ Define different instruction patterns for a give operator DAG node with different operands and  emitting different asm string. </div><div><br></div><div>2/ Define custom DAG nodes during target lowering (TargetLowering::LowerOperation) and write a dumb selector to emit necessary asm strings for custom nodes. </div><div><br></div><div>3/ Take a cue from X86 ComplexPattern where pattern matching for addressing mode is done using explicit C++ code. </div><div dir="auto"><br></div><div dir="auto">Hope this helps.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Jatin </div></div><div><br></div><div><br></div><div><br></div><div><br><br>On Monday, December 31, 2018, Mark R V Murray via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I'm playing around with an LLVM backend for the MC6809 8-bit processor. This is both so that I can learn LLVM and I would like a halfway-decent cross-compiler for that processor. Yes, I am a sucker for punishment!<br>
<br>
I'm getting very tied up in the implementation details, hence my request for advice.<br>
<br>
The MC6809 instruction set is very clean at the assembly language level, but the binary opcodes are not so helpful. Some instructions have a prefix byte, and due to the rich addressing modes, the instructions are very variable in length, and not necessarily neat or consistent. There is only very limited scope for packing known bit patterns like a a $src or $dst field.<br>
<br>
Where it would be nice to have (e.g.)<br>
<br>
        ADDA    1,X<br>
        ADDB    $20FF<br>
        ADDD    #23<br>
        ADDA    [123,Y]<br>
<br>
... or ...<br>
<br>
        NEG     addr<br>
        NEGA<br>
        NEG     [3,Y]<br>
<br>
... all matched with (say) "[(set $dst, (<opcode> $dst, $src)),(set $dst, (add $dst, $imm))]" - note the 2-argument mode - constructing the opcodes at the same time appears to be not possible. I think I can't do instruction matching this way. Multiclasses don't seem to quite get there either.<br>
<br>
So far I've got the whole instruction set in MC6809Instr(Format|Info).td (the indexed modes need some work as the postbytes are messy), without any matching, and I suspect I'll need to do all the instruction selection in the MC6809ISel* files. All the different types (immediate, indexed, inherent etc are there as separate instructions ordered by primary opcode (plus prefix byte if there is one).<br>
<br>
1) Am I making sense, and is my approach so far sane?<br>
1a) Once I have defined all the instructions, will grouping them by function and selecting the right one(s) in C++ code in the *ISel*.cpp files make more sense?<br>
<br>
2) Using MSP430 as a base, how do I force the TwoAddressInstructionPass to be run at the right time?<br>
<br>
Thanks and happy new year to all!<br>
<br>
M<br>
-- <br>
Mark R V Murray<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div><div><br></div><div><br></div><div><br></div><div><br><br>On Monday, December 31, 2018, Mark R V Murray via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I'm playing around with an LLVM backend for the MC6809 8-bit processor. This is both so that I can learn LLVM and I would like a halfway-decent cross-compiler for that processor. Yes, I am a sucker for punishment!<br>
<br>
I'm getting very tied up in the implementation details, hence my request for advice.<br>
<br>
The MC6809 instruction set is very clean at the assembly language level, but the binary opcodes are not so helpful. Some instructions have a prefix byte, and due to the rich addressing modes, the instructions are very variable in length, and not necessarily neat or consistent. There is only very limited scope for packing known bit patterns like a a $src or $dst field.<br>
<br>
Where it would be nice to have (e.g.)<br>
<br>
        ADDA    1,X<br>
        ADDB    $20FF<br>
        ADDD    #23<br>
        ADDA    [123,Y]<br>
<br>
... or ...<br>
<br>
        NEG     addr<br>
        NEGA<br>
        NEG     [3,Y]<br>
<br>
... all matched with (say) "[(set $dst, (<opcode> $dst, $src)),(set $dst, (add $dst, $imm))]" - note the 2-argument mode - constructing the opcodes at the same time appears to be not possible. I think I can't do instruction matching this way. Multiclasses don't seem to quite get there either.<br>
<br>
So far I've got the whole instruction set in MC6809Instr(Format|Info).td (the indexed modes need some work as the postbytes are messy), without any matching, and I suspect I'll need to do all the instruction selection in the MC6809ISel* files. All the different types (immediate, indexed, inherent etc are there as separate instructions ordered by primary opcode (plus prefix byte if there is one).<br>
<br>
1) Am I making sense, and is my approach so far sane?<br>
1a) Once I have defined all the instructions, will grouping them by function and selecting the right one(s) in C++ code in the *ISel*.cpp files make more sense?<br>
<br>
2) Using MSP430 as a base, how do I force the TwoAddressInstructionPass to be run at the right time?<br>
<br>
Thanks and happy new year to all!<br>
<br>
M<br>
-- <br>
Mark R V Murray<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>