From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: history of argv (was: Re: How to do a massive unfill paragraph operation over several hundred files?) Date: Sun, 30 Sep 2018 20:20:44 +0200 Organization: Aioe.org NNTP Server Message-ID: <865zym26f7.fsf@zoho.com> References: <8636ts4jz3.fsf@zoho.com> <86sh1s33xn.fsf_-_@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1538331809 9751 195.159.176.226 (30 Sep 2018 18:23:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Sep 2018 18:23:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Sep 30 20:23:25 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6gNI-0002Qz-Uo for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Sep 2018 20:23:25 +0200 Original-Received: from localhost ([::1]:56536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6gPP-00053M-DS for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Sep 2018 14:25:35 -0400 Original-Path: usenet.stanford.edu!goblin3!goblin.stu.neva.ru!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 119 Original-NNTP-Posting-Host: onLrbz09yV+MU3RaxdbMkg.user.gioia.aioe.org Original-X-Complaints-To: abuse@aioe.org Cancel-Lock: sha1:E6rMQ7S7VXt//qudHmREjlO1jWM= X-Notice: Filtered by postfilter v. 0.8.3 Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:223954 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:118080 Archived-At: 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