Live data from Hacker News

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

github.com

81–90 of 163 posts

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

#81
post #71
post #69

Earlier quoted context omitted.

Do you mean automatic type deduction? Edit : I know it’s also storage specifier but it also does type deduction here, hope I’m not confused with the terminology

It doesn't do type deduction there. In original C you could declare variables without a type, and these variables with auto have no type. So this "auto" is essentially saying "this variable without a type uses automatic storage". That's a completely different language feature from "deduce the type of this variable".

A variable without a type is 'int' so ```auto xx;``` means an int on the function local variable stack.

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

#82
post #21

Earlier quoted context omitted.

> Steve Woz's BASIC for the Apple II was "hand-assembled", as he put it. Very cool - so basically (haha) Woz's integer BASIC was bootstrapped by writing it in assembly language and translating it into machine code by hand. I wonder if someone (Woz?) has written a 6502 assembler in integer BASIC to allow it to bootstrap itself?

I'm not an expert, but I guess "bootstrapping" only applies to compilers , and Apple II BASIC was an interpreter . An interpreter doesn't have to compile itself, only run the programs you give it. So on an 8-bit computer the priority is to have an implementation that (a, and most importantly) takes up as little space as possible and (b) is reasonably fast.

There are metacircular interpreters, like in Scheme (see SICP [1]). But this is rare, compared to bootstrapping compilers.

[1] https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

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

#83
post #42

Earlier quoted context omitted.

It makes sense long would have needed a comment. It needs a comment because “long” and “double” are terrible names for data types. Long what ? Double length what ? Those type names could easily have opposite meanings and meant long floating point / double length integer. WORD/DWORD are nearly as bad - calling something a "word" incorrectly implies the data type has something to do with strings. If you don't believe m…

Yes, int_16/int_32 or something like that makes a lot more sense. Today, not when this compiler was written. The PDP-9, PDP-10, and PDP-18 have 18 bits registers. The world had not settled on 16/32/64 bits at all. Even the intel 80286 far/fat pointers are 24 bits.

Unsure why you’re being downvoted, IIRC the original C programmers reference spoke explicitly about how “int” meant the most efficient unit of storage on the target machine.

Admittedly I read that more than 30 years ago :-O

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

#84
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();

The difference between Dennis Ritchie and the average programmer of today is, Dennis Ritchie did not write bugs in the first place.

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

#85
post #26

Earlier quoted context omitted.

I like that the Bootstrappable Builds folks are working on a bootstrap process that goes from a small amount of machine code (~512 bytes) all the way up to a full Linux distro, including compilers/interpreters for modern languages. https://bootstrappable.org/

Nice, I hadn't heard of this project before! In particular BOOTSTRA [1] looks really fun. I have also toyed with the idea of using MS-DOS 3.30 as a guaranteed-ubiquitous build environment. It comes with a filesystem, a text editor (EDLIN.EXE), an object file linker (yup!), a debugger/assembler (DEBUG.EXE is an amazing tool), a programming language with decent string handling (GWBASIC.EXE), and a command interpreter w…

What is "guaranteed-ubiquitous" about DOS 3.30?

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

#86
post #42

The original keywords - https://github.com/mortdeus/legacy-cc/blob/master/last1120c/... Interestingly, long was commented

It makes sense long would have needed a comment. It needs a comment because “long” and “double” are terrible names for data types. Long what ? Double length what ? Those type names could easily have opposite meanings and meant long floating point / double length integer. WORD/DWORD are nearly as bad - calling something a "word" incorrectly implies the data type has something to do with strings. If you don't believe m…

No, the names are fine and self evident after glancing through K&R for 15 min.

The real mistake in retrospect is that int and long are platform dependent. This is an amazing time sink when writing portable programs.

For some reason C programmers looked down on the exact width integer types for a long time.

The base types should have been exact width from the start, and the cool sounding names like int and long should have been typedefs.

In practice, I consider this a larger problem than the often cited NULL.

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

#87
post #42

The original keywords - https://github.com/mortdeus/legacy-cc/blob/master/last1120c/... Interestingly, long was commented

It makes sense long would have needed a comment. It needs a comment because “long” and “double” are terrible names for data types. Long what ? Double length what ? Those type names could easily have opposite meanings and meant long floating point / double length integer. WORD/DWORD are nearly as bad - calling something a "word" incorrectly implies the data type has something to do with strings. If you don't believe m…

[deleted]

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

#88
post #33

Earlier quoted context omitted.

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". Especia…

IMO the way C programmers avoid dynamic memory allocation because it's so painful is probably the best feature of the language.

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

#89
post #86
post #42

Earlier quoted context omitted.

It makes sense long would have needed a comment. It needs a comment because “long” and “double” are terrible names for data types. Long what ? Double length what ? Those type names could easily have opposite meanings and meant long floating point / double length integer. WORD/DWORD are nearly as bad - calling something a "word" incorrectly implies the data type has something to do with strings. If you don't believe m…

No, the names are fine and self evident after glancing through K&R for 15 min. The real mistake in retrospect is that int and long are platform dependent. This is an amazing time sink when writing portable programs. For some reason C programmers looked down on the exact width integer types for a long time. The base types should have been exact width from the start, and the cool sounding names like int and long should…

And that creat has no e on the end.

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

#90

Earlier quoted context omitted.

Yes, int_16/int_32 or something like that makes a lot more sense. Today, not when this compiler was written. The PDP-9, PDP-10, and PDP-18 have 18 bits registers. The world had not settled on 16/32/64 bits at all. Even the intel 80286 far/fat pointers are 24 bits.

Unsure why you’re being downvoted, IIRC the original C programmers reference spoke explicitly about how “int” meant the most efficient unit of storage on the target machine. Admittedly I read that more than 30 years ago :-O

An int in C was 16 bits until about 1980 when Unix started being ported to larger machines. C and Unix were originally just for the PDP11.
Post reply on HN