Building and using a 29-year-old compiler on a modern system | Hacker News Reader

Building and using a 29-year-old compiler on a modern system

miyuki.github.io

139 pointsingve25 comments

Getting old build tools to work is really awesome. I went through a similar process getting an old version of HPHPc (the PHP-to-c compiler precursor to HHVM) to work[1]. I found Docker to be incredibly invaluable for doing this in a reproducible way, especially when the system state needed to be changed in complex ways or dependencies needed to be tweaked.

A small example is that the test cases only work right if English, German, Finnish and French locales are available and if the system timezone is set to "America/Los_Angeles".

[1]: https://github.com/allanlw/hphpc-docker

Another fun one is: http://fabiensanglard.net/Compile_Like_Its_1992/index.php

Note that the gcc.gnu.org server, like many others, is configured to also serve the same files via HTTP(S) e.g.

https://gcc.gnu.org/pub/gcc/old-releases/gcc-1/gcc-0.9.tar.b...

It's actually a little surprising just how much code is already there even in such an early pre-ISO-C version --- it feels like GCC was rather overengineered from the beginning.

Was it overengineered, or is this one of the rare cases where "too much" architecture upfront was actually a sound long-term investment?

GCC is still around and kicking and competes well with the much more modern Clang that has substantial investment from Apple and other industry giants. That's an amazing achievement for a 30-year-old open source project.

You can look at this from other side: the fact that Clang was created and is quite popular tells that GCC had enough problems to warrant its creation.

Is there any major software project that doesn’t get competition after 20 years? (Counting from gcc’s release to clang’s launch.)

This industry is constantly reinventing. Clang takes a different tack in both licensing and implementation, and that’s great for everyone.

It depends if you are talking only about open source or all projects. In the latter case I'd say Photshop still has no competition. There are alternatives for some subtasks (photo editing for web), but for print work nothing comes even close, afaik.

The Bloomberg terminal also enjoys an enviable moat these days. But that's mostly network effects.

Gcc had competition in the form of proprietary compilers from hardware manufacturers. I remember I used the HP compiler on HPUX machines at university (8xx series?) We were using gcc most of the time, can't remember why.

While clang's creation doesn't root only n the fact of "wrong" engineering, but of different goals and politics.

For the later: An important driver in clang are Apple and BSD communities who don't want to have GNU software (especially GPLv3) in their systems.

Also parts of gcc's architecture are created for political reasons to make it harder to decouple, while clang's primary design was to build a library which understands C/C++ and also can be used as a compiler.

The purely technical arguments (i.e. gcc has bad diagnostics and clang gives better errors) are minor (gcc, due to the competition, became way better, if equal time would have gone to gcc instead of clang it might be even better)

All that said: I really love this cooperative competition which benefits everybody, where you have different options try out ideas and where for large parts contributors discuss ideas between competing solutions.

> parts of gcc's architecture are created for political reasons to make it harder to decouple

This was a major, long standing gripe about GCC, and it materially affected its quality and usability. This was not an orthogonal matter: bad technical decisions were made in the interest of political goals.

> if equal time would have gone to gcc instead of clang it might be even better

I don't think so. GCC's position as the de facto choice for a free/open compiler, coupled with some of the political/organizational decisions of the project, made it easy for developers to say "it's good enough!" on such things. Viable competition is one of the few things that will shake a team out of that.

Politics bear a part of the blame for some of GCC's more questionable architectural decisions. They intentionally made the architecture hard to write plugins for.

The entire reason GCC exists is politics. The same can be said for the rest of the base GNU system.

For the ignorant: what decisions are you referring to? I've heard this a lot but am not sure what people mean.

https://news.ycombinator.com/item?id=15408652 explains it better than I did. Basically, early on they didn't want GCC to be able to be used piecemeal with closed source compilers / plugins. Thus they made GCC hard to be used piecemeal.

But using bits and pieces of your compiler is exactly what you'd want to be doing when you want to have good editor integration: eg syntax highlighting _should_ actually use the compiler instead of duplicating logic. Especially with a language that's Turing complete to even parse like C++; the logic just to figure out whether something is a type to be coloured eg blue or a variable name to be coloured eg green.

(See http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...)

Thanks, I updated the links.

Could a compiler as simple as TCC, if it was available at the time, have succeeded as the minimum viable product for GNU's C compiler? How do gcc 1's optimizations compare to TCC's today?

Optimizations were less important for gcc's popularity than you might think.

One of the key features of gcc was its portability across many architectures. Cygnus was one of the first companies to support free software. Among other things, they received income from companies who wanted gcc to run on new chipsets.

Another was that gcc was designed with multi-language support from the start. The original release only supported C, but C++ support can shortly afterwards. (Originally added by Tiemann, one of the founders of Cygnus.)

TCC is not designed with the same portability or multi-language support in mind.

TCC (as it was last time I looked) would have been a non-starter since it is so closely tied to a single platform.

gcc had the advantage of the same compiler everywhere.

Without gcc, you were using your Unix vendor's in-house compiler, which was usually a half-assed PCC port that was declared "done" as soon as AT&T's sources compiled.

gcc was both higher quality and had the same frontend quirks regardless of the platform. Particularly before 1989, the standard was "Work like K&R's compiler" rather than anything formal, so there were a lot of nooks and crannies where each compiler did its own thing.

This is a post about a fun experiment, but these kinds of tasks are day to day jobs for quite a few people. Fortran or COBOL codebases are often unmaintained yet relied upon.

I remember when we updated our Fortran compilers (because of other tooling) and they had problems with our 80s/early 90s code. That was joy to debug.

If you enjoy this type of content I highly recommend https://virtuallyfun.com

Example cool article: https://virtuallyfun.com/2015/10/09/building-linux-0-11-on-w...

Thanks for the plug, I've been able to cross build just about every a.out buildable Linux kernel from Windows.

In addition I've built and did some minor tyre kicking with GCC 0.9

https://virtuallyfun.com/2016/12/01/building-using-gcc-0-90-...

I've done minor shuffling to get DooM to compile with GCC 1.39 on MS-DOS/x68000 & OS/2

https://virtuallyfun.com/2017/07/29/null-doom-gcc-1-39-go32-...

GCC 1.37 on MacOS

https://virtuallyfun.com/2016/05/24/gcc-1-37-on-macos/

And of course using RSXNT / EMX to get GCC 1.40 targeting Windows NT

https://virtuallyfun.com/2016/05/06/gcc-1-40-on-windows/

I think I ran 0.97. from memory, it compiled the kind of trivial K&R C I wrote.

To build a particular working GCC, dependencies (binutils, MPC, MPFR and GMP (and sometimes ISL)) need to be within a particular range, preferrably within the same time era. Also note that old compilers will often contain unpatched security vulnerabilities.

Binutils 2.25 (released in 2016) is compatible with GCC 1.27 (released in 1988) - this is pretty amazing. As for the other libraries, they are not needed. All GCC versions implement simple multiprecision integer arithmetics internally, so GMP is only required by later versions of GCC for correct handling of corner cases, especially cross compilation. GCC 1.x does not use MPFR or any other software floating point library (and this can be problematic for cross-compilation). ISL is a relatively new dependency (it's a library used for some experimental loop optimizations). Needless to say, it is not relevant for GCC 1.x. Similarly for MPC - a multiprecision complex number library.

Reply on news.ycombinator.com