HN Books @HNBooksMonth

this makes a lot more sense alongside the actual souce code, like in this version:

https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

⬐ mananaysiempre

See also https://en.wikipedia.org/wiki/Xv6 for an attempted equivalent that would be freely redistributable, prepared as material for the MIT OS Engineering course. Apparently they switched from 32-bit x86 to RISC-V as a platform while I wasn’t looking :)

I had a colleague who did some work on PDP-11 on his early career. Excited, I asked "So you were using C (language) there?" "No, it's too early" He told me, kind of dismissively. In retrospect it was obvious - The PDP11-based Unix of the Lion's Book [1] was what I had in my mind, but that was probably more like an academic pursuit than a foundational OS of commercial software.

[1] https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

⬐ mark-r

I think my early PDP-11 programs were FORTRAN and Pascal, with a little assembler thrown in. The PDP-11 instruction set was fantastic.

⬐ imglorp

Yep: Macro-11 assembler.

It persisted until at least 1982 where you could get one on a desktop. https://en.wikipedia.org/wiki/DEC_Professional_(computer)

⬐ mark-r

That's fascinating, it looks almost exactly like a PC!

I used the LSI-11 and LSI-11/23, but never saw one of those.

⬐ imglorp

They were interesting beasts, with several personalities. One was a menu driven office suite with a word processor and I think a P-system Pascal arrangement. There was some kind of RSX11 underneath, with ratfor, macro-11, and DEC flavored C with $ identifiers.

Edit - Oh and I think this was one of the machine families DEC would sell where the difference between models was only the glue in some of the expansion slots of the cheap models.

⬐ imglorp

They were interesting beasts, with several personalities. One was a menu driven office suite with a word processor and I think a P-system Pascal arrangement. There was some kind of RSX11 underneath, with ratfor, macro-11, and DEC flavored C with $ identifiers.

The Linux kernel is unfortunately pretty far from UNIX nowadays but if you want to understand the basic concepts behind UNIX I think Lions' Commentary on UNIX is still the best resource out there:

https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

Once upon a time, programmers didn't have IDE's, Emacs, or even text editors. I'd been programming for seven or eight years before Bill Joy created vi. Each programmer and each program had its own style.

Often, a program's layout reflected the programmer's inner thoughts as he or she worked through the creation of the code. Expressions were written like a mathematician might write, with spacing and bracketing reflecting some way of thinking about the grouping of the abstractions at hand.

This is just a random routine, written around 1975, from Niklaus Wirth's PL/0 compiler for Pascal, the programming language that he created. The indenting is wild by contemporary standards:

    procedure getch;
    begin if cc = ll then
       begin if eof(input) then
                  begin write(' program incomplete'); goto 99
                  end;
          ll := 0; cc := 0; write(cx: 5,' ');
          while not eoln(input) do
             begin ll := ll+1; read(ch); write(ch); line[ll]:=ch
             end;
          writeln; readln; ll := ll + 1; line[ll] := ' ';
       end;
       cc := cc+1; ch := line[cc]
    end {getch};

Early C code too, even in the Unix kernel, was often dense and hard to understand (the kernel was under 10,000 lines back then). See Lions' Commentary [2]. Here's a small function, setfs(), line 7167 of the system 6 Unix kernel in Lion's book. In particular note the lack of indention under the for loop:

    setfs(dev)
    {
       register struct mount *p;
       register char *n1, *n2;
      
       for(p = &mount[0]; p < &mount[NMOUNT]; p++)
       if(p->m_bufp != NULL && p->m_dev == dev) {
               p = p->m_bufp->b_addr;
               n1 = p->s_nfree;
               n2 = p->s_ninode;
               if(n1 > 100 || n2 > 100) {
                       prdev("bad count, dev);
                       p->s_nfree = 0;
                       p->s_ninode = 0;
               }
               return(p);
       }
       panic("no fs");
    }

It seems obvious now that standard and consistent formatting make programs easier to understand. Why did we old timers do that to ourselves? First, short programs were easier to keypunch or enter via a teletype machine. Second, we had a plenty of time to study our code. Turn around time for a compilation, from submission to printed listing, could take 30 minutes to 12 hours.

[1] http://pascal.hansotten.com/niklaus-wirth/pl0/

[2] John Lions, Lion's Commentary on Unix 6th Edition with Source Code. https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

⬐ DonHopkins

>Often, a program's layout reflected the programmer's inner thoughts

And often it reflects the programmer's inner carelessness and disrespect for other programmers who have to deal with their code.

If you are going to study this you should also read the Lion's Commentary of the Unix 6th Edition (kernel)[0]. It provides a line by line commentary of the whole kernel (minus some of the hardware specific drivers). Xv6 is a port of the edition 6 kernel to x86 (with some minor changes).

[0] http://www.amazon.com/Lions-Commentary-Unix-John/dp/15739801...

The Lions book. http://www.amazon.com/Lions-Commentary-Unix-John/dp/15739801...