Sujet : Re: 80286 protected mode
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.archDate : 19. Oct 2024, 17:46:41
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241019194641.0000213b@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
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/
Date | Sujet | # | | Auteur |
16 Apr 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 237 | | Lawrence D'Oliveiro |
16 Apr 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 236 | | David Brown |
16 Apr 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | MitchAlsup1 |
26 May 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | MitchAlsup1 |
1 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 233 | | MitchAlsup1 |
1 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 232 | | Thomas Koenig |
1 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 225 | | MitchAlsup1 |
2 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 223 | | Brett |
3 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 222 | | Lawrence D'Oliveiro |
3 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | Brett |
3 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | Anton Ertl |
3 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 219 | | David Brown |
3 Oct 24 | Byte ordering (was: Whether something is RISC or not) | 218 | | Anton Ertl |
3 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 1 | | David Brown |
4 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 215 | | Lawrence D'Oliveiro |
4 Oct 24 | Re: Byte ordering | 1 | | Lynn Wheeler |
4 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 211 | | David Brown |
4 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 210 | | Anton Ertl |
4 Oct 24 | Re: Byte ordering | 5 | | BGB |
5 Oct 24 | Re: Byte ordering | 4 | | MitchAlsup1 |
5 Oct 24 | Re: Byte ordering | 2 | | BGB |
5 Oct 24 | Re: Byte ordering | 1 | | Lawrence D'Oliveiro |
5 Oct 24 | Re: Byte ordering | 1 | | Lawrence D'Oliveiro |
5 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 13 | | Lawrence D'Oliveiro |
5 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 12 | | Brett |
5 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 11 | | Anton Ertl |
5 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 10 | | Michael S |
6 Oct 24 | Re: Byte ordering | 1 | | Terje Mathisen |
6 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 8 | | Brett |
7 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 7 | | Lawrence D'Oliveiro |
7 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 6 | | Brett |
7 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 5 | | Michael S |
7 Oct 24 | Re: Byte ordering | 2 | | Stefan Monnier |
7 Oct 24 | Re: Byte ordering | 1 | | Michael S |
7 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 2 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: Byte ordering | 1 | | Terje Mathisen |
6 Oct 24 | Re: Byte ordering | 191 | | David Brown |
6 Oct 24 | Re: Byte ordering | 190 | | Anton Ertl |
6 Oct 24 | Re: Byte ordering | 189 | | John Dallman |
7 Oct 24 | Re: Byte ordering | 20 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: Byte ordering | 19 | | John Dallman |
9 Oct 24 | VMS/NT memory management (was: Byte ordering) | 1 | | Stefan Monnier |
15 Oct 24 | Re: Byte ordering | 2 | | Lawrence D'Oliveiro |
15 Oct 24 | Re: Byte ordering | 1 | | MitchAlsup1 |
15 Oct 24 | Re: Byte ordering | 15 | | Lawrence D'Oliveiro |
15 Oct 24 | Re: Byte ordering | 3 | | Michael S |
15 Oct 24 | Re: Byte ordering | 1 | | John Dallman |
18 Oct 24 | Re: Byte ordering | 1 | | Lawrence D'Oliveiro |
15 Oct 24 | Re: Byte ordering | 9 | | John Dallman |
16 Oct 24 | Re: Byte ordering | 7 | | George Neuner |
16 Oct 24 | Re: Byte ordering | 6 | | Terje Mathisen |
16 Oct 24 | Re: Byte ordering | 5 | | David Brown |
17 Oct 24 | Re: Byte ordering | 2 | | George Neuner |
17 Oct 24 | Re: Byte ordering | 1 | | David Brown |
17 Oct 24 | Re: clouds, not Byte ordering | 2 | | John Levine |
17 Oct 24 | Re: clouds, not Byte ordering | 1 | | David Brown |
18 Oct 24 | Re: Byte ordering | 1 | | Lawrence D'Oliveiro |
16 Oct 24 | Re: Byte ordering | 2 | | Paul A. Clayton |
18 Oct 24 | Re: Microkernels & Capabilities (was Re: Byte ordering) | 1 | | Lawrence D'Oliveiro |
7 Oct 24 | 80286 protected mode | 168 | | Anton Ertl |
7 Oct 24 | Re: 80286 protected mode | 5 | | Lars Poulsen |
7 Oct 24 | Re: 80286 protected mode | 4 | | Terje Mathisen |
7 Oct 24 | Re: 80286 protected mode | 1 | | Michael S |
7 Oct 24 | Re: 80286 protected mode | 2 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: 80286 protected mode | 1 | | Terje Mathisen |
7 Oct 24 | Re: 80286 protected mode | 3 | | Brett |
7 Oct 24 | Re: 80286 protected mode | 2 | | Michael S |
7 Oct 24 | Re: 80286 protected mode | 1 | | Brett |
7 Oct 24 | Re: 80286 protected mode | 1 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: 80286 protected mode | 152 | | MitchAlsup1 |
8 Oct 24 | Re: 80286 protected mode | 4 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: 80286 protected mode | 3 | | MitchAlsup1 |
9 Oct 24 | Re: 80286 protected mode | 1 | | David Brown |
15 Oct 24 | Re: 80286 protected mode | 1 | | Lawrence D'Oliveiro |
8 Oct 24 | Re: 80286 protected mode | 147 | | Anton Ertl |
8 Oct 24 | Re: 80286 protected mode | 1 | | Robert Finch |
9 Oct 24 | Re: 80286 protected mode | 145 | | David Brown |
9 Oct 24 | Re: 80286 protected mode | 79 | | MitchAlsup1 |
9 Oct 24 | Re: 80286 protected mode | 78 | | David Brown |
9 Oct 24 | Re: 80286 protected mode | 77 | | Stephen Fuld |
10 Oct 24 | Re: 80286 protected mode | 2 | | MitchAlsup1 |
10 Oct 24 | Re: 80286 protected mode | 1 | | David Brown |
10 Oct 24 | Re: 80286 protected mode | 1 | | David Brown |
11 Oct 24 | Re: 80286 protected mode | 73 | | Tim Rentsch |
15 Oct 24 | Re: 80286 protected mode | 72 | | Stefan Monnier |
15 Oct 24 | Re: 80286 protected mode | 30 | | MitchAlsup1 |
16 Oct 24 | Re: 80286 protected mode | 25 | | MitchAlsup1 |
16 Oct 24 | Re: C and turtles, 80286 protected mode | 13 | | John Levine |
16 Oct 24 | Re: C and turtles, 80286 protected mode | 7 | | MitchAlsup1 |
16 Oct 24 | Re: C and turtles, 80286 protected mode | 6 | | John Levine |
17 Oct 24 | Re: C and turtles, 80286 protected mode | 5 | | Thomas Koenig |
20 Oct 24 | Re: C and turtles, 80286 protected mode | 4 | | Lawrence D'Oliveiro |
20 Oct 24 | Re: C and turtles, 80286 protected mode | 3 | | George Neuner |
22 Oct 24 | Re: C and turtles, 80286 protected mode | 2 | | Tim Rentsch |
22 Oct 24 | Re: C and turtles, 80286 protected mode | 1 | | George Neuner |
16 Oct 24 | Re: C and turtles, 80286 protected mode | 1 | | David Brown |
16 Oct 24 | Re: C and turtles, 80286 protected mode | 4 | | Paul A. Clayton |
17 Oct 24 | Re: C and turtles, 80286 protected mode | 1 | | David Brown |
20 Oct 24 | Re: C and turtles, 80286 protected mode | 2 | | Lawrence D'Oliveiro |
20 Oct 24 | Re: C and turtles, 80286 protected mode | 1 | | Paul A. Clayton |
16 Oct 24 | Re: 80286 protected mode | 7 | | Thomas Koenig |
17 Oct 24 | Re: 80286 protected mode | 3 | | George Neuner |
17 Oct 24 | Re: 80286 protected mode | 1 | | Tim Rentsch |
16 Oct 24 | Re: 80286 protected mode | 3 | | David Brown |
17 Oct 24 | Re: 80286 protected mode | 1 | | Tim Rentsch |
16 Oct 24 | Re: 80286 protected mode | 41 | | David Brown |
9 Oct 24 | Re: 80286 protected mode | 51 | | Thomas Koenig |
13 Oct 24 | Re: 80286 protected mode | 14 | | Anton Ertl |
8 Oct 24 | Re: 80286 protected mode | 6 | | John Levine |
6 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 2 | | Michael S |
4 Oct 24 | Re: Byte ordering (was: Whether something is RISC or not) | 1 | | John Dallman |
2 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | Thomas Koenig |
2 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 5 | | David Schultz |
3 Oct 24 | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) | 1 | | Lawrence D'Oliveiro |