The earliest versions of the first C compiler known to exist

UNIX was ported to the System/370 in 1980, but it ran on top of TSS, which I understand was an obscure product.

"Most of the design for implementing the UNIX system for System/370 was done in 1979, and coding was completed in 1980. The first production system, an IBM 3033AP, was installed at the Bell Laboratories facility at Indian Hill in early 1981."

https://web.archive.org/web/20240930232326/https://www.bell-...

> The first publicly available version of Oracle Database (v2 released in 1979) was written in assembly for PDP-11.

I wonder if anybody still has a copy of Oracle v2 or v3?

Oldest I've ever seen on abandonware sites is Oracle 5.1 for DOS

> The mainframes at the time didn't have C compilers

Here's a 1975 Bell Labs memo mentioning that C compilers at the time existed for three machines [0] – PDP-11 UNIX, Honeywell 6000 GCOS, and "OS/370" (which is a bit of a misnomer, I think it actually means OS/VS2 – it mentions TSO on page 15, which rules out OS/VS1)

That said, I totally believe Oracle didn't know about the Bell Labs C compiler, and Bell Labs probably wouldn't share it if they did, and who knows if it had been kept up to date with newer versions of C, etc...

SAS paid Lattice to port their C compiler to MVS and CMS circa 1983/1984, so probably around the same time Oracle was porting Oracle to IBM mainframes – because I take it they also didn't know about or couldn't get access to the Bell Labs compiler

Whereas, Eric Schmidt succeeded in getting Bell Labs to hand over their mainframe C compiler, which was used by the Princeton Unix port, which went on to evolve into Amdahl UTS. So definitely Princeton/Amdahl had a mainframe C compiler long before SAS/Lattice/Oracle did... but maybe they didn't know about it or have access to it either. And even though the original Bell Labs C compiler was for MVS (aka OS/VS2 Release 2–or its predecessor SVS aka OS/VS2 Release 1), its Amdahl descendant may have produced output for Unix only

I assume whatever C compiler AT&T's TSS-based Unix port (UNIX/370) used was also a descendant of the Bell Labs 370 C compiler. But again, it probably produced code only for Unix not for MVS, and probably wasn't available outside of AT&T either

[0] https://archive.org/details/ThePortableCLibrary_May75/page/n...

I very much doubt anyone from the time wants to talk about it, but there is substantial bad blood about Oracle and Ingres. I believe not all of this story is in the public domain, nor capable of being discussed without lawyers.

Writing something that large in assembly is pretty crazy, even in 1979!

Gotta love the user-friendliness of these old Unix tools:

  if (argc<4) {
      error("Arg count");
      exit(1);
  }

Ah, yes, was that because of a lack of inline assembly? I feel like these could be replaced by 'nop' operations.

What is the point of it?

It's much less of your own code if you use TCL (THINK Class Library), which shipped with THINK C 4.0 (and THINK Pascal) in mid 1989.

Your System 6.0.8 is from April 1991, so TCL was well established by then and the C/C++ version in THINK C 5 even used proper C++ features instead of the hand-rolled "OOP in C" (nested structs with function pointers) used by TCL in THINK C 4.

I used TCL for smaller projects, mostly with THINK Pascal which was a bit more natural using Object Pascal, and helped other people use it and transition their own programs that previously used the Toolbox directly, but my more serious programs used MacApp which was released for Object Pascal in 1985, and for C++ in 1991.

>Looks like "extern" is used to bring global symbols into function scope.

a better way to think of extern is, "this symbol is not declared/defined/allocated here, it is declared/defined/allocated someplace else"

"this is its type so your code can reference it properly, and the linker will match up your references with the declared/defined/allocated storage later"

(i'm using reference in the generic english sense, not pointer or anything. it's "that which can give you not only an r-value but an l-value")

Yes, pretty much. To be fair, C at this point was basically BCPL with slightly different syntax (and better char/string support). The introduction of structs (and then longs) changed it forever.

"auto" used to mean automatic memory management because if you are coming from assembly or even some other older higher-level languages you can't just declare a local variable and use it as you please. You must declare somewhere to store it and manage its lifetime (even if that means everything is global).

C and its contemporaries introduced automatic or in modern terms local or stack allocated values, often with lexically-scoped lifetimes. extern meaning something outside this file declares the storage for it and register meaning the compiler should keep the value in a register.

However auto has always been the default and thus redundant and style-wise almost no one ever had the style of explicitly specifying auto so it was little-used in the wild. So the C23 committee adopted auto to mean the same as C++: automatically infer the type of the declaration.

You can see some of B's legacy in the design of C. Making everything int by default harkens back to B's lack of types because everything was a machine word you could interpret however you wanted.

Also with original C's function declarations which don't really make sense. The prototype only declares the name and the local function definition then defines (between the closing paren and the opening brace) the list of parameters and their types. There was no attempt whatsoever to have the compiler verify you passed the correct number or types of parameters.

Declaring a variable or function as extern(al) just tells the compiler to assume that it is defined "externally", i.e. in another source file. The compiler will generate references to the named variable/function, and the linker will substitute the actual address of the variable/function when linking all the object files together.

Modern C won't let you put extern declarations inside a function like this, basically because it's bad practice and makes the code less readable. You can of course still put them at global scope (e.g. at top of the source file), but better to put them into a header file, with your code organized into modules of paired .h definition and .c implementation files.

You can do the same with a modren C compiler - the extern and auto mean the same and int is still the default type.

All of these things come directly from B:

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bintr...

As to "sizeless" arrays - yes.

Have a look at the early history of C document on DMR's site, it mentions that the initial syntax for pointers was that form.

