Far and near pointers on the 80286 and later

On Apr 9, 9:40*am, Anne & Lynn Wheeler wrote:
Bill Davidsen writes:
One of the things which separated MULTICS from most other operating
systems was the way in which rings were used. Many operating systems
use (or mostly use) only two rings, similarly to the "master mode" and
"slave mode" of 1960's computers. By putting things like libraries and
privileged linked programs (terminology escapes me, it's been ~40
years) in rings, access could be more nuanced.

370xa started out with access registers and then added program call (&
return).

issue was that favorite son batch operating system heritage (from real
memory environment) was extensively pointer-passing API.

In the initial transition to virtual memory (OS/VS2 SVS) it was just a
single large virtual memory (pointer-passing APIs still working).

In the migration to MVS ... each application was given its own address
space ... but an image of the MVS kernel appeared in (8mbyte) half of
each (16mbyte) virtual address space (pointer passing API easily worked
since MVS kernel code as in the same address space of each application).

The problem was that there were a lot of "subsystems" (semi-privileged
operations) that had resided outside the kernel (called by applications
with pointer passing API) that were now in their own virtual address
space (i.e. application would generate system call and the kernel would
invoke the subsystem in its own virtual address space).

To continue with pointer-passing API, a "common segment" was created
that also resided in each virtual address space. This started out was
1mbyte of each virtual address space ... but grew ... somewhat
proportional to the number of independent subsystems and the number of
concurrent executing applications. eventually in the timeframe of of
large 3033s ... common segments were threatening to exceed five mbytes
(growing to six ... leaving only 2mbytes for applications in each
application virtual address space).

to start to address the problem ... a subset of 370xa access registers
were introduced in 3033 called dual-address space mode. Application wold
make kernel call to invoke subsystem, kernel would swap the home &
alternate virtual address space pointers before invoking the
subsystem. each instance of subsystem execution would have alternate
address space pointer to its invoking application ... and could directly
address the invoking applications virtual address space.

Now 370xa introduced introduced access registers with more generalized
implemenation of dual-address space as well as 31bit virtual addressing
(31bit virtual addressing would have alleviated the common segment
attempting to completely take-over remaining application area in each
virtual address space).

program call (& return) ... application instruction that references a
kernel hardware table ... that defines available "subsystems" and the
rules for changing around the address space pointers. now applications
can directly invoke a subsystem in different address space, w/o the
overhead of kernel call processing (much like a library routine call
that resides in the same address space).


Hmmm... "Modern" access registers didn't show up until ESA in about
1990. DAS was introduced in S/370, no later than 1980 (actually I'm
not sure exactly when DAS capable hardware shipped, but MVS/SP1, which
was the first release to support DAS, shipped in 1980). XA happened
in 1983. Of course I don't know for sure, but it seems unlikely that
access registers were planned that far before their introduction.
More likely they were an upwards compatible way to extend the DAS
support.

And Program Call / Program Transfer were introduced with DAS. XA
didn't really do much to DAS and PC/PT, other than fairly obvious
extensions to 31 bit (and a bit of cleanup - IIRC, some stuff like
which address space instructions were fetched from in secondary space
mode got nailed down in XA). XA was mostly about 31 bit mode and a
total revamp of the I/O subsystem. ESA did substantially enhance DAS
(with AR support), and added a number of extensions to PC/PT (and
those have continued as the architecture has evolved).

" writes:
Hmmm... "Modern" access registers didn't show up until ESA in about
1990. DAS was introduced in S/370, no later than 1980 (actually I'm
not sure exactly when DAS capable hardware shipped, but MVS/SP1, which
was the first release to support DAS, shipped in 1980). XA happened
in 1983. Of course I don't know for sure, but it seems unlikely that
access registers were planned that far before their introduction.
More likely they were an upwards compatible way to extend the DAS
support.

And Program Call / Program Transfer were introduced with DAS. XA
didn't really do much to DAS and PC/PT, other than fairly obvious
extensions to 31 bit (and a bit of cleanup - IIRC, some stuff like
which address space instructions were fetched from in secondary space
mode got nailed down in XA). XA was mostly about 31 bit mode and a
total revamp of the I/O subsystem. ESA did substantially enhance DAS
(with AR support), and added a number of extensions to PC/PT (and
those have continued as the architecture has evolved).


