From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Yates Newsgroups: gmane.emacs.help Subject: Re: history of argv (was: Re: How to do a massive unfill paragraph operation over several hundred files?) Date: Sat, 29 Sep 2018 19:20:54 -0400 Message-ID: References: <8636ts4jz3.fsf@zoho.com> <86sh1s33xn.fsf_-_@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1538263179 14809 195.159.176.226 (29 Sep 2018 23:19:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 23:19:39 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, moasen@zoho.com To: skip.montanaro@gmail.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Sep 30 01:19:35 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 1g6OWM-0003iZ-5M for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Sep 2018 01:19:34 +0200 Original-Received: from localhost ([::1]:52975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6OYS-0001hx-E2 for geh-help-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 19:21:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6OXw-0001hQ-DM for help-gnu-emacs@gnu.org; Sat, 29 Sep 2018 19:21:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6OXq-0004ce-Uq for help-gnu-emacs@gnu.org; Sat, 29 Sep 2018 19:21:11 -0400 Original-Received: from mail-yw1-f46.google.com ([209.85.161.46]:44623) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6OXq-0004cX-PW for help-gnu-emacs@gnu.org; Sat, 29 Sep 2018 19:21:06 -0400 Original-Received: by mail-yw1-f46.google.com with SMTP id s73-v6so4109183ywg.11 for ; Sat, 29 Sep 2018 16:21:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t9E6Qs6DqnAVKurETSPs3lQ9Rxqq9GXOZ23fL9ZmiLU=; b=Unk5/rCYlXmLA3eQvhf/pEsjB2B9YVgsum2baakKmfS8Lot8LlMhJtOxNEb+dsXss1 38qRIxqCcUNDEQHC8CE0Xr2WtqO2ZqZp0qDGNuFXef8CffafV80RwRNPx3Vi1Fmi/UYK rhDpIHhuoVX5MM1nSphbArUex7RUxgSmhWQphhPS1xk3du2CnnB8mDBBIFQ4wHeQaazL LMVo3Eq8w0nKdiIyWQ+BpUbzrhT+T1VaFem+psOCx0/qRZZtiMjHuZpdsQVq4Dq0LEIE ZCUBI5j3Hn2HE1sMU5sZNeDFPHuK+Yr5a5be5fXk4ze1Fcsh1HL8s0YhKAzXZs8Dyaca Eruw== X-Gm-Message-State: ABuFfoj/1VLvV74VKCcqznbvc0Wq4DdOx/crbHB3phap+Dv5DMbfihLf jEGVkwVWMIffJFQMn/yqQ+nBuKBfGBvGivJiovw= X-Google-Smtp-Source: ACcGV63Q/c/E05aj5tXiPKTLG3qUXDdlO6RM9KAcZjuxqGafBYFESqfU2pT/X3k8EKOblxziPJyZqTEyWZGtaNdZAdY= X-Received: by 2002:a0d:e2c7:: with SMTP id l190-v6mr2574590ywe.242.1538263265728; Sat, 29 Sep 2018 16:21:05 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.161.46 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:118073 Archived-At: On Sat, Sep 29, 2018 at 8:45 AM Skip Montanaro 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. 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