[comp.lang.asm370] New System/3x0 Instruction

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.

                                       Bruce

rickert@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)