Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: what's a segment, 80286 protected mode Date: Mon, 06 Jan 2025 17:28:11 -1000 Organization: Wheeler&Wheeler Lines: 43 Message-ID: <87frlvjoac.fsf@localhost> References: <2025Jan5.121028@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 07 Jan 2025 04:28:17 +0100 (CET) Injection-Info: dont-email.me; posting-host="82354d9c1eef7867da25864c93ab5fdb"; logging-data="2153717"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dBotO32o6eXkcFUVOSSyJAxPFbMh3vvI=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:nb58WQoUhqKqkFBbGs9LWUg2bGI= sha1:TAWenVinwYcPTL4YPeHqpT95o+Q= Xref: csiph.com comp.arch:110419 John Levine writes: > What you're describing is multi-level page tables. Every virtual > memory system has them. Sometimes the operating systems make the > higher level tables visible to applications, sometimes they don't. For > example, in IBM mainframes the second level page table entries, which > they call segments, can be shared between applications. initial adding virtual memory to all IBM 370s was similar to 24bit 360/67 but had options for 16 1mbyte segments or 256 64kbyte segments and either 4kbyte or 2kbyte pages. Initial mapping of 360 MVT to VS2/SVS was single 16mbyte address space ... very similar to running MVT in a CP/67 16mbyte virtual machine. The upgrade to VS2/MVS gave each region its own 16mbyte virtual address space. However, OS/360 MVT API heritage was pointer passing API ... so they mapped a common 8mbyte image of the "MVS" kernel into every 16mbyte virtual address space (leaving 8mbytes for application code), kernel API call code could still directly access user code API parameters (basically same code from MVT days). However, MVT subsystems were also moved into their separate 16mbyte virtual address space ... making it harder to access application API calling parameters. So they defined a common segment area (CSA), 1mbyte segment mapped into every 16mbyte virtual address space, application code would get space in the CSA for API parameter information calling subsystesm. Problem was the requirement for subsystem API parameter (CSA) space was proportional to number of concurrent applications plus number of subsystems and quickly exceed 1mbyte ... and it morphs into multi-megabyte common system area. By the end of the 70s, CSAs were running 5-6mbytes (leaving 2-3mbytes for programs) and threatening to become 8mbytes (leaving zero mbytes for programs)... part of the mad rush to XA/370 and 31-bit virtual addressing (as well as access registers, and multiple concurrent virtual address spaces ... "Program Call" instruction had a table of MVS/XA address space pointers for subsystems, the PC instruction whould move the caller's address space pointer to secondary and load the subsystem address space pointer into primary ... program return instruction reversed the processes and moved the secondary pointer back to primary). -- virtualization experience starting Jan1968, online at home since Mar1970