llvm dev - Jan 2013 - [LLVMdev] Initial thoughts on an LLVM backend for N-address generic assembly

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?

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

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

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?
Hi Nikolaos,

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
lib/Target/**/*.td).

As for your other questions, I'm no expert, but you might want to take
a look at the available tutorials
(http://llvm.org/docs/WritingAnLLVMBackend.html and
http://jonathan2251.github.com/lbd/).

-- 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
> it?
>
> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Thu, Jan 24, 2013 at 7:20 AM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>wrote:
> 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?
>
> Hi Nikolaos,
>
> 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
> lib/Target/**/*.td).
>
It really depends on your goals and the abstractions provided by the target
IR.  For NVPTX, we use a traditional LLVM back-end approach (using TableGen
and the SelectionDAG/MachineInstr/MC infrastructure) because PTX is
low-level enough to be treated as an assembly language.  There are some
higher-level features available in the language, but we do not use those.
If your IR is more like LLVM IR, then it may make sense to do some kind of
direct translation from LLVM IR to your IR and bypass the traditional
codegen approach.

Another point to consider is how much optimization you want.  For PTX, we
have to walk a fine line compared to other back-ends because PTX is not the
machine ISA.  A separate assembler is used to convert to the real machine
ISA, and that assembler performs optimizations of its own!  We want to
optimize the PTX we generate, but we also do not want to prevent
optimizations that may be performed by the assembler.  If your IR is meant
for optimization passes, then it may not make sense to perform all of the
back-end optimizations available through LLVM, but just use the middle-end
optimizations performed on LLVM IR directly.

>
> As for your other questions, I'm no expert, but you might want to take
> a look at the available tutorials
> (http://llvm.org/docs/WritingAnLLVMBackend.html and
> http://jonathan2251.github.com/lbd/).
>
> -- 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
> > it?
> >
> > 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
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130124/083b11df/attachment.html>

Hi Ahmed
> Hi Nikolaos,
>
> 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
> lib/Target/**/*.td).
Thanks for the tip, so I remove this from my short list.
> As for your other questions, I'm no expert, but you might want to take
> a look at the available tutorials
> (http://llvm.org/docs/WritingAnLLVMBackend.html and
> http://jonathan2251.github.com/lbd/).
I also had an eye on this tutorial. It seems to go to extensive detail  
for a backend of the "CPU0" architecture which appears to be a  
reasonable sample RISC.

PTX is also interesting since it is a close fit due to the fact that  
it is a virtual machine target, as NAC (N-Address Code).

Best regards
Nikolaos Kavvadias