-fnext-runtime vs. -fgnu-runtime smackdown, #0, introduction

Long ago and far away, well, for me at least, some Really Smart guys at NeXT Computer modified gcc to support Objective-C and released the changes back out into the public, because, well, they were obligated to under the GPL. What they were not obligated to release was the actual runtime needed to effectively use the compiler changes. So, some other Really Smart people who wanted a runtime wrote one which worked with the compiler changes and released it as free software as part of gcc. They actually improved upon the NeXT runtime in one aspect and saw a vision of Objective-C working everywhere in a more portable fashion. They changed the primary dispatch function from objc_msgSend to one called objc_msg_lookup, the subtle difference being that objc_msgSend must be written in assembler, whereas objc_msg_lookup can be written in C. The assembly needed to tie everything together for a particular platform was kept in the compiler. Very smart guys.

You could choose between these two runtime interfaces with compiler flags, -fnext-runtime and -fgnu-runtime. gcc became the de facto Objective-C compiler in the world and has remained to this day.

But something happened along the way. As with most Really Smart people, they don't sit around, and the guys who implemented the original GNU runtime interface moved on to other things. Their creation, -fgnu-runtime, was left out in the cold for someone else to come along and take care of.

Someone did come along and try to take care of -fgnu-runtime, but as with many foster parents they had Good Intentions but did not Understand -fgnu-runtime like a creator would. They tried to understand -fgnu-runtime, but pushed it to do some things it didn't want to do and neglected some of it's strengths.

The new caretakers were trying to create some new software and felt that -fgnu-runtime could help them if only it would do some new things that would make their life easier, or so they thought. Cinderella was put on dish duty.

What happened?

Instead of just being a difference in the function interface, people started to also modify the data structures that -fgnu-runtime generated. The major changes are:

- Heavily altered the behavior of a selector to support "typed selectors".
- Neglected to keep the object code data structures up to date with the NeXT changes
- Modified the object code data structures to support some things which aren't really needed in the object code data structures.

This caused a split in Objective-C, the NeXT runtime camp and the GNU runtime camp. The two runtimes vary so much that conventions in one are not supported in the other. So, there are effectively two Objective-C's and this bothers me.

I maintain my own Objective-C runtime which is neither Apple nor GNU. For a long time I hobbled along supporting both interfaces, the NeXT interface on Windows using the old YellowBox compiler and the GNU interface on Linux and Solaris with newer compilers. I have largely ignored the problem until now. I need to update my compiler suite and unify my runtime so it is supports one interface.

But what is happening is that while I prefer the NeXT data structures, objc_msg_lookup is very handy when moving to new platforms. So I end up creating my own version of gcc which supports the conventions I need.

Ugh. A third runtime interface. This is not good.

I decided to examine what I needed to unify the runtime interfaces and what compiler changes I would need to make.

This is the first in a series of posts on the differences between the -fnext-runtime and -fgnu-runtime interfaces. I will detail the strengths and benefits of each interface and how they can co-exist to make Objective-C a more compelling force in the world of software. This is not about the implementation of the runtimes, rather about compiler standardization. The runtime API's are a whole other topic!

Before these two runtime interfaces can agree, they've got to duke it out and settle their differences. Let the -fnext-runtime vs. -fgnu-runtime smackdown begin!