Log in

No account? Create an account

Previous Entry | Next Entry

We've got four runtimes for Objective C now: Apple/NeXT's, Cocotron's, the GNU Objective C runtime, and Etoile's.

Every one requires a modified version of the compiler, meaning three sets of patches to the compiler, plus one included by default. The default runtime is arguably the most limited and antiquated of them all.

Time for a change, folks?

(Anyone want to help write a pluggable backend and simultaneously help me target GObject?)


( 2 comments — Leave a comment )
Jan. 5th, 2009 05:54 pm (UTC)
good idea but.. :)
I think this is a good idea but getting commit access to gcc is somewhat of a challenge based on my experience. Apple seems to be shifting their focus more on Clang (http://clang.llvm.org) and OpenCL. I think that Clang is invoked via a separate executable and is using link-time optimization. Maybe something that attaches itself to Clang would be a better way to go. The big challenge here is requirements, where would you optimize etc.? I personally like the outside of the box thinking of Clang and there are some tangible benefits to link-time optimization such as import optimizing and things that focus more on the runtime and module loading side of things rather than some ubiquitous binary compatibility format (ala .Net). I randomly found this post googling something different but i like your ideas.

Jan. 5th, 2009 06:03 pm (UTC)
Re: good idea but.. :)
Thanks! Yeah -- Clang is a great start, though I think it'd be healthy if the compiler and runtime aren't so intertwined. (Besides, it makes a healthy competetive environment having two compatible compilers and a few runtimes that work with them)

I think this is a reason C lives on so strongly -- the ABI is so simple and unchanging that it's hard to break and many compilers can target the same runtime. So we end up with things like intel's cc, Sun's cc, and gcc, all with the same ABI, and runtimes like µClibc, glibc, and klibc.

( 2 comments — Leave a comment )