llgo update #14

Ahoy there, mateys!

It's been three months since our last correspondence. Apologies for the negligence. I've been busy, as usual, but it's more self-inflicted than usual. I've taken up a new role at Canonical, working on Juju. I'm really excited about Juju (both the concept and realisation), and the fact that it's written in Go is icing on the cake. Working remotely is taking some getting used to, but so far it's been pretty swell. Anyway, you didn't come here to read about that, did you?

I'm still working on llgo in the background, quietly prodding it along towards the 0.1 milestone. There's just one big ticket item left, and that's partially done now: channels. I've just finished porting the basics of channels from gc's standard library to llgo's runtime. That doesn't include select, which is entirely missing. When that's done, I'll be content to release 0.1.

So what's new since last time?

• There's a new llgo-build tool, which takes the pain out of building packages and programs with llgo and the LLVM toolchain. Just run "llgo-build <package>", and you'll either build and install a package, or build a program in the working directory. There's no freshness checking, so you're currently required to manually build all dependencies before building a program.
• Simplified building against PNaCl: llgo-dist now accepts a "-pepper" option, which points to a NaCl SDK.
• Implemented support for map literals.
• Implemented complex number arithmetic.
• Implemented channels (apart from anything select-related)
• Numerous bug fixes.

In my previous post I talked about having implemented panic/recover, and having implemented them in terms of DWARF exception handling. Well, it looks like PNaCl isn't going to support that, at least initially, so a setjmp/longjmp version is likely inevitable now.

I also said I would be working on a temporary for of cmd/go. I gave up on that, after hitting a few stumbling blocks. I figured it was more important to actually get the compiler and runtime working than get bogged down in the tooling, hence the simpler llgo-build tool.

That's about it! "Feature complete" is getting closer, though lots of things still don't work very nicely. Still no garbage collection, no proper escape analysis, etc. Those will come in time.

For now, though... I think I might go catch up on some sleep.

llgo on Go 1.1

Hi folks,

(For those of you coming from HN/Twitter/elsewhere, this is a post about llgo. llgo is an LLVM frontend for the Go programming language).

In my last post I mentioned that work had began on moving to Go 1.1 compatibility; this has been my primary focus since then. Since Go 1.1 is now released (woohoo!), I've gone ahead and pulled all the changes back into the master branch on GitHub. If you want to play around, you can do the following:

1. Get Go 1.1.
2. Get Clang and LLVM (I've tested with 3.2, Ubuntu x86-64). Make sure llvm-config is in your $PATH.
3. Run "go get github.com/axw/llgo/cmd/llgo-dist"
4. Run "llgo-dist". This will install llgo into $GOBIN, and build the runtime.

The biggest new feature would have to be: defer, panic and recover (I'm lumping them together as they're closely related). I've implemented them on top of LLVM's exception handling support. The panic and recover functions are currently tied to DWARF exception handling, though it's simple enough that it should be feasible to use setjmp/longjmp on platforms where DWARF exception handling isn't viable.

Aside from that, there's some new bits and bobs:

• Method sets are handled properly now (or at least not completely wrong like before). This means you can use a embedded types' methods to satisfy an interface.
• "return" requirements are now checked by go/types
• cap() is now implemented for slices.
• llgo-dist now builds against the LLVM static libraries (if available) by default now, with an option for building against the shared libraries.

I'll be working on a temporary fork of cmd/go to build programs with llgo, while a long-term solution is figured out. I'd also like to get PNaCl integration working again, given that its release is nigh.

That's all for now.

llgo update #12

Oh my, it's been a while.

In my previous post I wrote about llgo and PNaCl. I haven't had much time to play with PNaCl recently, but I have been prodding llgo along. In February, my wife gave birth to our son, Jeremy, so naturally I've been busy. But anyway, let's talk about what has been happening in llgo. Quick, while he's sleeping!

Feature-wise, there's nothing terribly exciting going on. Without getting too boring, what's new is:

• A new "go1.1" branch in the Git repository. The go1.1 branch aims to make llgo compatible with the Go tip, and will replace the master branch when Go 1.1 is released.
• Removed llgo/types (a fork of the old exp/types package), and moved to go/types.
• Updated runtime type representations to match those from gc's tip (thanks to minux for initiating this effort).
• Updated to use architecture-specific size for "int" (same as uintptr).
• Changed function representation to be a pair of pointers, to avoid trampolines/runtime code generation for closures. The rationale is the same as for rsc's proposal for Go 1.1; using runtime code generation limits the environments that Go can run in (e.g. PNaCl).
• A slew of bug fixes and minor enhancements.

The go/types change in particular was not a small one, but llgo came out much better at the end. As of the most recent go/types commits, llgo now passes all of its tests in the go1.1 branch. Now I can get back to implementing features again.

That's about all there is to report. It has been suggested that I set up some milestones in the GitHub project; I will spend a bit of time coming up with what I think are the bare essentials for a 0.1 release, and what would constitute future releases and so on.

One last thing: there's a new(ish) llgo-dev mailing list. If you want to get involved, or just lurk, come and join the party.

Until next time.