Unix V4 source recovered after 50 years

[BigEd]

(I found control-\ will stop a program and dump core. I tried pretty much every control combo. No doubt the v4 or v5 docs would have helped me!)

[barnacle]

Fun, and thanks, but I couldn't get a response from 'cc'.

Neil

[BigDumbDinosaur]

Yuri wrote:

That's pretty cool. Might want to add a note to the MOTD that CTRL+C will not stop a program either..... >_>

[Ctrl-C] had no special meaning to traditional UNIX, up to and including SCO OpenServer 7 (the last SCO product which my company sold before going all Linux).  To abort a script or program, [DEL] was used.  A kill with core dump was triggered with [Ctrl-\].  Not sure when [Ctrl-C] got into the picture—probably something inherited from BSD UNIX.

[Niek6502]

Yuri wrote:

Might want to add a note to the MOTD that CTRL+C will not stop a program either..... >_>

DEL should terminate a program.

Ah - this all takes me back. Did a lot of programming on SCO Xenix (from the 286 on) all the way to the last iterations of OpenServer. I am (was?) a certified engineer and trainer for SCO (and too many other Unix/Linux platforms).

barnacle wrote:

Fun, and thanks, but I couldn't get a response from 'cc'.

'cc' definitely works - I just wrote, compiled and ran a 'hello world' program.

Very nifty.

Niek.

[BigDumbDinosaur]

barnacle wrote:

Fun, and thanks, but I couldn't get a response from 'cc'.

Is the compiler installed?

[Niek6502]

BigDumbDinosaur wrote:

Is the compiler installed?

'cc' is:

-Niek.

[BigDumbDinosaur]

Niek6502 wrote:

BigDumbDinosaur wrote:

Is the compiler installed?

'cc' is:

The attachment hello.jpg is no longer available

Guess that settles that question.  As an aside, look how small the resulting a.out is that the compiler generated.    That shows just how much bloat modern versions of gcc attach to what is basically a one-line program (below).

Hello, world on Linux with gcc

The resulting a.out is about 10 times the size of that produced by the old compiler.  Even after stripping the binary, it is still over 6KB in size.

Also, notice how gcc complained because I didn’t have a function prototype for printf in my source.  Back when Sys IV UNIX was in use, C didn’t require prototypes—they aren’t at all mentioned in the 1978 edition of the K&R whitebook.

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

That's pretty cool. Might want to add a note to the MOTD that CTRL+C will not stop a program either..... >_>

[Ctrl-C] had no special meaning to traditional UNIX, up to and including SCO OpenServer 7 (the last SCO product which my company sold before going all Linux).  To abort a script or program, [DEL] was used.  A kill with core dump was triggered with [Ctrl-\].  Not sure when [Ctrl-C] got into the picture—probably something inherited from BSD UNIX.

I figured as much, hence why I suggested adding it to the MOTD. I'm sure a lot of folks trying it out for the first time would not know this.

Quote:

Guess that settles that question. As an aside, look how small the resulting a.out is that the compiler generated. That shows just how much bloat modern versions of gcc attach to what is basically a one-line program (below).

Not that GCC is the best compiler (arguably probably one of the worst actually), but not all of that is as much bloat as you might think; or at least, not all of that is GCC's fault.

Starting with the ABI, the PDP-11 also looks to have a relatively flat set of instructions that uniformly fit in 16-bit words. The x86 platform in general is all over the place with the size of its instructions, x64 is way worse.... Really the whole x86 platform is just absolutely BONKERS at this point with the number of instructions they've added. Intel/AMD complain about having to remain backwards compatible with the old 8-bit/16-bit days, but I would argue that they're insistence of doing stupid things like having a single instruction for computing a SHA-256 checksum (this is not an exaggeration, this instruction exists....) are completely unnecessary and are the real cause of the huge bloat in the x86 platform.

The PDP-11's native integer/pointer size is 16-bits. Modern Linux installations on an x64 process are 64bits; a 4x increase in size; even a 32 bit x86 would be x2 in size, that's for every integer and pointer constant, those quickly add up. To give you an idea, some of the modern code I work on for modern cloud infrastructure will save about 40% of in memory size just from telling the same compiler to generate 32-bit code instead of 64-bit code.

And then there's the binary format itself. The compiler for the PDP-11 is likely (I still am going through the source for the compiler and assembler right now) produces a raw binary with no extra fluff. GCC is adding ELF headers, text, rodata sections, etc. so on and so forth.

Finally there's the C Library itself, which has gotten considerably more complex and feature rich than these early days. The source in V4 Unix for printf() is 214 lines of PDP-11 assembly, and supports d, o, x, f, e, c, s, and l, inserts, can set a width and maybe a couple of other things broadly over all parameters, and pretty much only goes to stdout. FreeBSD 15's version by contrast can be redirected all sorts of different ways to Sunday, supports over 20 different insert types, and has a benzine of formatting options both generic and for specific insert types, and has many more safe guards on it to try and prevent erroneous buffer overruns and all sorts of things that just weren't a problem in those early days, as such it is now over 2000 lines of C code (and that's just the parts that actually formats and generates the strings, doesn't include all the various other flavor wrapper code around it).

That being said, there are about what appears to be about 114 functions in their C library, ANSI C has roughly 140 to 150 functions; so the number of functions in standard C hasn't increased much; though different platforms of course will change that. *gives Windows the stink eye*

Heck, as an example, make a couple of errors in your C code and look at how very terse the error messages are that the compiler generates vs a modern compiler.

Quote:

Also, notice how gcc complained because I didn’t have a function prototype for printf in my source. Back when Sys IV UNIX was in use, C didn’t require prototypes—they aren’t at all mentioned in the 1978 edition of the K&R whitebook.

That isn't a good thing that the compiler Sys IV did that. Not that I'm a huge fan of prototypes, there are other ways to do the same thing, but it requires more work in the compiler. But note that it was a warning, it isn't required, the compiler trusts that you know what you're doing, but it's trying to tell you that you might have made a mistake (which it often is.)

You can easily disable this warning in GCC/Clang with the "-Wno-implicit-function-declaration" command line option:

Note I also had to add the -fno-builtin because printf() has special handling in GCC; again, the compiler trusts you know what you're doing. C compilers are extremely forgiving with what you can give them, as such the age old adage is true, you can blow your toe off if you aren't careful with them. C++ tries to protect you some with it's type safety, but as the saying was extend to then say, you can blow your foot off when you make a mistake.