[LLVMdev] [JOB AD] Paid project proposal - LLVM backend for an n-address code machine
nkavv at physics.auth.gr
nkavv at physics.auth.gr
Thu Sep 12 00:25:37 PDT 2013
== SMALL JOB POSTING ==
To whom it may concern,
I am the CEO and co-founder of Ajax Compilers
(http://www.ajaxcompilers.com), an EDA startup established in Jan. 2012.
We are in urgent need of an LLVM developer/specialist/guru for a
specific short term, full-time commercial project.
Please let us know within the following few days if you are interested
and willing to undertake the project.
The task is to develop an LLVM backend for our in-house typed-assembly
language named NAC (N-Address Code). The backend should be able to
translate LLVM IR to NAC. NAC is both an abstract machine as well as
an intermediate representation for most of our in-house tools. A
manual of the NAC programming language can be found here:
http://www.nkavvadias.com/hercules/nac-refman.html (HTML format)
http://www.nkavvadias.com/hercules/nac-refman.pdf (PDF format).
The developer will be required to:
1) Develop the backend as part of the LLVM 3.3 version (latest
release) or the current mainline (which ever is deemed more
appropriate). You will be required to deliver all the necessary code,
and transfer copyright to Ajax Compilers. You will be requested to not
disclose the code to any third party or reuse it for your own
projects. These requirements will all be described in the context of a
legal document (contract + NDA). Further, you will be requested to not
use any code repository allowing public access.
2) Translate valid LLVM IR to NAC. Please note that NAC: a) does not
support structs and unions, b) arrays are single-dimensional. For this
reason you will need to use the LLVM infrastructure for struct/union
decomposition and array flattening. This is also the situation for
classic hardware targets, e.g. RISC machines. On the other side, NAC
supports custom floating-point arithmetic, so both float and double
arithmetic should be supported (long doubles is not an immediate
3) In case that this is mandatory and no other alternative exists,
make suggestions for updating the NAC specification in order to better
match the LLVM IR.
4) We expect that the working NAC backend will be able to process
realistic, large-scale ANSI/ISO C codes. We suggest that you use the
CHStone test suite: http://www.ertl.jp/chstone/ for evaluation; all
these codes should produce valid NAC. Please use clang for C-to-LLVM
You may choose to use the tblgen tool for backend development. Among
the existing LLVM backends in the official release, the PTX backend
may be considered somewhat close to NAC since it is an "abstract"
machine as well. On the other side, the approach used by the LLVM 3.0
C backend (custom backend not using tblgen) or the up-to-date C++
(Cpp) backend may also be viable.
In case you are interested:
1) Please let us know of your flat rate for the entire project.
2) We expect that you will work full-time (100%) or near full-time
(75%) on the LLVM-NAC project.
3) Give us your estimate for the project duration. Our own educated
guess is that for an LLVM expert, NAC backend development will require
something between 6 to 12 weeks. Thus the proposed contract is for a 2
or 3 month duration. However, this can also be negotiated.
We can also supply you with additional helper materials and tools such as:
- EBNF NAC grammar.
- NAC yacc/bison grammar.
- NAC lex/flex scanner.
- NAC grammar for the Gold Parsing System.
- TXL grammar for NAC.
- Numerous examples of C code translated to NAC using our prototype C
- Numerous examples of handwritten NAC programs.
- A NAC-to-C backend tool to help you with evaluating the behavior NAC
Nikolaos Kavvadias <nkavvadias at ajaxcompilers.com>
More information about the llvm-dev