gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cfe-dev] "Blocks" runtime


From: David Chisnall
Subject: Re: [cfe-dev] "Blocks" runtime
Date: Thu, 11 Jun 2009 12:36:00 +0100

On 11 Jun 2009, at 12:25, Pete French wrote:

Very interesting - whait's this 'libgcc replacement' they are
talking about ? wil that include the Obj-C runtime too ? It
would seem odd to put the OPbj-C block code elsewhere from the
rest of the langauge runtime.

libgcc is the support library that contains all of the functions that GCC may insert implicitly. This includes things like atomic operations, stack unwinding, soft float, and so on. GCC will link programs to it implicitly (and sometimes will copy code from it into programs) to provide features that are not present on the CPU.

Blocks are an Apple extension to C, rather than Objective-C, although they have some extra features for ObjC support, and so they don't go in the Objective-C runtime library.

BTW, for those people out there who havent tried llvm and clang
I suggest you go take it for a test drive. I've been experimenting
with it for a while now, and it looks "future shaped" to me
anyway ;-) It always looks like Davids announcements of llvm
stuff on here seem to go unremarked, and maybe people aren't
actually using it...

Clang definitely needs more testing, but I've been using it recently to compile some of the Étoilé frameworks and they seem to work nicely. I've recently been playing with some (very preliminary so far) support for speculative inlining, so if the compiler can correctly guess the called method then we can inline it and avoid the call overhead.

I'd also encourage people to test Étoilé's (MIT-licensed) ObjectiveC2 framework. This provides an implementation of Leopard's runtime API and a few other support functions for bits of Objective-C 2 (e.g. property accessors and a O(1) implementation of the @synchronized support functions, replacing GNUstep's O(n) one). I'm still not entirely sure where this code should end up. Some of it doesn't make sense for merging into libobjc, but I'd like let other Foundation implementations use it, so I'll keep it as a stand-alone framework for now, pending better suggestions.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]