Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
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>
	<ve5ek3$2jamt$1@dont-email.me>
	<2024Oct13.174537@mips.complang.tuwien.ac.at>
	<vejbts$1772o$2@dont-email.me>
	<3e885f3c9d768541e2b07180d5821a1f@www.novabbs.org>
	<1sePO.260703$v8v2.138100@fx18.iad>
	<20241018124753.00002084@yahoo.com>
	<tXtQO.77260$UZH4.60981@fx44.iad>
	<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 <already5chosen@yahoo.com> writes:
> >On Fri, 18 Oct 2024 14:06:17 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
> >  
> >> Michael S <already5chosen@yahoo.com> 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/