http://www.garlic.com/~lynn/2010g.html#83 Far and near pointers on the 80286 and later

access registers were in the 811 architecture documents ... named for
being dated nov1978. this may be slightly analogous to IPTE, ISTE, ISTO
and other features were in the original 370 architecture (before any 370
machines shipped). Some number of machines implemented the full-set of
370 architecture ... but then the 165 group said they could save six
month schedule retrofitting virtual memory if they dropped a bunch of
stuff (which then required the other groups to go back and remove the
extra features and retrench to just the 165 subset of 370).

dual-address space mode was shipped as part of 3033. it was part of
misc. stuff sometimes referred to as mvs microcode performance assist
.... somewhat analogous to vm370 microcode performance assist done for
4341.

the problem was that 4341 machine was vertical microcode that did about
10 natives instructions per 370 instruction. The 3033 was horizontal
microcode where 370 instructions already ran close to machine cycle
.... so never saw the 10:1 performance improvement that came with ECPS.
old discussion
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

it turned out that the mvs microcode performance assist could actually
run slower on 3033 ... than straight 370 implementation.

the scenario was that after killing future system
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush getting products back into the 370 product pipeline
(in parallel with launching xa ... which was going to take 7-8 yrs).

they took 370/158 engine with its integrated channel microcode and
created the 303x channel director (running just the channel micrcode
but w/o the 370 microcode).

3031 became 370/158 engine with just 370 microcode and a 2nd
370/158 engine with just the integrated channel microcode

3032 became 370/168 reconfigured to work with 303x channel directo

3033 started out being 168 wiring diagram mapped to 20% faster chips.
these chips had 10 times the circuits that were going to be mostly
unused. there was some optimization to better use the extra on-chip
circuts that managed to get 3033 performance up to 1.5 times 168.

the 168 had a 7-entry sto (aka virtual address space) stack TLB ...
which carried over to 3033. the addition of dual-address space support
was creating lots more different address spaces to being used in short
period of time resulting in overrunning the 7-entry sto stack resulting
in TLB invalidation ... which resulted in degraded performance (compared
to not using dual-address space mode).

for some itanium trivia related to dual-address space mode ... old
post
http://www.garlic.com/~lynn/2005p.html#18 address space
dual address space architecture reference:
http://web.archive.org/web/200107221...n/2worley.html

related
http://web.archive.org/web/200008160...interview.html
http://www.hpl.hp.com/news/2001/apr-jun/worley.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Anne & Lynn Wheeler writes:
access registers were in the 811 architecture documents ... named for
being dated nov1978.


http://www.garlic.com/~lynn/2010g.html#83 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later

at one point i had file cabinet of 811 documents ... they were
"candy-striped" ... i.e. highest corporate security classification;
individually numbered and signed out to specific person, required
special double-locked security provisions, subject to periodic security
audits.

