Pulling the plug

GCC facilitated the portability of Linux and other free operating systems. If it was accessible to proprietary plugins, this may not have happened

Recently, the topic of Gcc and the resistance of richard Stallman to the implementation of plug-ins, proprietary or otherwise, was re- ignited by an argument on the emacs mailing list. It started when Stefan Monnier, an Emacs developer, declared to Stallman: “To me there is blindingly clear evidence that what you’re trying to protect doesn’t exist any more, and that it’s just alienating those rare individuals who do share our values enough that they haven’t already moved on to LLVM/Clang.”

It is worth re-iterating the arguments from Stallman’s point of view. GCC first emerged in the late Eighties and was an instant success. Compilers had become an expensive commodity and GCC was free software. GCC produced fast and portable machine code and supported a range of languages and architectures. GCC was good at optimisation and its portability meant that code results could be compared between architectures, making it useful for the designers of processors and mobile devices, where speed to market is vital and the ability to compare results across different architectures is an asset.

The success of GCC, which is sometimes seen as Richard Stallman’s greatest programming achievement, was a major factor in the success of Linux, not only as the tool that made it possible for Linus Torvalds to run his kernel on his original 386, but because it was portable and enabled Linux (and the BSDs) to be ported across a range of architectures, separate of any proprietary chains. Linux is portable because GCC is portable. If GCC supports a processor, any software that is compiled with GCC can run on that processor.

The job of GCC is relatively straightforward – to translate and optimise the source code into a form that is understood at the machine level and ensure the translated code is fast and secure. To achieve this, GCC takes the code through a series of processes which are known as front ends, back ends and a ‘middle end’. In theory, these parts are distinct. The front end translates the source code of a programming language into a form recognisable to the middle end. The middle end performs optimisations and the back end translates code into a form known to a processor.

In an ideal world (where all software is free) GCC would be seen as modular and each part of the compilation process would be an interchangeable plug-in. In practice GCC is monolithic, which makes it difficult to draw the lines between the different sub-processes. This is of no consequence to end users and doesn’t affect the usability of the software from the end- user’s point of view. GCC is monolithic by design and the obfuscation of the intermediate coding steps between the programming language front ends and the machine-specific back ends, which prevents the modularisation of the code, is a deliberate ploy, designed to inhibit the re-use of GCC code in proprietary settings.

GCC is portable precisely because of this obfuscation, which has meant that the path of least resistance for language and processor designers has been to allow access to their code by free software developers – the specification and design of the processor (and/or programming language) has become available to the free and open source software community. This outcome is driven by three factors: the obfuscation of the code, the copyleft nature of the licence and the ubiquity of GCC. GCC has aided the portability of Linux and other free operating systems, including the BSDs. If GCC had been modular and accessible to proprietary plugins, this probably wouldn’t have happened. This is at the core of Richard Stallman’s argument that GCC should not allow plug-ins.

Stallman is often criticised for his obduracy and idealism, but it can be argued that his stance is ultimately pragmatic. We might like a modular approach which would sit well with the ideals of free software, but if the code was transparent, modular and allowed proprietary plug-ins, fewer languages and architectures would be available to the free, open source community. But does this argument still apply in a world where it is proposed that LLVM and Clang, both heavily sponsored by Apple, offer a different reality? LLVM and Clang are young and fresh, but GCC still outperforms Clang in the majority of benchmark tests and is independent of any commercial interest. Only time will tell which will be the better option.

Stallman recognises his own stubbornness. Back in 1999 he told Michael Gross that when he began the GNU project people said, “‘Oh, this is an infinitely hard job; you can’t possibly write a whole system like Unix. It would be nice, but it’s just hopeless.’ That’s what they said. And I said, ‘I’m going to do it anyway.’ This is where I am great. I am great at being very, very stubborn and ignoring reasons why you should change your goal, reasons that many other people will be susceptible to. Many people want to be on the winning side. I didn’t give a damn about that. I wanted to be on the side that was right, and even if I didn’t win, at least I was going to give it a try.”