dave@visual1.jhuapl.edu (Dave Weintraub) (03/09/91)
I am in the process of proposing a new 370 (etc.) machine code,
to be submitted as a SHARE requirement, probably in the
Numerically Intensive Computing (NIC) project.
===========================================================================
Statement: Create a new OP code, Move and Discard Character Long.
Enhance the Operating System paging services to recognize
moves of entire pages, and perform these by updating tables.
Justify: (The MVCL instruction is a misnomer. It is really, of course,
Copy Character Long, as the "old" data area is available for usage
after the instruction has been executed.)
When MVCL is used for large data areas (for example, data compaction
on large numeric problems, which can easily involve several 16MB
data chunks), page swap contention becomes a major issue,
as each old and new page must be swapped in, the data copied, and
then the next set of pages swapped in.
With the proposed instruction, if programmers are careful to keep
large (say greater than 40K) areas aligned on page boundaries,
then when the dual page fault occurs, the system could test to see
if an entire page is being moved to another entire page. If so,
no swapping (or byte copying) need actually occur! The page table
could be marked to indicate that the two pages have been interchanged;
both pages would still belong to the active task, as no FREEMAIN is
stated or implied.
For large data areas, it seems that the moving of, say, 200MB of data
could be reduced to about 5K loops of a few dozen instructions,
rather than 10K swapping operations, and 200M actual byte transfers.
If whole pages are not involved on both sides ("old" and "new"),
then the instruction could be treated as (good old) MVCL. In fact,
the test for the special case need only be performed once during
each instruction invocation; if the data areas do not both start
on page boundaries, and both have lengths of a whole number of pages,
then the MVCL situation can be assumed.
=========================================================================
An appeal:
I am NOT a systems internals person; I have no idea how page faults
are really handled, and if this idea can be implemented as stated.
Someone more familiar with MVS (or VM or AIX, which could also benefit)
page swapping methods, is welcome to comment on the feasibility
of this approach!news@ucf1vm.BITNET (03/09/91)
I am in the process of proposing a new 370 (etc.) machine code,
to be submitted as a SHARE requirement, probably in the
Numerically Intensive Computing (NIC) project.
===========================================================================
Statement: Create a new OP code, Move and Discard Character Long.
Enhance the Operating System paging services to recognize
moves of entire pages, and perform these by updating tables.
Justify: (The MVCL instruction is a misnomer. It is really, of course,
Copy Character Long, as the "old" data area is available for usage
after the instruction has been executed.)
When MVCL is used for large data areas (for example, data compaction
on large numeric problems, which can easily involve several 16MB
data chunks), page swap contention becomes a major issue,
as each old and new page must be swapped in, the data copied, and
then the next set of pages swapped in.
With the proposed instruction, if programmers are careful to keep
large (say greater than 40K) areas aligned on page boundaries,
then when the dual page fault occurs, the system could test to see
if an entire page is being moved to another entire page. If so,
no swapping (or byte copying) need actually occur! The page table
could be marked to indicate that the two pages have been interchanged;
both pages would still belong to the active task, as no FREEMAIN is
stated or implied.
For large data areas, it seems that the moving of, say, 200MB of data
could be reduced to about 5K loops of a few dozen instructions,
rather than 10K swapping operations, and 200M actual byte transfers.
If whole pages are not involved on both sides ("old" and "new"),
then the instruction could be treated as (good old) MVCL. In fact,
the test for the special case need only be performed once during
each instruction invocation; if the data areas do not both start
on page boundaries, and both have lengths of a whole number of pages,
then the MVCL situation can be assumed.
=========================================================================
An appeal:
I am NOT a systems internals person; I have no idea how page faults
are really handled, and if this idea can be implemented as stated.
Someone more familiar with MVS (or VM or AIX, which could also benefit)
page swapping methods, is welcome to comment on the feasibility
of this approach!rickert@CS.NIU.EDU (Neil Rickert) (03/11/91)
In article <1991Mar8.173043.26275@aplcen.apl.jhu.edu> you write: >I am in the process of proposing a new 370 (etc.) machine code, >to be submitted as a SHARE requirement, probably in the >Numerically Intensive Computing (NIC) project. >With the proposed instruction, if programmers are careful to keep >large (say greater than 40K) areas aligned on page boundaries, >then when the dual page fault occurs, the system could test to see >if an entire page is being moved to another entire page. If so, >no swapping (or byte copying) need actually occur! The page table >could be marked to indicate that the two pages have been interchanged; >both pages would still belong to the active task, as no FREEMAIN is >stated or implied. You can't do that in an instruction. An SVC routine -- yes. An instruction -- no. The page tables are not a hardware feature but a creation of the operating system. Therefore a hardware instruction cannot manipulate them. Sure, there are page tables pointed to by hardware registers. But these table entries contain bits of meaning only to the operating system. Then there are auxiliary tables that map logical pages to swap space on paging disks, which are meaniningful only to the operating system. If you want to try this, try writing a locally defined SVC routine to see how it goes. You will probably find it much more complex than you think. You have to take care of pages fixed in memory for I/O buffers, pages shared with other address spaces, pages with no valid contents (the space has been GETMAINed but nothing yet stored there). Then you have to be concerned about entries in the TLB (Translation Lookaside Buffer) of other processors in a multi-processor environment. Actually, it might be much easier, and much more efficient, to just redesign your algorithm so as to not need this kind of move. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
dave@visual1.jhuapl.edu (Dave Weintraub) (03/11/91)
In article <9103101907.AA18725@ucbvax.Berkeley.EDU>, rickert@CS.NIU.EDU (Neil Rickert) writes: |> |> You can't do that in an instruction. An SVC routine -- yes. An |> instruction -- no. The page tables are not a hardware feature but a |> creation of the operating system. Therefore a hardware instruction |> cannot manipulate them. |> Perhaps I did not make the point clear enough. It is not the intent to have the instruction perform page table manipulation. It is the intent to give the operating system the option of observing when swapping is NOT required, but rather just the mark-up of the page tables.
news@ucf1vm.BITNET (03/11/91)
In article <9103101907.AA18725@ucbvax.Berkeley.EDU>, rickert@CS.NIU.EDU (Neil Rickert) writes: |> |> You can't do that in an instruction. An SVC routine -- yes. An |> instruction -- no. The page tables are not a hardware feature but a |> creation of the operating system. Therefore a hardware instruction |> cannot manipulate them. |> Perhaps I did not make the point clear enough. It is not the intent to have the instruction perform page table manipulation. It is the intent to give the operating system the option of observing when swapping is NOT required, but rather just the mark-up of the page tables.
bzr10@ccc.amdahl.com (Bruce Richardson) (03/12/91)
This "NEW" instruction already exists, it is called Move-Page (MVPG), part of the Move-Page Facility. MVS/ESA's HIPERBATCH makes use of the instruction. Check out the ESA/370 POO (SA22-7200) with TNL SN22-5342. MVPG can be used in three ways: 1) Main-Store to Main-Store 2) Expanded-Store to Main-Store 3) Main-Store to Expanded-Store (Note, no Expanded-Store to Expanded-Store; that will be a later modification to the instruction (IMHO :-) )). The opinions expressed are my own, and do not reflect apon Amdahl Corp, or Amdahl Canada Ltd., etc.
USERALVE@RPITSMTS.BITNET (Brian Eliot) (03/13/91)
MVPG is not a fully-documented instruction. Only its behavior from the viewpoint of the virtual-address-space program is described. Extensions to the page-table-entry format and such to support mapping pages into expanded storage are not in the Principles of Operation. Therefore, I don't see how Dave Weintraub or anyone else for that matter can tell whether MVPG will meet a particular need. Perhaps if Amdahl has reverse-engineered MVPG you could give us a description of how it works? Brian Eliot Information Technology Services Rensselaer Polytechnic Institute
dave@visual1.jhuapl.edu (Dave Weintraub) (03/13/91)
YIn article <9103130448.AA28489@ucbvax.Berkeley.EDU>, USERALVE@RPITSMTS.BITNET (Brian Eliot) writes (in replay to Bruce Richardson's comments on my suggested Move and Discard instruction): |> MVPG is not a fully-documented instruction. Only its behavior from |> the viewpoint of the virtual-address-space program is described. |> Extensions to the page-table-entry format and such to support mapping |> pages into expanded storage are not in the Principles of Operation. |> Therefore, I don't see how Dave Weintraub or anyone else for that |> matter can tell whether MVPG will meet a particular need. |> |> Perhaps if Amdahl has reverse-engineered MVPG you could give us a |> description of how it works? |> |> Brian Eliot |> Information Technology Services |> Rensselaer Polytechnic Institute Thank you, thank you Brian, for expressing what I have been trying to compose for a day now. Our chief systems programmer and I got into a disagreement about exactly what Move Page DOES, let alone whether it would satisfy the intent of my requirement (as our 5890 does not support Move Page (we cannot justify the upgrade), I could not run a test, to see whether "replacement" is to be taken literally, as Bruce Richardson's post would indicate (and which would take care of a part of my requirement), or if it means "copy"). Of course, Move Page does not appear in the Index yet (at least in the -0 documentation, and the TNLs do not update the index pages), and I should point out that in discussion at SHARE with about a dozen IBM systems types, not one suggested the Move Page as a way of handling the requirement. I concur that I would love to see more explanation of the intent and effect of this instruction, certainly before proceeding with the MDCL requirement.
news@ucf1vm.BITNET (03/13/91)
YIn article <9103130448.AA28489@ucbvax.Berkeley.EDU>, USERALVE@RPITSMTS.BITNET
(Brian Eliot) writes (in replay to Bruce Richardson's comments
on my suggested Move and Discard instruction):
|> MVPG is not a fully-documented instruction. Only its behavior from
|> the viewpoint of the virtual-address-space program is described.
|> Extensions to the page-table-entry format and such to support mapping
|> pages into expanded storage are not in the Principles of Operation.
|> Therefore, I don't see how Dave Weintraub or anyone else for that
|> matter can tell whether MVPG will meet a particular need.
|>
|> Perhaps if Amdahl has reverse-engineered MVPG you could give us a
|> description of how it works?
|>
|> Brian Eliot
|> Information Technology Services
|> Rensselaer Polytechnic Institute
Thank you, thank you Brian, for expressing what I have been trying to
compose for a day now. Our chief systems programmer and I got into
a disagreement about exactly what Move Page DOES, let alone whether
it would satisfy the intent of my requirement (as our 5890 does not
support Move Page (we cannot justify the upgrade), I could not
run a test, to see whether "replacement" is to be taken literally,
as Bruce Richardson's post would indicate (and which would
take care of a part of my requirement), or if it means "copy").
Of course, Move Page does not appear in the Index yet (at least in the -0
documentation, and the TNLs do not update the index pages),
and I should point out that in discussion at SHARE with about a dozen
IBM systems types, not one suggested the Move Page as a way of handling the
requirement.
I concur that I would love to see more explanation of the intent and effect
of this instruction, certainly before proceeding with the MDCL requirement.eliot@aix01.aix.rpi.edu (Brian Eliot) (03/14/91)
In article <1991Mar13.145359.8430@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: > Our chief systems programmer and I got into >a disagreement about exactly what Move Page DOES, let alone whether >it would satisfy the intent of my requirement (as our 5890 does not >support Move Page (we cannot justify the upgrade), I could not >run a test, to see whether "replacement" is to be taken literally, >as Bruce Richardson's post would indicate (and which would >take care of a part of my requirement), or if it means "copy"). Move Page does in fact perform a "copy", not a move. It does not manipulate page tables. I agree with those who said what you want to accomplish is better implemented as an operating system service than as a machine instruction. Move Page would be appropriate if the application programmer wished to manage his own "paging" rather than leaving it to the operating system. By arranging to have a portion of the address space mapped into expanded storage, Move Page could be used to explicitly transfer portions of the 200MB array to and from main storage. Brian Eliot Information Technology Services Rensselaer Polytechnic Institute
eliot@UCSD.EDU (Brian Eliot) (03/14/91)
In article <1991Mar13.145359.8430@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: > Our chief systems programmer and I got into >a disagreement about exactly what Move Page DOES, let alone whether >it would satisfy the intent of my requirement (as our 5890 does not >support Move Page (we cannot justify the upgrade), I could not >run a test, to see whether "replacement" is to be taken literally, >as Bruce Richardson's post would indicate (and which would >take care of a part of my requirement), or if it means "copy"). Move Page does in fact perform a "copy", not a move. It does not manipulate page tables. I agree with those who said what you want to accomplish is better implemented as an operating system service than as a machine instruction. Move Page would be appropriate if the application programmer wished to manage his own "paging" rather than leaving it to the operating system. By arranging to have a portion of the address space mapped into expanded storage, Move Page could be used to explicitly transfer portions of the 200MB array to and from main storage. Brian Eliot Information Technology Services Rensselaer Polytechnic Institute
dandrews@bilver.uucp (Dave Andrews) (03/14/91)
In article <1991Mar8.173043.26275@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: >I am in the process of proposing a new 370 (etc.) machine code, >to be submitted as a SHARE requirement, probably in the >Numerically Intensive Computing (NIC) project. >=========================================================================== >Statement: Create a new OP code, Move and Discard Character Long. >Enhance the Operating System paging services to recognize >moves of entire pages, and perform these by updating tables. > > ... justification deleted ... Dave, maybe what you want is not an instruction, but a supervisor service that defines common pages in the same (or different) address space? This mythical service could be used to say "Make the 4K pages at location X and Y point to the same physical page. Discard the existing data (if any) at Y." Any changes made to the address space at X would be immediately echoed at location Y. Another request might be to undo the association, i.e. to invalidate one of the page table entries. This might be a useful cross-memory communication medium, and also be of value in moving LARGE data areas. I'm not sure that the path length is necessarily shorter than moving 16MB however :-) - David Andrews tarpit!bilver!dandrews
news@ucf1vm.BITNET (03/14/91)
In article <1991Mar8.173043.26275@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: >I am in the process of proposing a new 370 (etc.) machine code, >to be submitted as a SHARE requirement, probably in the >Numerically Intensive Computing (NIC) project. >=========================================================================== >Statement: Create a new OP code, Move and Discard Character Long. >Enhance the Operating System paging services to recognize >moves of entire pages, and perform these by updating tables. > > ... justification deleted ... Dave, maybe what you want is not an instruction, but a supervisor service that defines common pages in the same (or different) address space? This mythical service could be used to say "Make the 4K pages at location X and Y point to the same physical page. Discard the existing data (if any) at Y." Any changes made to the address space at X would be immediately echoed at location Y. Another request might be to undo the association, i.e. to invalidate one of the page table entries. This might be a useful cross-memory communication medium, and also be of value in moving LARGE data areas. I'm not sure that the path length is necessarily shorter than moving 16MB however :-) - David Andrews tarpit!bilver!dandrews
terry@uts.amdahl.com (Lewis T. Flynn) (03/16/91)
In article <9103101551.AA15585@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >I am in the process of proposing a new 370 (etc.) machine code, >to be submitted as a SHARE requirement, probably in the >Numerically Intensive Computing (NIC) project. >=========================================================================== >Statement: Create a new OP code, Move and Discard Character Long. >Enhance the Operating System paging services to recognize >moves of entire pages, and perform these by updating tables. [further discussion elided] You may want this to be a SHARE requirement, but not for a new machine instruction. All the necessary features are already there. Rather, this is a request for new operating system function in MVS or VM. Other 370 OSes already give at least some capability in this area or have major features coming. KeyKOS gives the programmer direct control of his address space, UTS currently has shared memory segments and will have the SVR4 mmap system call eventually, and I presume AIX/370 is similar. Both shared memory and mmap allow you to map data into specific addresses in your address space, to unmap it, and to map it in somewhere else. They have different characteristics and limitations and I suspect that mmap is much better for your needs. Regardless, none of this is exactly free (page table and tlb manipulation is pretty expensive no matter who does it) and you should carefully examine your algorithms to avoid the necessity, if possible. Terry
terry@AMES.ARC.NASA.GOV ("Lewis T. Flynn") (03/16/91)
In article <9103101551.AA15585@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >I am in the process of proposing a new 370 (etc.) machine code, >to be submitted as a SHARE requirement, probably in the >Numerically Intensive Computing (NIC) project. >=========================================================================== >Statement: Create a new OP code, Move and Discard Character Long. >Enhance the Operating System paging services to recognize >moves of entire pages, and perform these by updating tables. [further discussion elided] You may want this to be a SHARE requirement, but not for a new machine instruction. All the necessary features are already there. Rather, this is a request for new operating system function in MVS or VM. Other 370 OSes already give at least some capability in this area or have major features coming. KeyKOS gives the programmer direct control of his address space, UTS currently has shared memory segments and will have the SVR4 mmap system call eventually, and I presume AIX/370 is similar. Both shared memory and mmap allow you to map data into specific addresses in your address space, to unmap it, and to map it in somewhere else. They have different characteristics and limitations and I suspect that mmap is much better for your needs. Regardless, none of this is exactly free (page table and tlb manipulation is pretty expensive no matter who does it) and you should carefully examine your algorithms to avoid the necessity, if possible. Terry
LDW@USCMVSA.BITNET (Leonard D Woren) (03/17/91)
On Sun, 10 Mar 91 13:03:10 -0600, Neil Rickert <rickert@CS.NIU.EDU> said: > You can't do that in an instruction. An SVC routine -- yes. An > instruction -- no. The page tables are not a hardware feature but a > creation of the operating system. Therefore a hardware instruction > cannot manipulate them. Really? Ever heard of the MVS assists "OBTAIN LOCAL LOCK", "ADD FRR", etc.? These are (microcoded) instructions which are sensitive to the format of MVS control blocks. Look in the MVS Data Areas manual (or whatever it's called for your release of MVS.) In some control blocks like the ASCB, there are fields marked "this offset fixed by architecture". What could that possibly mean except that there are machine instructions that manipulate those control blocks? Leonard D. Woren Senior MVS Systems Programmer <LDW@USCMVSA.BITNET> <LDW@MVSA.USC.EDU> Disclaimer??? University of Southern California What would be the point?
rickert@CS.NIU.EDU (Neil Rickert) (03/17/91)
In article <9103171023.AA28323@ucbvax.Berkeley.EDU> you write: >On Sun, 10 Mar 91 13:03:10 -0600, > Neil Rickert <rickert@CS.NIU.EDU> said: >> You can't do that in an instruction. An SVC routine -- yes. An >> instruction -- no. The page tables are not a hardware feature but a >> creation of the operating system. Therefore a hardware instruction >> cannot manipulate them. > >Really? Ever heard of the MVS assists "OBTAIN LOCAL LOCK", "ADD FRR", >etc.? These are (microcoded) instructions which are sensitive to the >format of MVS control blocks. Look in the MVS Data Areas manual (or Sure they are. But they are not considered System/3x0 instructions, and are not documented in Principles of Operation. Rather they are considered part of a microcode assist for MVS. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
eliot@aix01.aix.rpi.edu (Brian Eliot) (03/18/91)
> Neil Rickert <rickert@CS.NIU.EDU> said: > >>Really? Ever heard of the MVS assists "OBTAIN LOCAL LOCK", "ADD FRR", >>etc.? > > Sure they are. But they are not considered System/3x0 instructions, and >are not documented in Principles of Operation. Rather they are considered >part of a microcode assist for MVS. I don't pretend to know what is considered to be a System/3x0 instruction given that the descriptions are scattered among so many manuals besides the Principles of Operation. But the MVS assists are described in GA22-7079 System/370 Assists for MVS SA22-7092 Assists for MVS/XA A bigger concern is the new architectural category added by ESA/390 oxymoronically defined as "architected but not described". Expanded storage and Move Page, which pre-date ESA/390, already fall into that category. ESA/390 adds to it things like ETR (Sysplex) and ICF (Cryptographic Facility) which in practical terms means such things will be confined to use by MVS alone. Brian Eliot Information Technology Services Rensselaer Polytechnic Institute
BRUCE@UMDD.BITNET (Bruce Crabill) (03/18/91)
>Really? Ever heard of the MVS assists "OBTAIN LOCAL LOCK", "ADD FRR", >etc.? These are (microcoded) instructions which are sensitive to the >format of MVS control blocks. Look in the MVS Data Areas manual (or >whatever it's called for your release of MVS.) In some control blocks >like the ASCB, there are fields marked "this offset fixed by >architecture". What could that possibly mean except that there are >machine instructions that manipulate those control blocks? Leonard, I think you are splitting hairs here, that kind of assist "instruction" is really just a subroutine of the operating system that IBM has decided to make faster by implementing in microcode. They know a lot about the operating system in question and as you noted, they can modify control blocks of that operating system. However, to call them "instructions" seems to be going a bit far. At least in the VM world, the ECPS microcode assists are just subroutines from CP that have been placed in microcode for speed. In CP, generally this "instruction" is at the entry point of a subroutine and if active and capable of handling the request, does all the processing including the return to caller. If the assist isn't available on the processor, CP NOPs these "instructions" and control is passed to the actual subroutine that immediately follows the assist "instruction". IUCV is implemented using funky op-codes too, originally this just caused an illegal instruction trap, but now on some processors there exists microcode assists for IUCV too. Bruce
tabu6@CCVAX.IASTATE.EDU (Adam Goldberg) (03/18/91)
It seems that we're trying to say some opcodes, say LA is a machine instruction, while other more complicated and implemented in microcode instructions are not 'instructions'. Where would you draw the line? Clearly L, LA, STH etc are instructions. But what about MVC? MVCL? PACK? Then there is at least one (don't have the opcode handy) instruction that used to be about a 4K block of MVS code that IBM (in their infinite wisdom) decided to implement in microcode for speed. Even if opcode WXYZ does about 10,000 different things, if it's an opcode, it's an opcode--therefore a 3x0 instrucion. On the other hand, if it's a macro that makes a SVC (or equivalent), it's an operating system function. It seems that that is the line that has to be drawn. And by the way, someone asked a little while back if anyone could provide a list of SVC's and what they do. My response would be that there are a number of IBM-defined SVC's, and there are also installation-dependent SVCs that are configured by the site--for example, RACF vs ACF/2... +----------------------------------------------------------------------------+ + Adam Goldberg Bitnet: tabu6@ISUVAX.BITNET + + Iowa State University Internet: tabu6@CCVAX.IASTATE.EDU + + H: (515) 233-5135 + "It's simple! Even a Pascal programmer could do it!" + +----------------------------------------------------------------------------+
BRUCE@UMDD.BITNET (Bruce Crabill) (03/18/91)
I would call an instruction something that was architected and well defined.
These assist microcoded subroutines change as the function in the operating
system that it is trying to implement in microcode changes with new releases.
That is why you have various EC levels of these assists. CP will check the
EC level of the assists installed and if not at the right level, will
disable the assists. I think this is the major difference, an "instruction"
is something that the manufacturer has defined to work according to the
Principles of Operations and does not change, whereas a microcode assist
can change at the manufacturer's whim and is not generally documented. Yes,
there are publically available books that tell you what they do, but they
do not define in Principles of Operations detail exactly what they do.
Brucerickert@CS.NIU.EDU (Neil Rickert) (03/18/91)
In article <9103180137.AA13890@ucbvax.Berkeley.EDU> you write: >It seems that we're trying to say some opcodes, say LA is a machine >instruction, while other more complicated and implemented in microcode >instructions are not 'instructions'. Where would you draw the line? Clearly If you can execute that opcode on any machine in the same class, independent of the operating system, and it always performs the useful defined effect, it is an instruction. If the opcode is designed to perform a special purpose procedure for a specific software environment, and makes no sense outside that environment, it is a microcode assist. The term 'same class' above is deliberately vague. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
LDW@USCMVSA.BITNET (Leonard D Woren) (03/18/91)
> Leonard, I think you are splitting hairs here, that kind of assist > "instruction" is really just a subroutine of the operating system that IBM > has decided to make faster by implementing in microcode. They know a lot > about the operating system in question and as you noted, they can modify > control blocks of that operating system. However, to call them "instructions" > seems to be going a bit far. Ok, now that we have nitpicked the terminology to death, let's think about what started this -- a request for a new instruction which would switch two pages in the page tables. Since this can clearly be done as an MVS service via an SVC, it can also be done as an assist instruction. One big problem that I have with exotic instructions is that they aren't on all 370s/390s/whatever. I have yet to find a machine that has MVCIN. Has anybody worked on a machine that had the math assists (SQRT and trig functions)? I'm still reluctant to write code using BAS and BASR, since they don't exist on non-XA machines. Suppose I use an MVCIN instruction? Either: (1) You can only run it on a machine that has MVCIN, if you can find one, or (2) I have to write dual path code so that it works on a machine without MVCIN. At which point I won't bother to write the code in the first place which uses MVCIN. Be careful what you ask for. You may get it. (However, asking for an instruction to be added to the standard instruction set and therefore always installed on all models is not likely to happen.) /Leonard
LDW@USCMVSA.BITNET (Leonard D Woren) (03/18/91)
Oh yeah. One more thing. > "instruction" is really just a subroutine of the operating system that IBM > has decided to make faster by implementing in microcode. Let's see now. UPT and CFC are subroutines of SORT, not of the O.S. And they are now documented in the POP, which according to someone's recent definition makes them part of the architecture and real INSTRUCTIONS. /Leonard
BRUCE@UMDD.BITNET (Bruce Crabill) (03/18/91)
>Let's see now. UPT and CFC are subroutines of SORT, not of the O.S. >And they are now documented in the POP, which according to someone's >recent definition makes them part of the architecture and real >INSTRUCTIONS. As much as I would like to say that they are microcode assists (and really, they are), I would have to say that they are instructions for the reasons noted. The point is that once IBM as documented them in the POP, they can't turn around in 6 months and change them to work some other way. With the OS type microcode assists, they can. Nobody says an instruction has to execute in a small number of micro instructions. Look at the VAX POP and their QUEUE and CRC instructions. But I suspect that UPT and CFC are exceptions, rather than the rule (probably ones that were forced on IBM because of legal reasons). But I will agree with you that asking for changes to an existing POP isn't likely to go far. As an RPQ type deal maybe. Bruce
seb1525@mvs.draper.COM ("Stephen E. Bacher") (03/18/91)
Let's get away from philosophical arguments on what consistutes an "instruction" and go back to the request that started this discussion. Somebody wanted to submit a requirement to IBM to make a particular function available at the machine level. Whether this is implemented in hardware, as microcode, or as an assist seems less important than making the interface publicized and externalized so that assembler programmers can safely use it without being restricted as to the model of the machine they are on. That is how the requirement should be stated. If implementing it as an OS assist, for example, would be unaccceptably slow, the requirement should say something like "with the expected performance improvement that is normally associated with System/3x0 machine-instruction-level operations". As long as IBM publishes the description of the "instruction" in POP, and doesn't restrict it to obscure models (like MVCIN), this should satisfy the requirement. - SEB
news@ucf1vm.BITNET (03/22/91)
(You know, this is all getting a liitle out of hand)
The original Posting I wrote was for comments on a proposed 370 instruction,
MVDL, or move and discard character long.
The "discard" had to to with the data, not the area;
there is no implicit FREEMAIN (this is an instruction, NOT an OS service).
The instruction was meant to be coded as a direct replacement for MVCL,
in those situations where the source area need not be assumed
to hold valid data, after it was moved to the target area.
Inititial implementation would simply treat MVDL
as an MVCL. The situation of improvement would be that, to minimize
page swapping and contention (which can occur and really wipe out performance
when you are dealing with 20MB blocks in 200MB regions),
the instruction could be extended to tie into the page tables;
if the new area and the old area both be on page boundaries,
and the length to be moved be integral pages,
then instead of ||:swap-in-the-old/swap-in-the-new/copy/repeat:||,
the page table could be marked up to have the user's target area page
references now point to the original (physical) source area.
Thus no physical swapping or copying of data would be required;
although page table manipulation is (perhaps) expensive, swapping contention
can be disastrously slow and ridiculously expen$ive.
(Perhaps "4-page" or "8-page" boundaries and lengths make more sense,
given the way auxiliary storage works. Fine. Then treat MVDL as MVCL
unless THOSE condition is met. The point is, the application code
remains unchanged, and the operating system figures out the most
efficient way to handle a specific invocation of the instruction.)
This idea was discussed (at SHARE) with a fair number of IBMers,
with MVS, VM, and AIX experience. All agreed that such a feature
would be useful, and could potentially lead to orders-of-magnitude
improvement in performance of a fair number of existing applications.
Noone suggested the MovePage; it is still not clear to me that it
would accomplish the desired result
(MovePage would also require a lot of recoding). All agreed that such a
feature would be useful.
I do appreciate the comments made, and anticpate more.
Thanks,
Dave
Dave Weintraub (dave@visual1.jhuapl.edu or dave@aplvm.bitnet)dave@visual1.jhuapl.edu (Dave Weintraub) (03/22/91)
(You know, this is all getting a liitle out of hand) The original Posting I wrote was for comments on a proposed 370 instruction, MVDL, or move and discard character long. The "discard" had to to with the data, not the area; there is no implicit FREEMAIN (this is an instruction, NOT an OS service). The instruction was meant to be coded as a direct replacement for MVCL, in those situations where the source area need not be assumed to hold valid data, after it was moved to the target area. Inititial implementation would simply treat MVDL as an MVCL. The situation of improvement would be that, to minimize page swapping and contention (which can occur and really wipe out performance when you are dealing with 20MB blocks in 200MB regions), the instruction could be extended to tie into the page tables; if the new area and the old area both be on page boundaries, and the length to be moved be integral pages, then instead of ||:swap-in-the-old/swap-in-the-new/copy/repeat:||, the page table could be marked up to have the user's target area page references now point to the original (physical) source area. Thus no physical swapping or copying of data would be required; although page table manipulation is (perhaps) expensive, swapping contention can be disastrously slow and ridiculously expen$ive. (Perhaps "4-page" or "8-page" boundaries and lengths make more sense, given the way auxiliary storage works. Fine. Then treat MVDL as MVCL unless THOSE condition is met. The point is, the application code remains unchanged, and the operating system figures out the most efficient way to handle a specific invocation of the instruction.) This idea was discussed (at SHARE) with a fair number of IBMers, with MVS, VM, and AIX experience. All agreed that such a feature would be useful, and could potentially lead to orders-of-magnitude improvement in performance of a fair number of existing applications. Noone suggested the MovePage; it is still not clear to me that it would accomplish the desired result (MovePage would also require a lot of recoding). All agreed that such a feature would be useful. I do appreciate the comments made, and anticpate more. Thanks, Dave Dave Weintraub (dave@visual1.jhuapl.edu or dave@aplvm.bitnet)