 So, I don't really know who I'm speaking to here. How many people in this room have used Objective-C before? So, there's a little group of GNU step developers at the front, and a few random other people scattered around. So, out of all of you people, how many of you have used Objective-C just on Apple platforms? Okay, so most of you. So, the point of this talk is to say, Objective-C is usable on places that Apple has no interest in at all, isn't doing any work. And this has actually been true for a long time. Objective-C was created in 1986, so it's not a brand new shiny, exciting language. It's been around for a while. And the idea was that if you have a C library and you want to package it for other people to use, you really want to give kind of an abstract interface with some loose coupling and late binding and stuff. And so, Brad Cox wrote a number of papers describing a Lego building model for software. So, you'd have some people who would be responsible for building the Lego bricks, and some people who would be responsible for assembling those bricks into larger structures. And Objective-C was designed for that boundary where you'd have some people working in the C-like bit, and some people working in the small talk-like bit, and they wouldn't necessarily be the same group of people. And next bought his company and they bought the Objective-C trademark, and they shipped it as the core development system for their workstations. And both people who bought the next workstation really, really liked it. And next in the Free Software Foundation had a little falling out at around this time. Next took the GNU compiler collection and they added an Objective-C front-end. And they tried to work around the GPL by releasing it as a shared library, which GCC would then load, and they thought, yeah, we don't have to release the source, we can keep it proprietary, and that's great for our commercial interests, because having an Objective-C compiler gives us a massive competitive advantage. Apple has since learnt that actually having an Objective-C compiler gives them no competitive advantage at all, so they released it as open source. And the Free Software Foundation set their attack lawyers on Next and said, you have to release this code, otherwise we will feed you to the sharks. And so Next released this code and it turned out once they did that the reason they didn't want to release it was that it was really hideous and they were just too embarrassed to let anyone see it. Unfortunately at that point the Free Software Foundation had put so much effort into forcing them to release the code they couldn't just look at it and say, actually no, we don't want it after all. So you look at this code and it's one single file which is about 1,500 lines long of just no separation of concerns and it's completely unreadable. And Next had approached the Free Software Foundation and said, hey, we've written this new front-end for Objective-C, they'd have said, no thanks, it's fine, you keep it. But because they tried to keep it private, the Free Software Foundation then did incorporate it. And so the compiler's only half of the puzzle. With Objective-C the compiler generates calls into a runtime library which implements all of the dynamic features that are required for Objective-C. And Next didn't release their runtime library which made getting the compiler support actually not that interesting because the runtime at the time was more complicated than the compiler stuff but it got the easy bit. So the Free Software Foundation wrote a new one and Next had done a few things in their design that weren't very sensible and they'd done some things that were done entirely for performance reasons but made it impossible to write a portable version of this library. And the GNU Project supports a load of different UNIX platforms. It now supports Windows and a few other things. So having something where you need to write every single combination of kernel and CPU they'd have needed to have the entire code base almost would have ended up being non-portable. It would have been horrible. So they changed the design a bit and then the GCC code got some more conditionals but some things for the next runtime and some things for the GNU runtime and so this really ugly code became even more ugly. And that was the status until about 2000. And I'll talk a bit about how that's changed in a few more slides. But for those of you who haven't really used Objective-C before I'll just give a little bit of an introduction to what the language does and why it's interesting. The first rule is that anything that has new semantics in the language has to have new syntax. So you don't have this confusion where you have one line of code with different things. C++ has the opposite philosophy. It says no new syntax for anything. So you can look at a line of C++ and you have no idea what it does at all. The next thing is Objective-C has no magic. If you look at a language like Perl or Smalltalk or anything Dynamic Scripting Language type things they do a lot of stuff in the virtual machine or even Java. They do things that really aren't exposed to the programmer. In Objective-C everything that's done in the background for you by the compiler, you can do in your own code. And the other part of the philosophy is there should only be one way of doing stuff. You don't have to decide do I want to use this language feature or this language feature or are they equivalent? So it's a very simple language. The one thing that everybody knows is the weird syntax. You look at it and you say Objective-C that's the language with the weird syntax. And this is an example of an Objective-C message send operation which is a Java program as you call out a method call. And it has this square bracket syntax. Tom Love, one of the developers of the original Objective-C said that this is a signpost saying you are now entering object land square brackets. You're dealing with the high-level bit of the language when you're outside of the square brackets you're dealing with basically C code. And this syntax takes a little bit of getting used to but it's actually really nice. You find after a while that you read Objective-C code. You can read Objective-C code that uses a library that you've never seen before and you're not constantly checking the documentation to find out what stuff does because every parameter is named. You don't get confused with parameter order. Everything that is an Objective-C message send is in no way confusable with a C function call so it's easy to look at a bit of code and see what the performance characteristics are going to be. So we have this message send operation. How does that really work? This is the same thing just up at the top. The message sent to the object called a dictionary the method name is set object for key and the two arguments are A and B. And if you're using the next runtime or the newer Apple runtime then this is just compiled to this single function call Objective-C message send and that takes the object as the first argument, the selector which is an abstract version of the method name as the second argument and then all of the other arguments and that's pretty simple and this is the bit that's hard to port to other platforms because this function then has to call another function with the arguments that it was passed so you can't do that in C and you can have to do it in some per platform assembly and you actually have to do it once for every different calling convention so in the Apple runtime they have a version of this called Objective-C message send which is for functions that return structures and Objective-C message send fp-rept which is another version for functions that return floating point values and it quickly gets really horrible and messy but it is slightly faster the GNU runtime version does it as a two-step process so the first call is to this Objective-C message lookup function which returns a function pointer and then you just have the compiler insert a call to that function just as it would insert a call to any other C function so this is really the only thing that makes Objective-C slower than C, this one extra layer of indirection message lookup so that's just a little bit of history and why Objective-C is interesting, what it's how it works I'm now going to talk a bit about the status of modern Objective-C compilers and a few years ago GCC switched to GPL v3 and Apple has religious objections to this so they started putting a lot of effort into Clang which is a new BSD license front-end for C and Objective-C and C++ and if you were at Chris Lattner's talk yesterday he talked quite a bit more about this than I'm going to now Clang is it's not a small code base it's actually pretty huge and that's great because it means Apple's doing loads of work for us for free of these 300,000 lines of code about 2,000 are specific to the GNU runtime and a lot of those actually don't really need to be, we've got abstract superclass which encapsulates all of the runtime specific behavior in the code generation part and we have a concrete superclass for the GNU runtime and a concrete subclass for the GNU runtime a concrete subclass for each of the two Mac runtimes and there's actually some code that could be shared between those two so we can probably reduce that number over time because there's just some stuff that rather than refactoring we've just copied and pasted from the Mac runtime version into the GNU runtime version and you can use Clang as a front-end for a compiler and I think Chris talked about that quite a bit but that's not all Clang can be used for library-based design so we can use it for some other interesting things and this is an example of using Clang for syntax highlighting this is enlarged a lot so it looks really ugly but you can see that it's doing proper syntax highlighting there and not just lexical highlighting so for example this compare thing at the top is a macro and it knows it's a macro so it highlights it it can tell that in pointer T is a type depth, it knows that big int is a class, it knows that big int with long long is a message sent and if you just compare that with vim which does lexical highlighting which is really simple to implement it's treating in pointer T as just a magic thing it's pretending that that's just a language keyword because it knows that that's defined by C99 but it doesn't know that big int is a class, it doesn't know that big int with long long is a message send, it doesn't know that compare is a macro and Clang of course exposes the error reporting at the library level as well so this is just a little quickly hacked together thing which in a normal GNU step text view gives you tool tips for any of the errors that were generated and this isn't a great user interface but it was just a demo that was 10 lines of code to write so as well as having a new compiler now we also have a new runtime which is a complete rewrite of the GCC runtime it's quite a bit smaller than the GCC runtime a lot of that is that the GCC runtime really predates having portable threading APIs so it has this huge threading abstraction layer most of which isn't actually called anywhere in the runtime some of which is incomplete it has a condition variable implementation which on Windows just always returns false we've added complete support for the new Objective C2 features there's a new ABI which has a few nice features that I'm going to talk about a little bit more we have working support for Apple's Blocks extension we're actually quite pleased with that because we managed to ship a working version of the Blocks runtime six months before Apple released their own language extension and it's also designed to support other dynamic languages I gave a talk yesterday in the GNU Step developer room about language kit which is a dynamic language implementation framework so we use the same compiler back end for compiling small talk and other languages so Objective C has a little bit of overhead on C and really there are three things that are different in C and Objective C in terms of performance I said one earlier but the other two aren't quite so important one of them is with the new ABI now Objects are no longer just a little bit of syntactic sugar around structures Objects have instant variables or fields if you're a C or Java programmer and these are now accessed via an Indirection layer which has some nice features for stopping you having to recompile all your code all the time but it adds just a little bit of overhead with the GCC runtime you have to look up every single time you send a message to a class you need to look up that class by name in a hash table and we're using a hopscotch hash which is pretty fast has nice performance with the data cache but it's still a hash table look up for something that really doesn't need to be and also we have the dynamic message look up which I talked about a couple of slides ago so the first thing we can do is avoid this non-fragile ABI use when it's not actually needed so the point of the non-fragile instance variable access is that allows you to ship a class which inherits from a class in someone else's library and then they change the layout of the instance variables in their class and you then don't need to recompile your class and that's a really useful feature but what happens if you're just inheriting from other classes in your own framework or if you're just inheriting from NS object which has a well-defined layout with just one instance variable that points to the class and nothing else and it turns out that's actually a really common case so we can for all libraries that do that we can just go through find all the indirect look ups replace them with direct look ups so you're only paying for this in direction layer in cases where it's actually useful and we can do this as a link time optimization with LLBM so all of these if all of these look up tests are done with the entire code for your library or for your application and we can also do this with the just in time compiler for language kit which means you can remove them in all cases because no one's going to change the layout of your super class after it's already been loaded into the running process class message overhead this one is really easy to fix we just make the class structure that the compiler generates export public symbol and just reference that directly don't bother with the hash table look up and Apple does the same thing for their runtime and this give us a factor of 5 speed up when calling class methods if you look in the GNU step codes you can tell that they're well aware of how expensive this is because in almost every Objective C file you see calls that cache the class pointer somewhere and then rather than sending messages to the class they send messages to this class layer of indirection so now we have stuff in GNU step which is actually making the code slower because it's adding another indirection layer rather than removing one so that's a shame but the other big thing though is the message send because Objective C encourages you to use this message send as your basic primitive for flow control and with the new runtime design we want to be able to add caching support for that and this is based on some ideas that the self team were implementing way back in 1995 so it's not really new research stuff but I think we're the first people to do it in a statically compiled language the self guys were doing this in a virtual machine with accurate garbage collection and that makes this actually a really easy thing to do it's slightly harder for us so now the lookup function rather than just returning a function pointer it returns a point to a structure and this has some metadata which makes it easier to implement languages that don't have quite the same type system as Objective C it also contains a version and you can use the version to find out whether the structure is still the same is still valid so you cache the version in the structure you compare whether the version in the structure and the version outside the structure are the same if they are it's great if they're not then you have to do the lookup again but it means that now rather than having the sort of manual method pointer caching that is fairly common in Objective C codes you'll see people doing this in critical paths in pretty much any large Objective C project we can now make the compiler do it automatically for free everywhere where it's sensible one thing that C programmers really like doing is using this inline keyword which the compiler then ignores and does its own thing but it tries to insert a copy of the function where it's called and that's really great for small functions and we have loads of those in Objective C the biggest case I think is probably accessor methods where you're just returning a value of an instance variable and so the cost of the message send is quite big the cost of even a function call there is a significant fraction of the total cost of doing the operation so in C you just inline that call and that's great it's fast and it's easy because if you have a function call in C you know exactly what function is being called it's the function which has that name Objective C because it has this in direction layer that's kind of difficult we don't have this one to one between call site and callee but we can get one and there are some heuristics we can use and there's profiling that we can do and then we can try inlining that and then we can just wrap that in a little test which says did we guess right if so don't bother with the call just go straight through the inline version and that then lets you do some other optimisation so you can take the inline's path and you can do constant propagation through that and so that can have some nice speedups so I've sort of waved my hands and said we can make stuff faster no talk about compiles would be complete without some synthesised and highly misleading microbench marks so here is the obligatory misleading microbench mark slide the basic test is a simple loop which calls a method which does nothing and it does it a billion times and the target performance is getting it close to what it costs in C and so running this version with just a C function call rather than an objective C message send takes about three seconds and okay three seconds is not very long if you just compile with Clang and you don't run any optimisations at all Clang actually produces some very messy intermediate representation for this which then the standard LVM optimisation path is clean up and actually just running the basic optimisations because we have some gratuitous loads and stores gets it down to eight seconds so eight seconds really isn't bad if the look up cost absolutely nothing just because we have two function calls six seconds is about what our target would be but we can get a bit better than that you turn on the automatic caching four point six seconds that's just automatic caching by itself by the way if you have the automatic caching plus the standard LVM optimisations we're now down to three point five seconds so really slightly slower than C but only just so now we turn on the speculative inlining and we're now faster than C without inlining so I think we're now at the point where we can make it faster but we just don't care anymore you're talking about the difference between your application using five percent of your CPU and it using four point five percent it's just not important but microbenchmarks they're great for examples and slides and stuff but they don't necessarily reflect real world performance and it's really important to realise that in any language a good language, a fast compiler and a poor algorithm will never beat a really naive compiler and a good algorithm and so one of the nice things about objective C is because it has this loose coupling it really encourages you to have optimisations at the macro scale rather than at the micro scale because it's a dialect of C you can also do the micro optimisations in C but the high level approach really encourages some general optimisations I just have a quick example of this how many people here are familiar with the international components for Unicode library a couple of you so this is a huge library which does lots of really useful things for internationalisation for locales for Unicode it has Unicode regular expressions some really nice things and it has internally its own representation of strings which is done as a C data type and it has fast macros for accessing characters by copying out a load of UTF-8 characters and I've seen quite a few libraries that use this from C++ and in C++ you have this standard string class and it's all really designed to be inlined and be fast and that's great turns out no one actually uses it in big libraries C++ library gets to a certain size and it implements its own C class its own string class it's like a writer passage and there are a couple of examples there LVM has its string ref thing QT has its own class WebKit has a thing called deprecated string in the WTF namespace which I particularly liked and so the way people use LibICU from C++ is they get a LibICU string and they copy it to a temporary buffer as an array of 16 bit characters and then they copy it from the temporary buffer into their own string class and so you have two linear time algorithms for every single string operation and if you're using the ICU regular expressions then one of these conversions may be hundreds of kilobytes of code I've run Regex code on text from my last book and so that's loads of text and so these linear time algorithms they really cripple performance and this happens a lot of boundaries between two C++ libraries where one has one string class that it thinks is great and the other one has its own happy string class which is also great and probably is implemented in exactly the same way but with very slightly different layout or interfaces in Objective C there's this NS string class and it's a standard string class but it doesn't actually do anything the NS string class is an abstract class the real implementation is some hidden concrete subclass on OS 10 it's probably NSCF string or some variant of that on GNU step there are a few GS string subclasses and it's very flexible it stores the text internally in a variety of ways it just gives you this abstract interface as if it's an array of 16 bit characters so everyone uses it and when we call ICU functions from GNU step we just have a subclass of NS string which uses the ICU underlying text representation and we do that the opposite way around as well so we implement their abstract data type in terms of NS string so we have two constant time operations that's great so the slow language Objective C ends up using algorithms that are much faster just because that's the easiest way of doing is an Objective C so that's how to make Objective C fast I now want to talk a little bit about making it a bit more reliable so this is a couple of Objective C class interfaces that define a method with the same name but one takes an integer as a parameter, one takes a float as a parameter and the implementation of these is simple they just use print it to display it on the terminal and so you have some code at the bottom which calls this method but in the last line you're calling an instance of class B but your static type annotation says it's an instance of class A and that's not an abuse of the type system because you're just casting a class to the super class so you compile this with LLPM or you compile it with plan and both will say absolutely fine, no warnings, that's great so what happens if you run this on the map well, the first call works the second call works and oops, you've called a function which expects a floating point value but you put your argument in an integer register so it just silently does the wrong thing and if you do this in a slightly more extreme case if it's a function returning structure and a function not returning structure then you don't just get the wrong result, you get random stack corruption and that's not ideal on Spark you get an illegal instruction exception and a trap and a bot and that's marginally better so with the GNU step runtime we do dispatch based on the type as well so now we're calling the correct function and that's a bit nicer so we're only matching methods with the correct type signature when we do the lookup if there's no matching version then we call a handler and that can return a fix up version so if you've got correct well written Objective C code it just works and I enabled this by default about 6 months ago and I was really shocked that it didn't break codes of people's code we found a few bugs in GNU step using it but mostly it just stuff works and what happens if you then have the same idea but the opposite way around if you do a downcast and you call this method which it thinks should be accepting the caller thinks it's passing a float and the caller is expecting an integer well again on OS 10 calls the function and there's some nonsense in the register with the GNU step runtime now it does this it says you're calling this method but you're doing it wrong fix your code so having this reporting an error is just a little bit nicer with a twilight which is project to build a desktop environment on top of GNU step we actually go one step further and we use some of LLVM's jit compiling stuff and we now insert a fix up method which says you did it wrong but don't worry we know what you mean we're going to do that type conversion for you and call the correct method so this is just a little demo that I think is quite fun I probably wouldn't recommend enabling it in production code but when you're testing stuff it's quite nice to say okay you've got a bug we'll fix it for now at runtime you can carry on your testing but don't forget to fix it before you actually ship so I've talked a bit about the compiler and the runtime and how we have Objective-C working on other platforms and how in some ways at least our version is nicer than Apple's but Objective-C is a really tiny language and by itself it's actually not that much use you can wrap up, see libraries with it but for Objective-C to be really useful it's the frameworks that really give it the power and if you're programming an OS X you're using these Cocoa frameworks and they're proprietary so well how do you deal with that when you're using another platform but it turns out Cocoa although it's a proprietary implementation is an implementation of an open specification and this was a collaboration between Sun and Next way back in 1992 and if you notice the NS prefix on all of the classes in Cocoa that stands for Next and Sun, the old Next stuff used NX and way back when this specification was created the GNU Step project was formed to implement it and it didn't get much use because Next over its entire history sold about 50,000 computers and that's 50,000 computers over about a decade which is not really enough for people to have a large installed base people using these frameworks and saying oh they're actually pretty nice you had a few people in academia Tim Berners-Lee said some really nice things about it but it didn't really get widespread adoption then Apple bought Next and renamed their OpenStep implementation Cocoa and suddenly there were loads of cheap computers and it seems weird to think of Max as cheap computers but in comparison with Next whose cheapest machine was $5,000 in early 90s late 80s money Max are actually really cheap so GNU Step then switched from implementing the OpenStep specification to implementing the OpenSpecification plus Cocoa extensions so where is it now well most of the stuff from OS 10 10.4 works which is a nice base level a lot of stuff from newer versions works we've got things like some of the newer locale and calendar stuff various random things a few things from the iPhone operating system their version of foundation we've now implemented so stuff like the Unicode regular expression classes basically stuff that people actually want to use tends to get implemented first occasionally Apple is very helpful to us to add a new API in one version we won't get around to implementing it then they'll deprecate it in the next version and then they'll remove it in the version afterwards so we don't have to bother with that one but generally stuff people use a lot gets done first and tends to be quite stable but of course patches are welcome so we've had a few companies say we want to port our application GNU Step can almost do it so it's cheaper to just add the bits to GNU Step send the patches along than it is to completely rewrite our application for another platform so one thing that I guess everybody knows about GNU Step is that it has this classic look which is totally timeless and it has this really consistent behaviour that mimics how next step worked and this is still the default look for GNU Step because one of the aims is to faithfully recreate all of the stuff that next did well and the difference is that now this is an option for GNU Step it's not the only thing so GNU Step has had increasing support for themes recently and a theme is not just the visual appearance all drawing in GNU Step opens via a delegate class now and you can replace that with a theme that does custom drawing in code or just with a simple one that loads PIX maps and they can also alter the behaviour so there are some nice things we can do we can move the menu into the window where Windows users expect it and people with desktop environments that try copying Windows expect it we can use native panels for things we can change the shortcut keys in menus so that they correspond to face guidelines we can do all of that kind of stuff so I just want to give you a few examples of that this is being as a word processor that was written for OS X it requires 10.4 or later it uses some newer APIs it was never written as a portable application it was written as an OS X word processor and it now works on GNU Step so this is what it looks like in its native environment you can see oh you actually can't see the top of the screen but there should be a menu bar off the top of the screen and it's a native Cocoa and then you take it to GNU Step and you see this classic industrial look with the floating menu there's okay it doesn't actually look quite that ugly the resolution doesn't quite match up so the anti-aliasing is broken but it's it's gray and it's boxes and that's the GNU Step trademark Gregory's recently been working on a GNOME theme so you run it in a GNOME environment and again you can't quite see the top of the screen but it has the menu in the window now and the menu looks like a GNOME menu the widgets all look like GNOME widgets the file dialog box is still the GNU Step one but well the themes are working progress so hopefully that won't stay there for much longer the Windows theme is a little bit more mature it uses the Windows API for drawing the menu it uses the Windows common dialog box doing the standard opening file panels for doing the print panels the color well the font user all of the standard Cocoa things that you just call into the library to produce it now just calls into the Windows library to produce so it looks and it feels like a native Windows application and I'm just going to finish up with a couple of things that we can do in Objective-C just to give you a taste of why Objective-C is more fun to program with than pure C and one of these things is higher-order messaging which originally came from Smalltalk and Smalltalk stole it from functional programming languages the idea is that rather than having a function that takes a function as an argument you have a message that takes a message as an argument to see how it works but that's how it looks like it works to programmers so I could try and explain this but it's much easier to show you some examples and if you've written any Haskell or ML code then this will probably look quite familiar to you at the top you have an array and you send it a map message and then you send it a make-up-a-case message and so the return value for this is another array which is the result of sending a element in the array, that's pretty simple you can do the same with a filter operation so you send it a is-supported message and it then iterates along every object in the collection and returns just an array which supports those versions the one in the middle is actually quite nice it's very common in Objective-C programs to have a delegate class that implements some methods that are required and some methods that are optional and so every time you call the delegate you have to bracket the message send saying do you actually respond to this method or to this message or should I just not bother calling it and with this higher-order message we just say delegate if it responds to this do it and the result from the if-response method is a proxy and it then receives the do-stuff or message it checks whether the thing that it's proxying actually responds to that if it does it forwards it, great if it doesn't then it ignores it and this now uses the fast proxying mechanism so this is very, very fast using the old proxying mechanism it was about 300 times more expensive than doing just a normal message send now it's about three times more expensive so that's a bit of an improvement the last one is probably my favorite one this in new thread message returns the proxy that has the object wrapped up in its own thread with its own message queue and that's using a lockless ring buffer to push the messages across very quickly so now you send it to start message and that's added to the queue it returns immediately and then in the other thread it starts playing you send it a current track message and it returns a proxy object and then you send a message to this return value and then you get the synchronization so it doesn't block until you actually try and use the result from calling the message in the other thread so we can have this really nice, simple implicit concurrency and we've used that in a media player application in a twilight and we just chuck the decoder just up in another thread and it just sits there and we pretend from a programming perspective that it's all happening in the main thread and it looks like it is but it's all done asynchronously and the synchronization has happened implicitly we can also do some fun stuff like automatic persistence we have this Itoile serialized framework and one of the nice things about Objective-C is that it has introspection metadata everywhere so every object you can enumerate all of the methods that it has what their types are you can enumerate all of the instance variables what their types are you can see it's superclass all of that stuff so we can look at an object visit every object that it references we can automatically serialize all of its instance variables we can take snapshots of objects messages that you send to objects so we can record those as well we can record the entire undue history to disk with no modifications of the model code in a statically compiled language that's almost as fast as C so that's pretty nice we can go beyond Objective-C yesterday I gave a talk about language kit and that's another compiler built on top of LLPM giving you an abstract syntax tree for small talk like languages we can implement a dialect of javascript on top of the same runtime sharing the same object you can take an Objective-C object Objective-C class you can subclass it in small talk you can then use that as a prototype in javascript and it's all compiled down to machine code there's no virtual machine and it's pretty magic and we've also got some kind of research stuff going on the new runtime takes the sender as one of the arguments for the lookup method and so we can implement this thing called object planes and Demian's been doing some work on that in small talk as well and the idea is that you have objects that are grouped in some semantic group and that might be related to a document or related to a specific library and every time you send a message between two of these discrete groups the message is intercepted by the writing on it so we can do things like implicit concurrency every time you send a message to any of the objects in this group it's added to a new thread to a message queue in that thread we can do access control so we can say only objects in this set are allowed to access some methods so we can do some sound boxing like that we can do automatic serialization it's pretty cool I'd just like to finish by provisionally announcing a brand new Objective-C compiler which should be appearing quite soon I've been working on this a bit with a company called PathScale and their existing compiler is a fork of Open64 and Open64 has a really nice architecture it has an intermediate representation which is initially at a very high level it's very close to a C or a Fortran Abstract Syntax Tree you can do some high level optimizations there and it's lowered through five stages and at each of the stages you can do more optimization so they're really heavily focused on optimization their aim is to be 10% faster than any other competing compiler so if you file a bug report with them saying ICC is faster than you for our code they regard that as a valid bug report it has stuff like OpenMP it has support for offloading stuff on the GPU and they're now using the same front-end as LLVM they're using this Clang front-end which is really modular so the dependencies between LLVM and Clang are actually really small it has a single library in the Clang source tree takes the Clang Abstract Syntax Tree and it emits LLVM intermediate representation from that and all they're doing is just replacing that library with another library that does the same thing but with their intermediate representation and this will be released open source quite soon so you can maybe use that if you're working on another compiler you could use that as an example of how to emit Gimple or something else and that's the end I shall just throw that in my latest book was released this week so if you want to learn more about Objective-C and if anyone has any questions