Memory safety predates C by a decade, in languages like JOVIAL (1958), ESPOL/NEWP (1961) and PL/I (1964), it follows along in the same decade outside Bell Labs, PL/S(1970), PL.8 (1970), Mesa (1976), Modula-2 (1978).

If anything the cool kids are rediscovering what we lost in systems programming safety due to the wide adoption of C, and its influence in the industry, because the cool kids from 1980's decided memory safety wasn't something worth caring about.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"

Guess what programming language he is referring to by "1980 language designers and users have not learned this lesson".

The "cool kids talking about memory safety" are indeed standing on the shoulders of giants, to allow for others to stand even taller.

Big non sequitur, but your comment triggered a peeve of mine that I find it ironic when people talk like oldsters can't understand technology.

The reality is, the only languages that are truly simple are Turing tarpits, like Brainfuck.

Reality is not simple. Every language that’s used for real work has to deal with reality. It’s about how the language helps you manage complexity, not how complex the language is.

Maybe Forth gets a pass but there’s good reason why it’s effectively used in very limited circumstances.

The perceived complexity from a semantic standpoint comes from the weakly-typed nature of the language. When the operands of an expression have different types, implicit promotions and conversions take place. This can be avoided by using the appropriate types in the first place. Modern compilers have warning flags that can spot such dodgy conversions.

The rest of the complexity stems from the language being a thin layer over a von Neumann abstract machine. You can mess up your memory freely, and the language doesn’t guarantee anything.

C is simple.

Representing computation as words of a fixed bit length, in random access memory, is not (See The Art of Computer Programming). And the extent to which other languages simplify is creating simpler memory models.

It’s not really clear to me how you could have a simple low level language without tons of nuance. Something like Go is certainly simple without tons of nuance, but it’s not low level, and I think extending it to be low level might add a lot of nuance.

forth would come to mind, some people have build surprising stuff with it though I find it too low-level.

Lisp is build from a few simple axioms. Would that make it simple?

I would say rust. When you learn the basics, rust is very simple and will point to you any errors you have, so you get basically no runtime errors. Also the type system is extremely clean, making the code very readable.

But also C itself is very simple language. I do not mean C++, but pure C. I would probably start with this. Yes, you will crash at runtime errors, but besides that its very very simple language, which will give you good understanding of memory allocation, pointers etc.

Modula-2 is a language operating on the same level (direct memory addressing, no GC etc) but with saner syntax and semantics.

It's still a tad more complicated than it needs to be - e.g. you could drop non-0-based arrays, and perhaps sets and even enums.

The first 4 commits in GO are:

commit d82b11e4a46307f1f1415024f33263e819c222b8 Author: Brian Kernighan <bwk@research.att.com> Date: Fri Apr 1 02:03:04 1988 -0500

    last-minute fix: convert to ANSI C
    
    R=dmr
    DELTA=3  (2 added, 0 deleted, 1 changed)

commit 0744ac969119db8a0ad3253951d375eb77cfce9e Author: Brian Kernighan <research!bwk> Date: Fri Apr 1 02:02:04 1988 -0500

    convert to Draft-Proposed ANSI C
    
    R=dmr
    DELTA=5  (2 added, 0 deleted, 3 changed)

commit 0bb0b61d6a85b2a1a33dcbc418089656f2754d32 Author: Brian Kernighan <bwk> Date: Sun Jan 20 01:02:03 1974 -0400

    convert to C
    
    R=dmr
    DELTA=6  (0 added, 3 deleted, 3 changed)

commit 7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 Author: Brian Kernighan <bwk> Date: Tue Jul 18 19:05:45 1972 -0500

    hello, world
    
    R=ken
    DELTA=7  (7 added, 0 deleted, 0 changed)

I don’t think anybody thinks or thought it was.

It would have been bootstrapped in assembly (or B/BCPL?) and then once you can compile enough C to write a C compiler you rewrite your compiler in C.

I remember a Computerphile video where prof. Brailsford said something along the lines of "nobody knew who wrote the first C compiler, everybody just kinda had it and passed it around the office" which I think is funny. There's some sort of analogy to life and things emerging from the primordial soup there, if you squint hard enough.

yes. the Q you're asking is: "how was this bootstrapped?"

the page that's referenced from GitHub doesn't describe that

http://cm.bell-labs.co/who/dmr/primevalC.html

however there probably was a running c compiler (written in assembly) and an assembler and a linker available, hand bootstrapped from machine code, then assembler, linker, then B, NB and then C...

We can't tell but that would make sense...

The first B compiler was written in BCPL on the GE 635 mainframe. Thompson wrote a B compiler in BCPL which they used to cross-compile for PDP-7. Then Thompson rewrote B in B, using the BCPL compiler to bootstrap. AFAIK this is the only clean "bootstrap" step involved in the birth of C (BCPL -> B -> self-compiled B)

Then they tweaked the compiler and called it NB (New B), then eventually tweaked it enough they decided to call it C.

The compiler continuously evolved by compiling new versions of itself through the B -> New B -> C transition. There was no clean cutoff to say "ah this was the first C compiler written in New B".

You can see evidence of this in the "pre-struct" version of the compiler after Ritchie had added structure support but before the compiler itself actually used structs. They compiled that version of the compiler then modified the compiler source to use structs, thus all older versions of the compiler could no longer compile the compiler: https://web.archive.org/web/20140708222735/http://thechangel...

Primeval C: https://web.archive.org/web/20140910102704/http://cm.bell-la...

A modern bootstrapping compiler usually keeps around one or more "simplified" versions of the compiler's source. The simplest one either starts with C or assembly. Phase 0 is compiled or assembled then is used to compile Phase 1, which is used to compile Phase 2.

(Technically if you parsed through all the backup tapes and restored the right versions of old compilers and compiler source you'd have the bootstrap chain for C but no one bothered to do that until decades later).