Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: Why I've Dropped In Date: Tue, 17 Jun 2025 16:47:55 -1000 Organization: Wheeler&Wheeler Lines: 54 Message-ID: <87cyb1u5no.fsf@localhost> References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <8addb3f96901904511fc9350c43917ef@www.novabbs.com> <102b5qh$1q55a$2@dont-email.me> <48c03284118d9d68d6ecf3c11b64a76b@www.novabbs.com> <102cd09$23hcu$1@dont-email.me> <42cac84be6fb35b9e468cc174919bc4a@www.novabbs.com> <102eske$2nqdn$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 18 Jun 2025 04:47:57 +0200 (CEST) Injection-Info: dont-email.me; posting-host="28fd2b5bc6a946242919f13ee6838c9b"; logging-data="3039110"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1zKR9NL0bEPSP7q6rFYCB3/DH7b0GKYQ=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:gUdpOonF+cEDd/Jt1/aGPx+iHx4= sha1:NI9OogglEuKLrYSvblCrkNRVmgE= Stephen Fuld writes: > Yes, but as I have argued before, this was a mistake, and in any event > base registers became obsolete when virtual memory became available > (though, of course, IBM kept it for backwards compatibility). OS/360 "relocatable" ... included address constants in executable images that had to be modified when first loaded into real storage (which continued after move to virtual storage). The initial decision to add virtual memory to all 370s was based on the fact that OS/360 "MVT" storage management was so bad that (concurrently loaded) executable sizes had to be specified four times larger than used .... so typical 1mbyte (real storage) 370/165 only ran four concurrently executing regions, insufficient to keep 165 busy and justified. Running MVT in a (single) 16mbyte virtual address space, aka VS2/SVS (sort of like running MVT in a CP67 16mbyte virtual machine) allowed concurrently running regions to be increased by a factor of four (modulo 4bit storage protection keys required for isolating each region) with little or no paging. As systems got larger they needed to run more than 15 concurrent regions (storage protect key=0 for kernel, 1-15 for regions). As a result they move to VS2/MVS ... a separate 16mbyte virtual address space for each region (to eliminate storage protect key 15 limit on concurrently executing regions). However since OS/360 APIs were heavily pointer passing, they map an 8mbyte kernel image into every virtual address space (allowing pointer passing kernel calls to use passed pointer directly) ... leaving 8mbyte for each region. However kernel subsystems were also mapped into their own, separate 16mbyte virtual address space. For (pointer passing) application calls to subsystem, a one megabyte "common segment area" ("CSA") was mapped into every 16mbyte virtual address space for pointer passing API calls to subsystems ... leaving 7mbytes for every application. However, by later half of 70s & 3033 processor, since the total common segment API data space was somewhat proportional to number of subsystems and number of concurrently executing regions ... the one mbyte "common SEGMENT area" was becoming 5-6mbyte "common SYSTEM area", leaving only 2-3mbytes for applications ... but frequently threatening to become 8mbyte (leaving zero bytes for applications). This was part of desperate need to migrate from MVS to 370/XA and MVS/XA with 31-bit addressing as well as "access registers" ... where call to subsystem switched the caller's address space pointer to the secondary address space and loads the called subsystem address space pointer into the primary address space ... allowing subsystem to directly address caller's API data in (secondary address space) private area (not needing to be placed in a "CSA"). The subsystem then returns to the caller .... and the caller's address space pointer is switched back from secondary to primary. -- virtualization experience starting Jan1968, online at home since Mar1970