[LLVMdev] Initial thoughts on an LLVM backend for N-address generic assembly
ahmed.bougacha at gmail.com
Thu Jan 24 04:20:12 PST 2013
On Thu, Jan 24, 2013 at 12:46 PM, <nkavv at physics.auth.gr> wrote:
> Hi all,
> i'm just starting out with LLVM (although i've been observing its evolution
> since that first release some years ago :)
> I would like to develop a backend for a generic assembly-like language,
> called NAC (N-Address Code). More info on NAC can be found here:
> http://www.nkavvadias.com/hercules/nac-refman.html (HTML)
> http://www.nkavvadias.com/hercules/nac-refman.pdf (PDF)
> You can consider NAC similar to an LLVM subset for hardware synthesis.
> Although NAC was developed independently, certain decisions taken when
> designing it, may or may not defer from other textual IRs like LLVM or PTX.
> I have a number of questions:
> 1) It seems to me that a template backend either the C backend or NVPTX are
> possible starting points. However, only NVPTX makes use of tblgen which
> removes some burder from the backend developer. I also think that a
> tblgen-based backend like NVPTX is easier to maintain in the long term. What
> do you think?
The C backend (that is by the way deprecated) is the exception rather
than the rule: most targets use TableGen extensively (look at all the
As for your other questions, I'm no expert, but you might want to take
a look at the available tutorials
-- Ahmed Bougacha
> 2) NAC uses the following statement form (for any given statement):
> dst1, dst2, ..., dstm <= op src1, src2, ..., srcn;
> which expresses an operation op with n source operands and m destination
> operands. Do you think that tblgen supports such form or should I sanitize
> 3) The NAC memory model uses separate address spaces per array. A
> general-use stack/heap might also be supported. Should I use dot directives
> to declare each address space in use for a given translation unit/module?
> 4) What is the maximum that I can get from tblgen? Which C++ source files
> cannot be generated by .td files and always have to be coded by hand?
> In the end, source code for the LLVM->NAC backend and a NAC interpreter will
> be released, probably as third-party BSD-licensed tools.
> Best regards
> Nikolaos Kavvadias
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev