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

Restoration of First Edition Unix Kernel Sources

github.com

Post reply on HN
Print view View original

1–10 of 13 posts

Re: Restoration of First Edition Unix Kernel Sources

#2

Post by beefhash »

Pretty sure this is an export of a Google code project[1], at least the date and message of the latest commit matches the github version.

Previously on HN for the Google code project: https://news.ycombinator.com/item?id=1132682 and https://news.ycombinator.com/item?id=2698685

Two days ago on HN: The init system from the same source code tree: https://news.ycombinator.com/item?id=10206309

[1] https://code.google.com/p/unix-jun72/

Re: Restoration of First Edition Unix Kernel Sources

#3

Post by nightcracker »

Can anyone explain this from src/c/c10.c?

    ospace() {}	/* fake */

    waste()		/* waste space */
    {
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
        waste(waste(waste),waste(waste),waste(waste));
    }

Re: Restoration of First Edition Unix Kernel Sources

#4

Post by jhallenworld »

nightcracker wrote: post #3

Can anyone explain this from src/c/c10.c? ospace() {} /* fake */ waste() /* waste space */ { waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste))…

I think so...

It's creating space in the code section right after ospace. If you look at ospace, it's being used as a buffer. So we have a buffer in the code section instead of the data section. So the question is why? Remember that this is a PDP-11/20 and the maximum memory is only 56 KB (maybe the one at AT&T had less). The data section must be nearly out of space.

There is more: notice that the variables are always allocated at the end of each file, and that "extern" is being used within each function as a forward reference. I think the purpose of this is to keep the symbol table usage within the compiler low- at the end of each function you get the symbol table space used by the externs back. The only symbols which remain are the function names themselves until the end of the file.

I never used UNIX on a PDP-11 (except simh), but I did use DEC's RSX-11 (on an 11/34). In that operating system a lot of effort was dedicated toward making a good overlay linker. Overlays were in the form of a tree: You had to carefully structure your code to maximize the efficiency of this, so that the most commonly referenced things were closer to root. UNIX didn't have any of this..

Re: Restoration of First Edition Unix Kernel Sources

#5

Post by kps »

jhallenworld wrote: post #4
nightcracker wrote: post #3

Can anyone explain this from src/c/c10.c? ospace() {} /* fake */ waste() /* waste space */ { waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),waste(waste),waste(waste))…

I think so... It's creating space in the code section right after ospace. If you look at ospace, it's being used as a buffer. So we have a buffer in the code section instead of the data section. So the question is why? Remember that this is a PDP-11/20 and the maximum memory is only 56 KB (maybe the one at AT&T had less). The data section must be nearly out of space. There is more: notice that the variables are alway…

  > The data section must be nearly out of space.
It is for space, but the 11/20 didn't have split I/D. The specific answer¹ is ‘worse’:

  A second, less noticeable, but astonishing peculiarity is
  the space allocation: temporary storage is allocated that
  deliberately overwrites the beginning of the program,
  smashing its initialization code to save space.
That is, use of the ospace() ‘array’ overlaps the beginning of main().

¹ https://www.bell-labs.com/usr/dmr/www/primevalC.html

Re: Restoration of First Edition Unix Kernel Sources

#7

Post by acqq »

kps wrote: post #5
jhallenworld wrote: post #4

Earlier quoted context omitted.

I think so... It's creating space in the code section right after ospace. If you look at ospace, it's being used as a buffer. So we have a buffer in the code section instead of the data section. So the question is why? Remember that this is a PDP-11/20 and the maximum memory is only 56 KB (maybe the one at AT&T had less). The data section must be nearly out of space. There is more: notice that the variables are alway…

> The data section must be nearly out of space. It is for space, but the 11/20 didn't have split I/D. The specific answer¹ is ‘worse’: A second, less noticeable, but astonishing peculiarity is the space allocation: temporary storage is allocated that deliberately overwrites the beginning of the program, smashing its initialization code to save space. That is, use of the ospace() ‘array’ overlaps the beginning of main…

So it is a kind of "overlay" where the data buffer overlaps the piece of the code. I find the explanation of jhallenworld is correct.

Re: Restoration of First Edition Unix Kernel Sources

#9

Post by kps »

acqq wrote: post #7
kps wrote: post #5

Earlier quoted context omitted.

> The data section must be nearly out of space. It is for space, but the 11/20 didn't have split I/D. The specific answer¹ is ‘worse’: A second, less noticeable, but astonishing peculiarity is the space allocation: temporary storage is allocated that deliberately overwrites the beginning of the program, smashing its initialization code to save space. That is, use of the ospace() ‘array’ overlaps the beginning of main…

So it is a kind of "overlay" where the data buffer overlaps the piece of the code. I find the explanation of jhallenworld is correct.

In a sense, but ‘overlay’ generally means more than just re-using memory — it's reading in different sections of (usually) code in place of others; in modern terms, it's sort of like paging, but structured explicitly and (usually) manually at build/link time.

PDP-11 Unix did eventually support overlays, but I don't think they were widely used. The ‘Unix way’ would be to have (as this C compiler does) separate programs run consecutively with intermediate state in temporary files.

Post reply on HN