seeking a mailing list for llvm ports

"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?

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

   -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?

Regards

PTB

“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//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. Etc.