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

[Emanuel Berg <moasen@zoho.com>]

John Yates wrote:

> 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

I'm certainly glad I brought this up for you
all to share these stories!

    "Government forces claim they have found
    evidence of interesting pieces of
    computer history in J. Yates' person."

-- 
underground experts united
http://user.it.uu.se/~embe8573