Re: history of argv (was: Re: How to do a massive unfill paragraph operation over several hundred files?)

[John Yates]

On Sat, Sep 29, 2018 at 8:45 AM Skip Montanaro <skip.montanaro@gmail.com> wrote:
>
> I suspect that if
> Multics was still the main Emacs ecosystem, we'd see Multics-like names at
> the boundaries. In fact, they might be there and I just don't recognize
> them. <wink>

I never used Multics but I was part of Apollo Computer from its earliest days.

Apollo was born in Prime Computer's R&D group before the Unix tsunami hit the
computer industry.  Prime included a large contingent of Multics alumni. The
main emotional impetus of that R&D group was to preserve as much of the Multics
computing architecture as possible on more limited hardware. By contrast,
Thompson and Ritchie, Multics' best known alumni, were more intent on recreating
the experience of community that a shared computing environment fostered.  The
hardware each effort targeted greatly influence its designs.

Multics' original hardware - the GE-645, a mainframe with pricing to match -
provided a 36-bit virtual address space composed of 2^18 segments, each
containing up to 2^18 36-bit words. These segments formed a "Single Level
Store": all segments were addressable though not necessarily accessible.
ACL-based protection was segment-granular. Segments were the user visible
elements of persistent storage. Hierarchical directories mapped names to segment
numbers (think DNS to IP address or Unix path to inode number).  The output of
the compilation tool chain was what we would consider a shared library: an image
exporting various symbols and requiring additional symbols to be provided by the
environment into which it got loaded.  Upon connection a user was provide a
process running the command shell.  To invoke a command the shell translated the
name to a segment ID and asked to have it "made known" (i.e. import its exported
symbols into the CLS - Combined Linkage Segment).  Linking was maximally
dynamic.  References to heretofore unbound symbols (both instruction and data)
were resolved "on the fly" using the CLS. So for instance, for the shell to list
the contents of the current directory the shell would locate the list segment,
ask to make it known and then call its entrypoint.  The clear implication here
was that a single process' stack contained both stack frames for the invoking
shell and stack frames for the list_directory image.  The corollary is that
there was no forking, no cloning of address spaces.

Thompson and Ritchie, started earlier and targeted the obsolescing PDP-7.  The
PDP-7 had an 18-bit architecture nearly unchanged from DEC's original PDP-1.  It
had an ability to address at most 16 banks of 4K 18-bit words.  Each bank was
effectively a separate segment.  The most convenient program image occupied no
more than a single bank (i.e. 4K words).  Having two or more images present at
the same time in a process' 4K address space was nearly unthinkable.  This, at
least in part, explains why, unlike Multics, Unix emphasizes creating light
weight processes.

Nearly a decade later the Prime folk targeted Motorola's forthcoming 68000.
This microprocessor had a 24-bit byte-granular address space.  (The original
68000 did not support virtual memory.  Still it was cheap enough that Prime was
able to cobble together a virtual memory scheme via an off chip MMU and a second
68000 to handle page faults.  When the MMU detected a page miss it simply halted
the clock to the main processor.  The second chip serviced the page fault and
then re-enabled the main processors clock.)  This 16MB virtual address space was
large enough to implement Multics' single level store architecture.  Because the
68000 supported neither segment addressing nor segment faults those had to be
finessed by explicitly mapping files into the address space.  There were not
stream I/O operations.  That file mapping was the only means of performing I/O
testifies to the system being a true SLS.  The large address space also allowed
in-process image activation.  Full on-the-fly dynamic linking was not possible.
Trampolines might have supported calls to unbound external entrypoints but there
was no obvious way to handle unbound data reference.  Therefore adding an image
into a process resolved all possible references in either direction.

As Skip intuited, in spite of the radically different systems that emerged the
common Multics heritage is visible in the culture of abbreviated command names
and in some of the names themselves (e.g. ls, pwd, etc):

https://multicians.org/multics-commands.html