The Shape of Code

C is for Coral 66, CHILL, C, Cobol and C++. Writing compilers for languages beginning with C is a surprisingly accurate summary of the first half of my professional career.

Coral 66 is a variant of Algol 60 created by a branch of the UK Ministry of Defence. Apart from being the target language for my first compiler related work after graduating (a preprocessor to implement floating-point double) it also illustrates the difference between the UK and US military establishments, with the former deriving its language from the academically respectable Algol 60 and the later deriving Jovial from the engineering oriented Fortran.

CHILL gets mentioned because I spent 2 years writing and maintaining a front end of a CHILL compiler whose claim to fame may be as the oldest compiler still in production use; I have been half expecting somebody to point to a PL/1 mainframe compiler that is older. The language does support 2-dimensional switch statements, which I have not encountered elsewhere, e.g., switch i, j ... requires matching the value of i against one list of case labels and then matching the value of j against a second list associated with the first matched value.

C, I have written enough about this already.

COBOL is generally mocked by software developers, but it is a surprisingly sophisticated language; I suspect that the real target of the mockery is the thought of business people writing software. Business people have one redeeming characteristic in the programming language world, they are willing to pay good money for good compilers (generally developers are loath to spend money on the tools of their trade). I think that more money has been spent buying COBOL compilers than buying compilers for all the other languages put together.

My company won a contract to produce an optimising Micro Focus COBOL code generator for the Motorola 88000 (the successor to the popular, to developers, 68000) this is where I got to experience the most extreme form of debugging I have ever done. Creating a code generator for a new cpu involves cross-compiling programs from a platform that already supports the necessary tools and eventually cross-compiling the new compiler so that it executes on the target cpu. Porting software to a new cpu and OS invariably uncovers new faults that are specific to that combination of platform; compiler writers have to deal with the uncertainty that the fault might actually be caused by the code they generated. I’m used to handling this extra level of uncertainty, some developers cannot handle it and end up in mindless looping activities until something different to do. It was not until the target hardware was delivered that we found out it contained alpha silicon (i.e., a not yet in beta version of the cpu), and oh, here is an awk script to run your generated code through to map the instructions that don’t yet work to something that does; ever couple of week we would get an updated cpu motherboard, OS update and of course an awk script for that version of the silicon. I am not looking to repeat the ‘excitement’ of using an alpha silicon cpu to test a freshly written code generator, awk script or not. Sean Corfield deserves a lot of the credit for getting this project to work.

C++ was almost a very different beast than it is today. SC22 (the top level committee responsible for ISO programing language standards) did not think C++ was sufficiently different from C to warrant a separate committee. WG14 discussed this issue and gave a formal response to SC22 saying “we are not the committee to standarize C++”. WG21 was created, but without the power to publish any standards, with the task of figuring out what to do. Things came to a head, in a very heated discussion, at the WG21 meeting during early 1992 in London; the meeting minutes are suspiciously brief. The two positions were, 1) C++ is still incomplete and needs time to evolve to become itself before being standardized (I recall the AT&T representative saying that “C++ needed to fulfill its destiny” and banging the table, which got a round of applause), 2) we need a C++ ISO standard asap because C++ is being used now for production work and we have to stop Bjarne making major changes to the language (up until then existing practice was for the group creating an ISO language standard to specify the words for whatever existed at the time, i.e., no invention of new features); the Microsoft representative was the vocal led on this position.

As an outsider it (I had not attended the two previous WG12 meetings) there appeared to be many floating voters in the room and it could have gone either way, but the standardize now camp eventually prevailed.

Stroustrup’s solution to future C++ evolution possibly being stymied by WG21 was to become an active member of WG21 and to recruit like minded individuals to continue the work of evolving C++ within WG21, i.e., an ISO language committee broke with tradition and started doing major language invention.

Why did people care that Stroustrup kept changing the language, why didn’t they ignore him and carry on with whatever C++ compiler they were using? Up until almost the date of the London meeting all but one C++ compilers were based on Cfront, and who maintained and controlled Cfront? Yes, none other than Bjarne Stroustrup himself.

Things to read

The Design and Evolution of C++, by Bjarne Stroustrup. Get the 1994 edition, before history started to get updated.