[LLVMdev] seeking a mailing list for llvm ports

Jim Grosbach grosbach at apple.com
Mon Apr 27 15:33:01 PDT 2015


> On Apr 27, 2015, at 3:20 PM, Peter T. Breuer <ptb at inv.it.uc3m.es> wrote:
> 
> "Also sprach Jim Grosbach:"
>> out of tree port, you’re in the general right place for LLVM related
>> questions, including about the assembler infrastructure.
> 
> Great!
> 
>> You are correct that the .td files contain most of the information for
>> instructions.  All of it for simple instructions, really.  Those files
>> are used to create .inc files for asm matchers (it’s a bunch of data
>> tables, and a few helper functions) via the tblgen utility.
> 
> Aaaaaah. OK. So the .td files are scanned by a woojah and produce .inc
> files, which get incorporated in other things (parsers, printers, ...).
> Yes, I can see references to the extra instruction I tried defining
> coming through in the build dir in the
> lib/Target/OR1K/OR1KGenAsmMatcher.inc file.
> 
> That's the only place I can see a reference, however. Is that going to
> be it?

Depends on the details of what you’re doing, but for an assembler, that’s pretty much it, yeah.

> 
> 
>> The main assembler functionality is in the lib/MC library of llvm,
>> with target specific bits in lib/Target/<targetname>/AsmParser.  You can
>> start by perusing that code a bit and stepping through the instruction
>> matching.  The llvm-mc utility is handy for this, as it’s a developer
>> tool that provides a no-frills front end to the assembler and
>> disassembler engines.
> 
> At the moment that leaves me a bit cold, as I don't know what llvm-mc
> is for, hence what I might use it for. The "m" in "mc" sounds like
> "meta", so I guess it's a generic engine of some kind. What kind of
> input file I might run it on is a mystery to me at the moment, but I
> see it has some likely looking options
> 

MC == Machine Code.

>   -as-lex                 
> 
> so I guess it can run over an assembler file. OK, I'll try that. Oooh
> .. yes, it does do lexing. I see. I suppose it does more things too,
> per option. I'll check to see if I have done enough to get my extra
> instruction io
> 
> Yes, the lexer is happy. I'll see what else ...
> 
> After adding that one more instruction, which is a "prefix" instruction
> that allows immediate data for a prefixed instruction to be extended
> beyond 16 bits, I would like to change the backend so that
> 
> 1) it recognizes an extra pseudo assembler instruction that puts it in 
>   a special mode, and another that gets it out of it again
> 
> 2) in the special mode, when it sees an assembler instruction with
>   immediate data in, it should emit the machine code for an extra
>   prefix instruction before it.
> 
> Where would I head over to for those increments?
> 

Sounds like you really just need to play around with the codebase and become familiar with it. You’re on the right track, so I wouldn’t worry too much about the details yet. Something like a prefix instruction here may be a bit more complicated, depending on exactly what you want and how the specific back end is structured. To start with, just play around with the tools. Explore the code base. Change some things and see what happens where (like change the mnemonics of existing instructions and see what changes in the output). Read the documentation on llvm.org <http://llvm.org/>. Etc.


> Regards
> 
> PTB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150427/ca5ad06b/attachment.html>


More information about the llvm-dev mailing list