No Compiler – On LLVM, and writing software without a compiler

193 点作者 btrask大约 9 年前

14 条评论

pcwalton大约 9 年前

> And actually we’re now entering a world where at minimum supporting LLVM as a backend option is mandatory.I would have said this too a few years ago, but Go is a huge counterexample. It's become very popular without using LLVM, and the compiler that does use a mature, optimizing backend (gccgo) doesn't get nearly as much use as the Plan 9-based one.I should also mention that increasingly it's become popular to have a mid-level IR that you lower the AST to before lowering to LLVM IR. GHC does it, Swift is doing it, and Rust is working on doing it. The reasons are (a) you can do language-specific optimizations like devirtualization, which are often pretty hard to do in LLVM; (b) going from AST to LLVM IR is often a big, messy leap for any language that isn't C.

评论 #11222395 未加载

评论 #11223512 未加载

评论 #11222722 未加载

评论 #11223041 未加载

评论 #11223477 未加载

评论 #11226232 未加载

erichocean大约 9 年前

You may be better off building up the LLVM IR as text, vs. using the FFI builder. (If you want/need type safety as opposed to just waiting for the LLVM verifier to tell you what went wrong, you could write the builder in Lua.)Here's a link with a Python example (along with a justification for this approach): <a href="http://eli.thegreenplace.net/2015/building-and-using-llvmlite-a-basic-example/" rel="nofollow">http://eli.thegreenplace.net/2015/building-and-using-llvmlit...</a>

drmeister大约 9 年前

So I've done basically the same thing with a few differences: (1) I chose Common Lisp as the language I would implement (2) I used C++ template programming to automatically generate wrappers for C++ library functions (like boost::python and luabind) so that I could expose C++ functions directly to Common Lisp. That allowed me to use the llvm C++ API directly.The project is called clasp -> github.com/drmeister/clasp Send me a message - we should talk and compare notes.

vbit大约 9 年前

Instead of generate LLVM code, you could instead generate 'typed Lua' using Lua as a metaprogramming language. Then the 'typed Lua' can get compiled down by LLVM into object code.This is what <a href="http://terralang.org" rel="nofollow">http://terralang.org</a> does.

评论 #11221600 未加载

daniel-kun大约 9 年前

Been there, done that.See <a href="https://github.com/daniel-kun/omni" rel="nofollow">https://github.com/daniel-kun/omni</a> (look at the little gif in the “Status Quo” section, it will say more than 100 words).I have the “Code Model” (that is what I call the AST, because there is no Syntax) up for a very little, C-like language, and I have a frontend that can manipulate parts of it. However, these are not yet combined, and I stopped working on it because I am in the middle of transforming my efforts into a Web App. This will allow you to edit and run a code model in your browser, and download a compiled binary when you are finished. Btw., you will be able to link code elements such as classes to online-ressources such as a task tracker, a diagram, a mindmap, etc. to have the whole ALM process embedded into your code base.Sounds good? Sounds good to me.

smaddox大约 9 年前

Interesting article. Looking at the code, it's pretty clear that this is not a particularly practical approach, but I think it points in the direction of where language design should head. Abstractions shouldn't be forced, unless absolutely necessary; forced abstractions lead to inefficiency.I've been working on a related concept, but more along the lines of developing a low-level IR (LLIR) and corresponding syntax that allows direct coding in the LLIR. It would essentially be a portable assembly language. The LLIR could be then be compiled down to machine code for different architectures, or even run directly in a VM.This isn't too different from the LLVM concept, except the IR would be a practical programming language, much like assembly. Furthermore, the IR would provide access control primitives (reference capabilities) that most languages do not support, but that are extremely useful for low-overhead secure computing and concurrent computing. These primitives could be especially useful in the design of exokernel OS's, and related applications.

评论 #11222105 未加载

评论 #11222083 未加载

couchand大约 9 年前

I've run into so many of these issues myself, trying to work through the forest of LLVM. The abysmal state of the generated docs and those cryptic segfaults are the bane of my existence.So I started to slap together a little library that gives some order to the madness. I call it petard [0], for reasons that should be obvious if you've heard that word. At the moment I'm focused on JavaScript bindings, but the idea is to build a sensible object-based API that's simple enough to export pure C bindings to make FFI easy.There's currently support for lots of the basics, but some significant issues too (lack of features as well as poor C++ style). Stern memory-management focused pull requests would be very welcome, and feature additions would be helpful, too.[0]: <a href="https://github.com/couchand/petard" rel="nofollow">https://github.com/couchand/petard</a>

a-dub大约 9 年前

This seems like a fun way to poke around with LLVM but I don't see how this is any easier than writing down a grammar and feeding it into a parser generator..."Writing a parser" sounds really annoying and complicated, but in my admittedly limited experience with ocamlyacc, it was easy peasy and dare I say it, fun!The hard part I guess was defining the language and maybe that's what he's trying to avoid.But even still, scripting around the AST building functions in LLVM and coding directly to them seems way more annoying to me in the long run. (especially the writing programs part)But who knows, maybe I'm missing the point...

评论 #11223373 未加载

评论 #11223495 未加载

评论 #11226444 未加载

barrkel大约 9 年前

There's an enormous lump of complexity that this chap seems to be unaware of: the type system. This is the semantic analysis bit that he seems to think is done by LLVM, but it isn't.It's like he mostly thinks of compilers as turning statements and expressions into executable code, but IMO that's one of the easier bits. Defining how different values interact, what operations are legal and aren't, and the runtime support - this is a lot of work, and in particular, it's different for every language, because it's what makes languages distinct.

评论 #11222933 未加载

benjismith大约 9 年前

This is the most kickass thing I've read all day.

prewett大约 9 年前

Seems like what he really wants is an LLVM assembler.

评论 #11223617 未加载

greydius大约 9 年前

Excellent post highlighting the problem solving skills and tenacity of a talented engineer. Of course, this is also the "duct tape and paper clips" approach to writing software that I certainly would not advocate for production systems.

评论 #11221813 未加载

sklogic大约 9 年前

For everyone here who mentioned building wrappers around llvm-c or llvm c++ api: there is a nice tool for automating this job (and many other similar things), it's called "Clang". Or, more specifically, cindex. It's easy to use Python + cindex to parse LLVM headers and spit out nice wrapper library for your language of choice.And example of this approach: <a href="https://github.com/combinatorylogic/clike/blob/master/llvm-wrapper/rebuild.py" rel="nofollow">https://github.com/combinatorylogic/clike/blob/master/llvm-w...</a>

kungfooman大约 9 年前

I really like the idea, why not hack a scripting engine to add bindings to itself, e.g. in Duktape JavaScript engine. Then a JavaScript function could use the C-API of Duktape to generate AST's at runtime for itself. But I think the VM would be the limit then... support for coroutines etc.