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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25620 invoked from network); 16 Dec 2023 19:22:02 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 16 Dec 2023 19:22:02 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 74D2243E6E; Sun, 17 Dec 2023 05:21:59 +1000 (AEST) Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) by minnie.tuhs.org (Postfix) with ESMTPS id 69C1D43D5E for ; Sun, 17 Dec 2023 05:21:50 +1000 (AEST) Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-59067f03282so1305008eaf.0 for ; Sat, 16 Dec 2023 11:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702754509; x=1703359309; darn=tuhs.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MHFXnfGCAzHbR2K4kqvWpLOrIEuwRS8p2hA6Irbo6MU=; b=ITvY9i9W7/qhb/ACPeR3xsw1UCBLlzzhpDagmfGNyIP+7h2j6ycyiA0ldBWP5twq2f TMMnYO7mBZ869e3l8/dBLUQKLhc0G02hrlKCq4yyRrfmXPzvRT7JL33xvXji/S8d9UdC VgsbBk2tnInbqZdRhBcxktmhsWpafn7vtZvc4XjXfq/eBz1Y2ohGAAxSVyyik8XMTB3s MXkY80vb3LgrIPzdvF+feYDhqKJPI0nx7W0R7ewNpZl1h1n3Vcvth/nuN/4t2Iodrhj4 +7QbUnBjIE6lQUK8yVt4SpCqFB0UppW3of3AIYDNOFQD3svdRfNHeUqfn8LD4+ntjQiL HQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702754509; x=1703359309; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MHFXnfGCAzHbR2K4kqvWpLOrIEuwRS8p2hA6Irbo6MU=; b=jSCoD8SSjoymtrue04+y/0qd/AE72OJ6NUzgZdj15NHjJThlzEnmnASHWDIc19Qyiq qO5xHOOyu2uhLe1VGKhMQDfLthDqVX8u/LtXI/+PVBaoy1tHtfDNa555RBkYtUbMHfmq TRf7rECmRw9omacIyiLA5l5mI7XLH3OHHH8kt+utvLbtbBCph2Mu4KaHL4udzKlMwQpc sa1W4zDMsbQp4RuMT89NMOCda52PpJYAzxppOIQar4aHqsJlDzTQCvdypNzpf7ADBgSH ZvoAfrR+LacCN7CIuEZ0tXhjmsek8BbqD/4Y4oLOT3Nxf8xgbkhU6Iz8GdMTdp7NgWo9 l2lg== X-Gm-Message-State: AOJu0Ywy54XAP+o9JZQfzS6JrcY/B8AUcbQC0hqPUGIJ3YphdDbtWdab UyP7eioomBZy9Icty74HhkTJC8Kt94nrLRfjcEw= X-Google-Smtp-Source: AGHT+IF9dsWbAqLBKTnh85ms2b+sxbTiFHVQoJ57CpI7DZc7F/aY5WdXmDn8EpVLIOBGCL3R0AZT5E7kgXxPcTd3en8= X-Received: by 2002:a05:6358:720d:b0:16d:f46f:16a9 with SMTP id h13-20020a056358720d00b0016df46f16a9mr18642521rwa.17.1702754509283; Sat, 16 Dec 2023 11:21:49 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6a10:234f:b0:526:f191:393 with HTTP; Sat, 16 Dec 2023 11:21:48 -0800 (PST) In-Reply-To: References: <20231214232935.802BB18C08F@mercury.lcs.mit.edu> <4416CB1B-CDE2-42DA-92F2-33284DB6093F@iitbombay.org> From: Paul Winalski Date: Sat, 16 Dec 2023 14:21:48 -0500 Message-ID: To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 7NBBJDOIJ6ARISAM2WR2FTMTPA52YS6G X-Message-ID-Hash: 7NBBJDOIJ6ARISAM2WR2FTMTPA52YS6G X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: coff@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Terminology query - 'system process'? List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 12/15/23, Greg 'groggy' Lehey wrote: > > At least in assembler (I never programmed HLLs under MVS), by > convention R13 pointed to the save area. From memory, subroutine > calls worked like: > > LA 15,SUBR load address of subroutine > BALR 14,15 call subroutine, storing address in R14 > > The subroutine then starts > with > > STM 14,12,12(13) save registers 14 to 12 (wraparound) in old save > area > LA 14,SAVE load address of our save area > ST 14,8(13) save in linkage of old save area > LR 13,14 and point to our save areas > > Returning from the subroutine was then > > L 13,4(13) restore old save area > LM 14,12,12(13) restore the other registers > BR 14 and return to the caller > > Clearly this example isn't recursive, since it uses a static save > area. But with dynamic allocation it could be recursive. Yes, that was the most common calling convention in S/360/370., and the one that was used if you were implementing a subroutine package for general use. It has the advantage that the (caller-allocated) register save area has room for all of the registers and so there is no need to change the caller code if the callee is changed to use an additional register. It also makes it very convenient to implement unwinding from an exception handler. But it does burn 60 bytes for the register save area and if you're programming for a S/360 model 25 with only 32K of user-available memory that can be significant. Those writing their own assembly code typically cut corners on this convention in order to reduce the memory footprint and the execution time spent saving/restoring registers. There's been long debate by ABI and compiler designers over the relative merits of assigning the duties of allocating the register save area (RSA) and saving/restoring registers to either the caller or the callee. The IBM convention has the caller allocate the RSA and the callee save and restore the register contents. One can also have a convention where the caller allocates an RSA and saves/restores the registers it is actively using. Or a convention where the callee allocates the RSA and saves/restores the registers it has modified. Each convention has its merits and demerits. The IBM PL/I compiler for OS and OS/VS (but not DOS and DOS/VS) had three routine declaration attributes to assist in optimization of routine calls. Absent any other information, the compiler must assume the worst--that the subroutine call may modify any of the global variables, and that it may be recursive. IBM PL/I had a RECURSIVE attribute to flag routines that are recursive. It also had two attributes--USES and SETS--to describe the global variables that are either used by (USES) or changed by (SETS) the routine. Global variables not in the USES list did not have to be spilled before the call. Similarly, global variables not in the SETS list did not have to be re-loaded after the call. IBM dropped USES and SETS from the PL/I language with the S/370 compilers. USES and SETS were something of a maintenance nightmare for application programmers. They were very error-prone. If you didn't keep the USES and SETS declarations up-to-date when you modified a routine you could introduce all manner of subtle stale data bugs. On the compiler writers' side, data flow analysis wasn't yet advanced enough to make good use of the USES and SETS information anyway. Modern compilers perform interprocedural analysis when they can and derive accurate global variable data blow information on their own. -Paul W.