It's been a while, so I thought I'd give a little status update ;)
A few months back, nlvm compiled itself for the first time, and now it did so again, but this time with GC enabled! With that, most core features except threads are implemented - in other words, there's a fair chance you'll be able to compile your stuff with it. Along the line, many other fixes have gone in and it's now running on llvm 3.9 as well.
There are of course many other things that could be done as well:
Give it a spin - find a bug - fix a bug - sky's the limit ;) let me know if it works too!
Sure. nlvm generates bitcode which can either be translated to machine code statically (creating an executable) or run directly. If you use the -c option nlvm will write out the bitcode to a file, llvm has a just-in-time compiler called lli that runs it without creating a binary (though there are issues in the Nim standard library that need to be fixed before everything can run), and nlvm could do the same easily because everything in llvm is available as a library.
Relevant llvm tutorial link: http://llvm.org/docs/tutorial/LangImpl04.html
With your backend, would it be possible, to also compile nimscript and macro code to native istructions and throw out the distinction of runtime and compiletime behavior?
Even if you are not using C as an intermediate step it is still essential to distinguish between compile time and run time behavior.
There are compilers for other languages that compile/assemble/link on the fly into RAM, then write out the image when done.
If Nim were to evolve into something like that, it would still be necessary to make runtime and compiletime separate.
Nimscript is essentially "compile time only" which is why it does not have macros (as macros are for what will be the run time code). Nim would need something more than a new backend to compile to native code and use that doing compile time.
ah. tbh, I'm not quite sure what nimscript does, so I probably misunderstood something. thought it was simply running nim code using included vm (which also happens to be used when compiling macros etc), and that limitations stem from the vm being incomplete. The llvm equivalent of that would be to use the jit, in which case there is no limitation that I know of - it should be possible to both evaluate compile time stuff and run the result with lli/jit, and the full language should be available. That's not implemented in nlvm though, it still uses the internal vm during compile, but I see no reason why it wouldn't work - maybe that's the next step, replace vm with llvm ;)
nlvm still cannot produce optimized binaries, so can't compare full optimized bootstrap. Here's a sample though, all from my 8-core laptop:
compile nlvm, nim compiled with -d:release:
time nim c "-l:-lLLVM-3.9" "--clibdir:/home/arnetheduck/src/llvm-3.9.0.src/rel/lib" "-l:-Xlinker '-rpath=/home/arnetheduck/src/llvm-3.9.0.src/rel/lib'" nlvm
real 0m11.752s
user 0m31.495s
sys 0m6.248s
compile nlvm, nlvm compiled by nim with -d:release:
time nlvm -o:nlvm.self "-l:-lLLVM-3.9" "--clibdir:/home/arnetheduck/src/llvm-3.9.0.src/rel/lib" "-l:-Xlinker '-rpath=/home/arnetheduck/src/llvm-3.9.0.src/rel/lib'" c nlvm
real 0m8.830s
user 0m8.641s
sys 0m0.186s
compile nlvm, nim compiled without -d:release
time nim c "-l:-lLLVM-3.9" "--clibdir:/home/arnetheduck/src/llvm-3.9.0.src/rel/lib" "-l:-Xlinker '-rpath=/home/arnetheduck/src/llvm-3.9.0.src/rel/lib'" nlvm
real 0m23.345s
user 0m42.476s
sys 0m5.932s
compile nlvm, nlvm compiled by nim without -d:release
time nlvm -o:nlvm.self "-l:-lLLVM-3.9" "--clibdir:/home/arnetheduck/src/llvm-3.9.0.src/rel/lib" "-l:-Xlinker '-rpath=/home/arnetheduck/src/llvm-3.9.0.src/rel/lib'" c nlvm
real 0m22.924s
user 0m22.730s
sys 0m0.191s
time ./nlvm.self -o:xxx "-l:-lLLVM-3.9" "--clibdir:/home/arnetheduck/src/llvm-3.9.0.src/rel/lib" "-l:-Xlinker '-rpath=/home/arnetheduck/src/llvm-3.9.0.src/rel/lib'" c nlvm
real 0m15.053s
user 0m14.879s
sys 0m0.171s
these numbers are all using the release version of llvm 3.9 (if you follow the README instructions, you'll be using a debug LLVM which is much slower). for nim, CC=gcc-6.x.