[email protected] (David Andrews) writes:
> I vaguely remember the dual-address-space-facility that began life just
> before XA came around.  There was some exploitation of it in - I think -
> MVS/SE2 (or was it SP1?).

in the wake of the failure of FS 
http://www.garlic.com/~lynn/submain.html#futuresys

... they kicked off 3033, 3081 & xa-architecture approximately
concurrently 
http://www.garlic.com/~lynn/2014d.html#54 Difference between MVS and z / OS 
systems

but the extensive pointer passing api and need to map common address ...
by late in 3033 period, the combination of mvs kernel and common segment
(morphed into common system area) was on the verged of taking up all the
area in the 16mbyte virtual address space given to each application for
execution. 

One of the people that was involved in XA, the (aborted) effort to use
801/risc (Iliad chip) as the microprocessor for low & mid-range 370
... do a retrofit of a subset of XA multi-address space addressing to
3033 as dual-address space mode ... as a way of trying to take some
pressure off the need for the constant growth in common system area size
(for passing parameters between address spaces). dual-address space mode
allowed semi-privileged subsystem to access parameter list in calling
application parameter list ... w/o it having to be in the common system
area.

he was working on 801/risc Iliad chip right up until the time he left
for HP Labs ... where he worked on the HP risc chip (snake) used in
their line of machines. He then was the lead architecture (at HP) on the
architecture for Itanium. shortly after he left for HP Labs ... I was
getting email asking if I was going to join him.

past posts mentioning 801, risc, iliad, romp, rios, power, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

the other problem that mvs had in the 3033 time-frame was that it not
only was in danger of taken up the whole 16mbyte virtual address space
... but its really bloated implementation was starting to overwhelm
16mbyte real storage limitation. Besides dual-address hack for 3033,
another hack was rasing real storage to 64mbytes ... even though there
was only 24bit addressing. There was two unused bits in the 16bit page
table entry (that mapped a virtual page number of real page number).
The hack was to prepend the two unused bits to the existing 12bit page
number allowing addressing up to 64mbytes (the 12bit virtual page number
mapped into a 14bit real page number). It wasn't possible to directly
address any of the storage about the 16mbyte line ... except via
virtual page number.

Fortunately for I/O there was IDAL ... originally introduced in 370 to
handle a problem with overruns involving non-contiguous page crossing
i/os (360/370 channel architecture precluded prefetching of CCWs so
data-chaining could sometime overrun since it had to wait for the i/o
transfer on the previous ccw to complete before it could fetch the
following ccw ... IDALs lifted that restriction allowing all addresses
in IDALs to be prefetched). In any case the IDAL field was 32bits ...
allowing I/O transfer addresses in the greater than 16mbyte area to be
addressed.

Especially in vm370 ... when virtual machine data in a virtual page
above the 16mbyte line needed to be addressed ... it had to be brought
down below the line. There original approach was to write the page to
disk and then read it back in below the line. I provided them with a
hack using dummy page table entries where a MVCL in virtual mode could
bring the page down below the line (w/o resorting to in/out page i/o).

as an aside, in the wake of the FS failure, POK kicked off 3033, 3081,
and XA architecture. At the same time, Endicott kicked off 138/148,
138/148 ECPS ... mentioned here:
http://www.garlic.com/~lynn/2014d.html#59 Difference between MVS and z / OS 
systems

the 4331/4341 and E-architure. The 4331/4341 was approx. mid-range
analogy to the 3081 ... except it was all brand new technology and
finished much faster than the use of the warmed over FS technology
for 3081 ... discussed here:
http://www.jfsowa.com/computer/memo125.htm

The E-architecture for DOS/VS and VS1 was sort of the low/mid-range
analogy to XA architecture for MVS. However, its primary feature was
moving much of the single virtual address space operation into
microcode. DOS/VS (virtual dos/360) and VS1 (for os/360 mft) did
something similar that OS/VS2 SVS did ... map the real kenel operation
into single virtual address space ... sort of like emulating a large
real memory machine. E-architecture moved a lot of what was the 370
virtual pagetables into the microcode layer.

However, the big explosion in 4300 machines were with vm/370 ... which
required separate (370) virtual address space for each virtual machine
... and so E-architecture didn't catch on like XA did (although you see
its influence in the "name" VSE).

Another 4341 issue was that they were out in late 70s, overlapped with
3033 and well before 3081. Cluster of vm/4341s had more processing power
than 3033, larger aggregate memory than 3033, high aggregate i/o than
3033, and much less expensive (and more cost/effective) than 3033. While
lots of 4300s were publically positioned as competition to other
mid-range like DEC VAX ... POK 3033 also felt the competitive heat, and
at one point the head of POK managed to have the allocation of a
critical 4341 manufacturing component cut in half. some old 4300 email
http://www.garlic.com/~lynn/lhwemail.html#43xx

other posts in this thread:
http://www.garlic.com/~lynn/2014d.html#55 Difference between MVS and z / OS 
systems
http://www.garlic.com/~lynn/2014d.html#56 Difference between MVS and z / OS 
systems
http://www.garlic.com/~lynn/2014d.html#57 Difference between MVS and z / OS 
systems
http://www.garlic.com/~lynn/2014d.html#60 Difference between MVS and z / OS 
systems
http://www.garlic.com/~lynn/2014d.html#61 Difference between MVS and z / OS 
systems

-- 
virtualization experience starting Jan1968, online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to