From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8528 invoked from network); 26 Aug 2020 13:25:46 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 26 Aug 2020 13:25:46 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4B4FD9DF41; Wed, 26 Aug 2020 23:25:43 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 669F593D54; Wed, 26 Aug 2020 23:25:08 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 6511293D54; Wed, 26 Aug 2020 23:25:04 +1000 (AEST) Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by minnie.tuhs.org (Postfix) with ESMTPS id 848E493D49 for ; Wed, 26 Aug 2020 23:25:03 +1000 (AEST) Received: from tahoe.cs.Dartmouth.EDU (tahoe.cs.dartmouth.edu [129.170.212.20]) by mail.cs.dartmouth.edu (8.15.2/8.15.2) with ESMTPS id 07QDOxeC250266 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 26 Aug 2020 09:24:59 -0400 Received: from tahoe.cs.Dartmouth.EDU (localhost.localdomain [127.0.0.1]) by tahoe.cs.Dartmouth.EDU (8.15.2/8.14.3) with ESMTP id 07QDOxBs046424 for ; Wed, 26 Aug 2020 09:24:59 -0400 Received: (from doug@localhost) by tahoe.cs.Dartmouth.EDU (8.15.2/8.15.2/Submit) id 07QDOxln046419 for tuhs@tuhs.org; Wed, 26 Aug 2020 09:24:59 -0400 From: Doug McIlroy Message-Id: <202008261324.07QDOxln046419@tahoe.cs.Dartmouth.EDU> Date: Wed, 26 Aug 2020 09:24:59 -0400 To: tuhs@tuhs.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. I hadn't heard this urban legend before. A stack is certainly manageable without auto-increment/decrement (AID) instructions. In fact Dennis's compiler did not use AID instructions for that purpose. AID instructions are nice for a LIFO stack, in which a stacked item disappears as soon as it's used--as do intermediate results in expression evaluation. But when the stack contains local variables that are accessed multiple times, the accesses are offset from the stack pointer. If AID instructions set the pointer, then the offset of a particular local varies throughout the code. The compiler can cope with that (I once wrote a compiler that did so), but a debugger will have a devil of a time doing a backtrace when the offset of the return address in each stack frame depends on the location counter. AID instructions are fine for sequentially accessing arrays, and in principle Ken's ++ and -- operators can exploit them. Yet idiomatic C typically wants post-increment and pre-decrement instructions--the opposite of what DEC offered. Examples: char a[N], b[N]; char *ap = a; char *bp = b; int i; for(i=0; i= 0) a[i] = b[i]; Doug