apparently people that had 811 documents were subject to industrial
espionage (how the information leaked? ... possibly some clerk in the
plant site security office ... since they were responsible for doing the
periodic audits for candy-striped documents and had list of
candy-striped documents in each person's possession).

In my case, a recruiter contacted me ... with job interview for
technical assistent to president of a mainframe clone computer
company. I went to the interview ... but it became pretty clear that
they were interested in the 811 documents. I managed to pretty much
bring the interview to an end when I mentioned that I had suggested
several improvements to the corporate conduct guidelines (that every
employee had to review/reread every year) ... because I thought there
were several loopholes for unethical behavior.

somewhat later the industrial espionage and other stuff came up in
federal court and I got to spend several hrs with FBI agent going over
what was said during my job interview.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

" writes:
Hmmm... "Modern" access registers didn't show up until ESA in about
1990. DAS was introduced in S/370, no later than 1980 (actually I'm
not sure exactly when DAS capable hardware shipped, but MVS/SP1, which
was the first release to support DAS, shipped in 1980). XA happened
in 1983. Of course I don't know for sure, but it seems unlikely that
access registers were planned that far before their introduction.
More likely they were an upwards compatible way to extend the DAS
support.


http://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#3 Far and near pointers on the 80286 and later

another reference to demise of Future System ... and mad rush to get out
303x in parallel with doing "811"
http://www.jfsowa.com/computer/memo125.htm

In 1975, some POK engineers had con'ed me into looking at a 5-way SMP
effort ... it never shipped, but I did an enhanced microcoded
queue i/o design as well as a microcoded multiprocessor dispatching
operation (somewhat akin to the later i432) ... some past posts
http://www.garlic.com/~lynn/submain.html#bounce

In 1976, the head of pok managed to convince corporate that in order to
meet the mvs/xa (aka initial 811) ship schedule, vm370 had to be killed,
the vm370 development group in burlington mall shutdown and everybody
moved to POK (to support mvs/xa development). Later, there were jokes
about head of POK being a major contributor to vax/vms ... since so many
people didn't move and went to work on vms instead. Endicott managed to
save the vm370 product mission ... but effectively had to reconsistute a
development group from scratch. some recent posts mentioning burlington
mall group:
http://www.garlic.com/~lynn/2010.html#4 360 programs on a z/10
http://www.garlic.com/~lynn/2010d.html#59 LPARs: More or Less?
http://www.garlic.com/~lynn/2010d.html#66 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#14 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant)

part of mainframe mailing list thread about later doing another kind of
queued/packetized i/o programming (more than queued operation ...
packetized asynchronous operation for latency masking)
http://www.garlic.com/~lynn/2010f.html#7 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#8 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#16 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#18 What was the historical price of a P/390?

in 1990, US auto manufacturer had C4 taskforce to completely remake
themselves to better respond to foreign/fareast competition ... and they
had in technology vendors to participate. one of the issues was that the
foreign competition had cut in half the 7-8 yrs, industry avg., to turn
out new vehicle (from idea to rolling off the line) ... part of making
foreign competition much more agile and being able to respond to
changing consumer tastes and/or market conditions (and they appeared to
be on the verge of cutting it in half again).

So one of the issues was how could technology vendors help in totally
redoing and cutting their elapsed process in half. Offline, I would
chide the mainframe participants about they were also on a similar
development timeline ... so how could they expect to contribute.

Note that was 20 yrs ago ... and, at least, the auto company seemed
unable to change ... even all the issues and solutions were layed out in
detail. Some recent posts referencing auto maker C4 taskforce
http://www.garlic.com/~lynn/2010b.html#14 360 programs on a z/10
http://www.garlic.com/~lynn/2010e.html#47 z9 / z10 instruction speed(s)
http://www.garlic.com/~lynn/2010e.html#49 z9 / z10 instruction speed(s)
http://www.garlic.com/~lynn/2010f.html#55 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#70 Handling multicore CPUs; what the competition is thinking

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Anne & Lynn Wheeler writes:
for some itanium trivia related to dual-address space mode ... old
post
http://www.garlic.com/~lynn/2005p.html#18 address space
dual address space architecture reference:
http://web.archive.org/web/200107221...n/2worley.html

related
http://web.archive.org/web/200008160...interview.html
http://www.hpl.hp.com/news/2001/apr-jun/worley.html


http://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#3 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#8 Far and near pointers on the 80286 and later

so shortly after availability of 811 documents ... the person referenced
above responsible for 3033 dual-address space, was in STL and had the
only copies in the silicon valley area.

the disk guys were trying to suck me more & more into playing disk
engineer ... some past posts
http://www.garlic.com/~lynn/subtopic.html#disk

including participating in conference calls with POK channel engineers.
something comes up with 811 reference and I need to check a document
.... the only local copies being down in STL. I go down and turns out
there are some authorization issues with access ... so I decide to get a
copy of all the 811 stuff for myself. this takes a little extra time
since all copies have to be justified and I'm not listed as being
responsible for anything (other people with justification have to vouch
for me).

playing disk engineer does inadvertently bring down the wrath of the mvs
organization on my head ... some recent refeences.
http://www.garlic.com/~lynn/2010b.html#38 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#100 "The Naked Mainframe" (Forbes Security Article)
http://www.garlic.com/~lynn/2010c.html#28 Processes' memory
http://www.garlic.com/~lynn/2010d.html#45 What was old is new again (water chilled)
http://www.garlic.com/~lynn/2010d.html#59 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#30 SHAREWARE at Its Finest
http://www.garlic.com/~lynn/2010f.html#53 F.B.I. Faces New Setback in Computer Overhaul
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#32 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#44 16:32 far pointers in OpenWatcom C/C+

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Peter Flass wrote:
OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Are you sure OS/2 actually uses that? The Intel architecture allowed for
upto 4 privilege rings (now it's 5 rings with virtualization). However,
most OS software never used more than 2 rings, highest (for OS &
drivers) and lowest (for apps).

The reason I'm skeptical is because running drivers in anything other
than highest privilege level means you run into performance penalties,
since all hardware accesses by the driver will result in a exception
fault requiring a redirection through the OS first. Not great if your
driver has to respond to hardware signals fast.

Yousuf Khan

On Apr 14, 11:45*pm, Yousuf Khan wrote:
Peter Flass wrote:
OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Are you sure OS/2 actually uses that? The Intel architecture allowed for
upto 4 privilege rings (now it's 5 rings with virtualization). However,
most OS software never used more than 2 rings, highest (for OS &
drivers) and lowest (for apps).

The reason I'm skeptical is because running drivers in anything other
than highest privilege level means you run into performance penalties,
since all hardware accesses by the driver will result in a exception
fault requiring a redirection through the OS first. Not great if your
driver has to respond to hardware signals fast.


In segmented x86, a segment can be accessible at a particular
privilege level (or higher). Thus a segment mapping the I/O device
would be accessible at the ring the device drivers were running in.
Anyway, device drivers in OS/2 always ran in ring zero, so that part
of it is moot. OTOH, an application could have ring 2 segments (aka
"IOPL" segments), which *did* have certain amounts of access to the
real hardware (so selected applications could do user level I/O).

Yousuf Khan wrote:
Peter Flass wrote:
OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Are you sure OS/2 actually uses that? The Intel architecture allowed for
upto 4 privilege rings (now it's 5 rings with virtualization). However,
most OS software never used more than 2 rings, highest (for OS &
drivers) and lowest (for apps).

The reason I'm skeptical is because running drivers in anything other
than highest privilege level means you run into performance penalties,
since all hardware accesses by the driver will result in a exception
fault requiring a redirection through the OS first. Not great if your
driver has to respond to hardware signals fast.

Yousef, you need to read up on the x86 ring architecture!

OS/2 used a separate ring for drivers specifically because that ring had
intermediate privilege, in particular the OS can delegate IO port access
to such a driver.

I.e. a driver had full-speed access, but only to those hardware
resources the OS would agree to give it, so a buggy driver had less
chance of messing up some unrelated hardware/software subsystem.

Terje
--
- Terje.Mathisen at tmsw.no
"almost all programming can be viewed as an exercise in caching"

OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Are you sure OS/2 actually uses that? The Intel architecture allowed
for upto 4 privilege rings (now it's 5 rings with virtualization).
However, most OS software never used more than 2 rings, highest (for
OS & drivers) and lowest (for apps).

16-bit OS/2 most definitely uses three out of the four rings. 16-bit
OS/2 applications can define IOPL segments, that run in ring #2. It's
essentially an official way of Doing Naughty Things With The Hardware.

Yousuf Khan writes:

Peter Flass wrote:
OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Are you sure OS/2 actually uses that? The Intel architecture allowed
for upto 4 privilege rings (now it's 5 rings with
virtualization). However, most OS software never used more than 2
rings, highest (for OS & drivers) and lowest (for apps).

The reason I'm skeptical is because running drivers in anything other
than highest privilege level means you run into performance penalties,
since all hardware accesses by the driver will result in a exception
fault requiring a redirection through the OS first. Not great if your
driver has to respond to hardware signals fast.

One of the many clever features of the x86 is an IO protection bitmap,
permitting a process at any level (even user level) to access hardware
directly, without a kernel trap.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)