Mark R V Murray via llvm-dev
2018-Dec-31 12:07 UTC
[llvm-dev] Strategy for writing a new LLVM backend?
Hi 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! I'm getting very tied up in the implementation details, hence my request for advice. 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. Where it would be nice to have (e.g.) ADDA 1,X ADDB $20FF ADDD #23 ADDA [123,Y] ... or ... NEG addr NEGA NEG [3,Y] ... 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. 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). 1) Am I making sense, and is my approach so far sane? 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? 2) Using MSP430 as a base, how do I force the TwoAddressInstructionPass to be run at the right time? Thanks and happy new year to all! M -- Mark R V Murray
Jatin Bhateja via llvm-dev
2018-Dec-31 18:30 UTC
[llvm-dev] Strategy for writing a new LLVM backend?
Hi Mark, To deal with multiple addressing mode instruction selection for same opcodes following can be done :- 1/ Define different instruction patterns for a give operator DAG node with different operands and emitting different asm string. 2/ Define custom DAG nodes during target lowering (TargetLowering::LowerOperation) and write a dumb selector to emit necessary asm strings for custom nodes. 3/ Take a cue from X86 ComplexPattern where pattern matching for addressing mode is done using explicit C++ code. Hope this helps. Cheers, Jatin On Monday, December 31, 2018, Mark R V Murray via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi > > 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! > > I'm getting very tied up in the implementation details, hence my request > for advice. > > 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. > > Where it would be nice to have (e.g.) > > ADDA 1,X > ADDB $20FF > ADDD #23 > ADDA [123,Y] > > ... or ... > > NEG addr > NEGA > NEG [3,Y] > > ... 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. > > 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). > > 1) Am I making sense, and is my approach so far sane? > 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? > > 2) Using MSP430 as a base, how do I force the TwoAddressInstructionPass to > be run at the right time? > > Thanks and happy new year to all! > > M > -- > Mark R V Murray > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >On Monday, December 31, 2018, Mark R V Murray via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi > > 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! > > I'm getting very tied up in the implementation details, hence my request > for advice. > > 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. > > Where it would be nice to have (e.g.) > > ADDA 1,X > ADDB $20FF > ADDD #23 > ADDA [123,Y] > > ... or ... > > NEG addr > NEGA > NEG [3,Y] > > ... 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. > > 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). > > 1) Am I making sense, and is my approach so far sane? > 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? > > 2) Using MSP430 as a base, how do I force the TwoAddressInstructionPass to > be run at the right time? > > Thanks and happy new year to all! > > M > -- > Mark R V Murray > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190101/069e46d1/attachment.html>