Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!UCSD.EDU!usc!rpi!eliot
From: usc!rpi!eliot@UCSD.EDU (Brian Eliot)
Newsgroups: comp.lang.asm370
Subject: Re: New System/3x0 Instruction
Message-ID: <9103150308.AA00939@ucbvax.Berkeley.EDU>
Date: 13 Mar 91 16:09:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: IBM 370 Assembly Programming Discussion List
              <ASM370@OHSTVMA.BITNET>
Distribution: inet
Organization: The Internet
Lines: 24

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