I remember a letter from some time ago saying that LLVM IR format is private to specific version of LLVM, and is not guaranteed to be compatible with other versions in the future or in the past. Does this announcement mean that is not the case anymore, and LLVM IR is backwards compatible now?

There's IR assembly (the human readable format) and the bitcode format. There are no compatability guarantees for the assembly but new LLVM versions can read the old bitcode inside the same major version.

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compa...

LLVM is a great tool, but I've had trouble in the past with version compatibility. I wrote a compiler that used LLVM as a backend (I used LLVM versions 3.4-3.6). The problem was that each minor version of LLVM slightly changed the API. It was things like removing parameters from methods, renaming methods, removing the need for some methods completely, or adding/removing some static-link libraries. If you only wish your tool to be compatible with a single version of LLVM, its not a problem, but attempting to support a selection of minor versions ended up being a pain. These minor versions would come out 3-4 times a year and I would need to find what broke each time, and if there was even an equivalent solution in the new version.

I didn't work on the level of IR, so I didn't come across any problems there, but I wouldn't be surprised if the IR syntax changed slightly across minor versions.

I guess you used the C++ API? There's a C language subset available that has way more stability.

Given that Apple controls that format, even if it were to continue to change in the future, that would not necessarily be an unsurmountable obstacle.

All of LLVM is open source, and the format isn't quite so fluid as GP makes it sound. It should be relatively trivial for one versed in the LLVM codebase to grok the current features of the bitcode.

That said, as long as you keep an indication of the LLVM version that your bitcode was generated with, I really don't see a problem with fluid bitcode specs.

I'm quite sure it is LLVM bitcode. Btw, the creator of LLVM is the same guy who created Swift, i.e. Chris Lattner.

> I really think that LLVM is one of the best things to happen to computer science in a long, long time.

While LLVM is a great compiler toolchain, it is no different than many other JIT/AOT frameworks since the old mainframe days.

What you are suggesting is how OS/400 is adapted to new CPUs.

The major difference with LLVM is modularity. If you create a new language frontend, you get all LLVM's CPU support "for free." If you create a new processor backend, you get all LLVM's frontend languages "for free."

This has interesting consequences such as retargeting anything from the frontend to anything on the backend. I'd venture a wager that in the old mainframe days, the monolithic nature of a JIT would not have been friendly to a porting campaign.

Again, I don't see how this is any different from mainframes.

On OS/400 all executables are bytecode (TIMI) with the JIT on the kernel.

When AS/400 changed processors, the programs continued to execute as always, no change required. All languages got the new processor for free.

Any compiler that targets TIMI, gets OS/400 support for free.

The difference is that they had to port the entire JIT to the new processor. With LLVM, you just need the backend components that represent the CPU. Granted, from an app developer's perspective, this is not really relevant because they're targeting a VM; where the VM runs, their apps run.

Distinction without difference. These two components are essentially equivalent in scope.

Any resource in how look the TIMI bytecode? Could be usefull for a x86 interpreter?

There isn't much available. IBM doesn't disclose much about it.

However here are some links about OS/400, nowadays known as System i.

http://koeln.ccc.de/ablage/as400/as400concepts.xml

http://de.slideshare.net/tvlooy/introduction-to-the-ibm-as40...

A story about the two times TIMI actually changed:

http://www.itjungle.com/tfh/tfh082007-story01.html

Some Redbooks about ILE, which sits on top of TIMI

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c415...

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c415...

All of them can be found at

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/rzaqhindex...

My limited understanding is that LLVM bitcode doesn't insulate you completely from the ABI/platform differences, e.g. between 32- and 64-bit. So I wonder if they'll be "fat" binaries.

Coincidentally, there's been a bunch of stuff on the mailing lists recently about embedding bitcode in object files in order to support link time optimisation.

You are correct about the 32-bit, and furthermore correct about ABI (LLVM code targeted at Mac wouldn't work on Linux without a lot of work and inefficiencies, and it's not obvious how to fix that).

LLVM IR files are already target specific. There are some targets like Google NaCl that work on several architectures, but I doubt Apple wants to go that way.