llvm dev - Sep 2013 - [LLVMdev] [JOB AD] Paid project proposal - LLVM backend for an n-address code machine

== 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.

The job:

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.

Details follow:

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)

and here:

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  
priority).

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  
translation.

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  
frontend.
- Numerous examples of handwritten NAC programs.
- A NAC-to-C backend tool to help you with evaluating the behavior NAC  
programs.



Yours sincerely,
Nikolaos Kavvadias <nkavvadias at ajaxcompilers.com>
CEO
Ajax Compilers
Athens, Greece