Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dennis Ritchie’s first C compiler (c. 1972)

github.com

Post reply on HN
Print view View original

31–40 of 163 posts

Re: Dennis Ritchie’s first C compiler (c. 1972)

#31

Post by wahern »

divs1210 wrote: post #25
retrac wrote: post #11

Earlier quoted context omitted.

Yes, bootstrapping with regard to languages is the trick of getting that first compiler running so you can compile the rest of the compiler. It has been done many times. The first assemblers were written directly in machine language. The first compilers were written in assembly. Many implementations of FORTRAN, ALGOL, COBOL, etc. As late as the 1970s it was not unknown to write a new high level language directly in m…

> No one has implemented a serious high level systems language, except in a high level systems language, for a long time now. LuaJIT is a prominent counterexample. The base interpreter in written in assembly for performance. It comes with its own tradeoffs, especially portability.

LuaJIT uses it's DynASM library for both static and JIT code generation. DynASM is implemented in a mixture of Lua and C, and Lua is of course implemented using C. So LuaJIT actually depends on a C compiler to generate assembly. Plus, not all of LuaJIT is implemented using assembly, only some critical hotspots (e.g. the bytecode interpreter loop). The rest is just C.

DynASM is actually really cool.

I almost forgot: apropos bootstrapping, because LuaJIT requires Lua to build, it includes a single-file, stripped down version of PUC Lua 5.1 which it can build to bootstrap itself if the host lacks a Lua interpreter.

Re: Dennis Ritchie’s first C compiler (c. 1972)

#32

Post by [deleted] »

divs1210 wrote: post #25
retrac wrote: post #11

Earlier quoted context omitted.

Yes, bootstrapping with regard to languages is the trick of getting that first compiler running so you can compile the rest of the compiler. It has been done many times. The first assemblers were written directly in machine language. The first compilers were written in assembly. Many implementations of FORTRAN, ALGOL, COBOL, etc. As late as the 1970s it was not unknown to write a new high level language directly in m…

> No one has implemented a serious high level systems language, except in a high level systems language, for a long time now. LuaJIT is a prominent counterexample. The base interpreter in written in assembly for performance. It comes with its own tradeoffs, especially portability.

[deleted]

Re: Dennis Ritchie’s first C compiler (c. 1972)

#34

Post by inopinatus »

neatze wrote: post #29

It is surreal feeling when looking at first code, not sure how to explain why it is the case.

I felt the same upon seeing an actual Dead Sea Scroll at the Jordan Museum in Amman.

The feeling dissipated somewhat when our guide explained that it’s a treasure map

Re: Dennis Ritchie’s first C compiler (c. 1972)

#36

Post by rzzzt »

systemvoltage wrote: post #10
retrac wrote: post #9

Earlier quoted context omitted.

It was written in B. And B was written in B. To trace the bootstrap up into the high level, you have to go further back than the PDP-11. To bootstrap B on the PDP-7 and GE-635 machines he had access too, Ritchie wrote the minimum subset required to compile a compiler in B, in a language known as TMG (in the vein of, and a big influence on, Yacc and similar). This minimal bootstrap was then used to compile a B compile…

When people say bootstrapping, is this how all computer languages came to be? Or there has been multiple attempts at bootstrapping? What I’m getting at is whether all languages have a single root.

Bootstrapping can also get recursive, eg. GCC and binutils are bootstrapped by compiling their sources with the GCC you already have on your build system; the result of this is an intermediary compiler, which is then used to compile the sources of itself again. (I should look up the following bit, but IIRC, the second generation result compiles the sources a third time, and the last two outputs are compared -- they should be equal, barring any non-deterministic optimizations.)

Re: Dennis Ritchie’s first C compiler (c. 1972)

#37

Post by andreareina »

bawolff wrote: post #30
amyjess wrote: post #20

I have to say, the way indentation and brackets were done here looks like it's just inviting subtle bugs. Take this for example: if (peekc) { c = peekc; peekc = 0; } else if (eof) return(0); else c = getchar();

I dont think it would look that out of place if he was using the ternary operator which is the same thing after all. E.g.: if (peekc) { c = peekc; peekc = 0; } else eof ? return(0) : c = getchar(); The first else clause sill looks weird, but the final part isn't nearly as out of place (well i guess assigning in a ternary would be weird, but in terms of indentation) and its not like we actually changed anything.

Can't return in a ternary.

Re: Dennis Ritchie’s first C compiler (c. 1972)

#38

Post by bumbada »

It is very interesting how many hardcoded magic numbers it has. No headers and defines because they did not existed yet?.

The full compiler is super compressed. Hundreds of lines per file. It would be great if there was an explanation of the general idea of the design somewhere.

Re: Dennis Ritchie’s first C compiler (c. 1972)

#39

Post by TonyTrapp »

lisper wrote: post #33
tyingq wrote: post #19

Earlier quoted context omitted.

Explanation: https://news.ycombinator.com/item?id=5748762

Why not just: char waste[however-many-bytes-are-needed]; ?

Can't say for sure if it's the reason in this particular situation, but that would require dynamic memory allocation, and while it may seem backwards to reserve more memory than potentially needed on old memory-constrained systems, it is a pattern you see very frequently because on those systems, you actually know exactly how much memory you have. As a result, you know exactly how much memory you can "waste".

Especially on single-tasking systems, it doesn't matter how much memory you waste, because no other program is affected by it.

Or in other words: If you know you are guaranteed to have x KB of memory available and no other program can steal it, and you know that you don't need more than y KB, then why allocate up to y KB dynamically when you can just straight-up allocate y KB statically, which is less work?

Re: Dennis Ritchie’s first C compiler (c. 1972)

#40

Post by Cthulhu_ »

bumbada wrote: post #38

It is very interesting how many hardcoded magic numbers it has. No headers and defines because they did not existed yet?. The full compiler is super compressed. Hundreds of lines per file. It would be great if there was an explanation of the general idea of the design somewhere.

I'm only seeing a few thousand lines of code, so I think it would fit in someone's head easily enough. Might be the numbers were on paper.
Post reply on HN