Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.arch Subject: Re: 80286 protected mode Date: Sat, 19 Oct 2024 19:46:41 +0300 Organization: A noiseless patient Spider Lines: 145 Message-ID: <20241019194641.0000213b@yahoo.com> References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <2024Oct13.174537@mips.complang.tuwien.ac.at> <3e885f3c9d768541e2b07180d5821a1f@www.novabbs.org> <1sePO.260703$v8v2.138100@fx18.iad> <20241018124753.00002084@yahoo.com> <20241018173416.00004a0f@yahoo.com> <0UvQO.100333$xO0f.88362@fx48.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Sat, 19 Oct 2024 18:46:47 +0200 (CEST) Injection-Info: dont-email.me; posting-host="4b2aa2bd44702e06c3fbf5997e0631a8"; logging-data="4166709"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/kNB7NoMO/rJ8Ay3m/jnwQ646c9K2MUVA=" Cancel-Lock: sha1:uRz51gsTNUfRJuyDOyTPW3ox03Q= X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32) Bytes: 7485 On Fri, 18 Oct 2024 16:19:08 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S writes: > >On Fri, 18 Oct 2024 14:06:17 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S writes: > >> >On Mon, 14 Oct 2024 19:39:41 GMT > >> >scott@slp53.sl.home (Scott Lurndal) wrote: > >> > > >> >> mitchalsup@aol.com (MitchAlsup1) writes: > >> >> >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > >> >> > > >> >> >> On 13/10/2024 17:45, Anton Ertl wrote: > >> >> > > >> >> >> I do think it would be convenient if there were a fully > >> >> >> standard way to compare independent pointers (other than > >> >> >> just for equality). Rarely needing something does not mean > >> >> >> /never/ needing it. > >> >> > > >> >> >OK, take a segmented memory model with 16-bit pointers and a > >> >> >24-bit virtual address space. How do you actually compare to > >> >> >segmented pointers ?? > >> >> > >> >> Depends. On the Burroughs mainframe there could be eight > >> >> active segments and the segment number was part of the pointer. > >> >> > >> >> Pointers were 32-bits (actually 8 BCD digits) > >> >> > >> >> S s OOOOOO > >> >> > >> >> Where 'S' was a sign digit (C or D), 's' was the > >> >> segment number (0-7) and OOOOOO was the six digit > >> >> offset within the segment (500kB/1000kD each). > >> >> > >> >> A particular task (process) could have up to > >> >> one million "environments", each environment > >> >> could have up to 100 "memory areas (up to 1000kD) > >> >> of which the first eight were loaded into the > >> >> processor base/limit registers. Index registers > >> >> were 8 digits and were loaded with a pointer as > >> >> described above. Operands could optionally select > >> >> one of the index registers and the operand address > >> >> was treated as an offset to the index register; > >> >> there were 7 index registers. > >> >> > >> >> Access to memory areas 8-99 use string instructions > >> >> where the pointer was 16 BCD digits: > >> >> > >> >> EEEEEEMM SsOOOOOO > >> >> > >> >> Where EEEEEE was the evironment number (0-999999); > >> >> environments starting with D00000 were reserved for > >> >> the MCP (Operating System). MM was the memory area > >> >> number and the remaining eight digits described the > >> >> data within the memory area. A subroutine call could > >> >> call within a memory area or switch to a new environment. > >> >> > >> >> Memory area 1 was the code region for the segment, > >> >> Memory area 0 held the stack and some global variables > >> >> and was typically shared by all environments. > >> >> Memory areas 2-7 were application dependent and could > >> >> be configured to be shared between environments at > >> >> link time. > >> > > >> >What was the size of phiscal address space ? > >> >I would suppose, more than 1,000,000 words? > >> > >> It varied based on the generation. In the > >> 1960s, a half megabyte (10^6 digits) > >> was the limit. > >> > >> In the 1970s, the architecture supported > >> 10^8 digits, the largest B4800 systems > >> were shipped with 2 million digits (1MB). > >> In 1979, the B4900 was introduced supporting > >> up to 10MB (20 MD), later increased to > >> 20MB/40MD. > >> > >> In the 1980s, the largest systems (V500) > >> supported up to 10^9 digits. It > >> was that generation of machine where the > >> environment scheme was introduced. > >> > >> Binaries compiled in 1966 ran on all > >> generations without recompilation. > >> > >> There was room in the segmentation structures > >> for up to 10^18 digit physical addresses > >> (where the segments were aligned on 10^3 > >> digit boundaries). > > > >So, can it be said that ar least some of B6500-compatible models > > No. The systems I described above are from the medium > systems family (B2000/B3000/B4000). I didn't realize that you were not talking about Large Systems. I didn't even know that Medium Systems used segmented memory. Sorry. > The B5000/B6000/B7000 > (large) family systems were a completely different stack based > architecture with a 48-bit word size. The Small systems (B1000) > supported task-specific dynamic microcode loading (different > microcode for a cobol app vs. a fortran app). > > Medium systems evolved from the Electrodata Datatron and 220 (1954) > through the Burroughs B300 to the Burroughs B3500 by 1965. The B5000 > was also developed at the old Electrodata plant in Pasadena > (where I worked in the 80s) - eventually large systems moved > out - the more capable large systems (B7XXX) were designed in > Tredyffrin Pa, the less capable large systems (B5XXX) were designed > in Mission Viejo, Ca. > > >suffered from the same problem as 80286 - the segment of maximal size > >didn't cover all linear (or physical) address space? > >Or their index register width was increased to accomodate 1e9 digits > >in the single segment? > > > >> > >> Unisys discontinued that line of systems in 1992. > > > >I thought it lasted longer. My impresion was that there were still > >hardware implemntation (alongside with emulation on Xeons) sold up > >until 15 years ago. > > Large systems still exist today in emulation[*], as do the > former Univac (Sperry 2200) systems. The last medium system > (V380) was retired by the City of Santa Ana in 2010 (almost two > decades after Unisys cancelled the product line) and was moved > to the Living Computer Museum. > > City of Santa Ana replaced the single 1980 vintage V380 with > 29 windows servers. > > After the merger of Burroughs and Sperry in '86 there were six > different mainframe architectures - by 1990, all but > two (2200 and large systems) had been terminated. > > [*] Clearpath Libra > https://www.unisys.com/client-education/clearpath-forward-libra-servers/