re:
http://www.garlic.com/~lynn/2013c.html#31 REFRPROT History Question
Note this is part of old exchange of trying to get page protect for 3033
... included in same hardware hits for MVSA microcode assist
Date: 02/27/80 08:37:42
From: wheeler
re: yesterday's protect bit discussion. -- It does make a difference
whether the proctect bit is in the page table entry or segment table
entry (page table entry bit , I think may have originated MVS 811
hardware to provide them selective storage protection in addition to
don't p*** on page zero for system protection). I was spending too
much time thinking about the hardware implementation. Segment table
entry protect bit provides selective protection for some users and the
possibility of no protection for others, i.e. some virtual machines
have R/W shared segments (DWSS) and others only have R/O
access. Segment table protect bit is also defined in the original 370
architecture.
.. Lynn W., K03/281, San Jose Res., 408-256-1783 (8-276)
referenced note:
MY VERSION OF HARDWARE PAGE PROTECTION: WHEN UNDERTAKING AP
DESIGN, SHARED PAGE PROBLEM WAS OBVIOUS. FIRST, I WAS TOLD BY POK
MANAGEMENT (zzzzzzzz) THAT CMS MUST UTILIZE VMA MICROCODE. THIS WAS
BECAUSE IBM WAS SELLING VMA TO 168 CUSTOMERS, AMONG OTHER REASONS. SO
WE TRIED FOR PAGE PROTECTION. ARCHITECTURE SAID O.K. MVS SAID IT
WOULD MAKE A NICE RAS TOOL, BUT THEY REALLY DID NOT CARE, AND DID NOT
GET INVOLVED IN NEGOTIATIONS. WE DID NOT GET PAGE PROTECTION BECAUSE
OF 168 MANUFACTURING. OUR EC WOULD HAVE HIT SEVERAL OF THE SAME CARDS
AS MVSA (THEN IN THE WORKS). 168 PEOPLE INSISTED ON COMBINING PAGE
PROTECT WITH MVSA TO REDUCE MANUFACTURING AND RECORD KEEPING
COMPLEXITY. BUSINESS PEOPLE THEN SAID VM CUSTOMERS WOULD HAVE TO
SHARE MVSA COSTS, SINCE IT WOULD BE PART OF PAGE PROTECT PACKAGE. AT
THIS POINT VM BUSINESS CASE COLLAPSED AND WE GAVE UP THE FIGHT.
THE ONLY APPARENT ALTERNATIVE WAS TO ADOPT YOUR 'FACETIOUS' SUGGESTION
TO DUPLICATE ALL SHARED SEGMENTS. WHAT SHOULD WE HAVE DONE??
.....
ABOUT CHANGES TO VMA SHARED PAGE SCAN, xxxxxxx, yyyyyyyy, AND I
CERTAINLY ATTEMPTED TO OPTIMIZE BOTH SOFTWARE AND MICROCODE. THE
MICROCODE DID NOT ALLOW FOR RELOCATABLE SHARED SEGMENTS SINCE WE DID
NOT UNDERSTAND THE DESIRABILITY OF DOING SO. I SEE THIS AS PRIMARILY
YOUR FAULT. SINCE YOU ENVISIONED THIS REQUIREMENT, YOU SHOULD HAVE
EXPLAINED IT TO US. I CERTAINLY WOULD HAVE LISTENED.
... snip ....
"xxxxxx, yyyyyy, zzzzzzz" are to protect some of the guilty.
DWSS was internal support for the original relational database
implementation, system/r
http://www.garlic.com/~lynn/submain.html#systemr
and getting DWSS included in protect as shipping system/r as sql/ds
(in period when favorite son operations were pre-occupied with getting
out EAGLE as the new strategic database ... it wasn't until EAGLE
crash&burn that attention was turned to possibly doing version of
systemr/sqlds as DB2).
In a shared segment with same page table used by all virtual address
spaces, a protection bit in the page table entry would apply to all
address spaces. There was a unique segment table entry for every
address space ... so with segment protect bit, it was possible to have
some address spaces with the protect bit on and other address spaces
with protect bit off.
Part of my full paged-mapped memory and shared segment support (small
subset shipped in vm370 release 3) was any shared segment could occur at
any virtual address in any virtual address space (even concurrently at
different virtual addresses). The issue was limited to 16mbyte, 64kbyte
shared segments was limited to 256 ... take out some system overhead and
requirement for some shared systems being multiple shared segments
... possibly limited the number of unique shared systems around one
hundred or so (across the whole system if unique system-wide virtual
address was required for each shared application image). Relocating
shared segments eliminated requirement for unique system-wide virtual
address for each shared application. Then a specific CMS was limited to
hundred or so concurrent shared applications (but in any combination
... rather than having the limitation system-wide). misc. pasts memory
mapped posts
http://www.garlic.com/~lynn/submain.html#mmap
lots of old posts discussing problems that I had creating location free
code (i.e. image on disk could be loaded at any virtual address w/o
having to change it ... and the same image could occur simultaneously in
multiple different address spaces at potentially different addresses)
http://www.garlic.com/~lynn/submain.html#adcon
this showed up because lots of CMS applications were done using os/360
compilers which generated relocatable address constants ... which had to
be swizzled after loading .... fixing them to specific address. I
basically had to undo all relocatable address constants in order to
create location free code.
as an aside, lots of stuff I've done over the years, people have
repeatedly claimed that it was my fault that they were unable to
understand how great they were.
In the microcode assist arena, vm370 VMA would include virtual machine
rules as option as part of machine instruction execution (avoiding
several hundred instruction pathlength interrupt thru the vm370
kernel, reducing vm370 overhead from several hundred times to a couple
percent). The other area of microcode assist was duplicating kernel
pathlength instructions in microcode. This was done for the 138/148
ECPS ... discussed in this old post:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
these were vertical microcode machines averaging 10 native instruction
for every 370 instruction. ECPS did approx. one-for-one replacement
getting ten times performance improvement. The problem was different
with the high-end horizontal microcode machines, especially as things
improved, 165 was approx. 2.1machine cycles per 370 instructions, 168
was 1.6machine cycles per 370, and 3033 it was done to apporx. 1:1
... nearly one machine cycle per 370 instruction. It was basically
impossible to get any speedup doing ECPS-like microcode enhancements
... and because of certain side-effects, such microcode could even run
slower than the 370 software implementation. I was told that was what
happened with the MVS microcode on 3033 ... and people wanted all trace
of their involvement erased ... since the features were supposedly
justified as performance speedup ... and looking at benchmark numbers,
it might be viewed that the requirement for new microcode in new MVS
releases might have been done for other reasons.
--
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
