> Why do you use LM and STM to load the fields in to registers
> and then out to memory again, rather than just using MVC for
> a “memory to memory” move? ...
> [eg] MVC ARG1(ARG1_L),CONSTS

MVC will work.  And all else being equal, fewer instructions usually are
better.
But!  In performance discussions on LinkeIn's "Mainframe Assembler
Professionals" group, like this one:
http://www.linkedin.com/groups/1462937/1462937-91082881 ...
... I've learned that LOAD/STORE sequences (IC/STC, L/ST, LM/STM) are much
faster than an equivalent length MVC.  See comments in the above discussion
such as:
"CLC (like MVC) is very fast - but only after a start-up penalty. In the
MVC case using two LG/STG is much faster than a 16 byte MVC..."
and
"There is a good reason why small MVCs run slower than LG/STG pairs. There
is a bunch of overhead at the beginning of a MVC. Just one example: you
have to check if the operands are on "good" boundaries. If not, you tiptoe
your way to a good boundary. Then you can rip. Have to check for operand
overlap conditions. There is a length check involved. During this time the
LG/STG is far on its way. Some IBM machines (if I remember correctly) also
had a bigger fetch/store path for MVC. Again, once it got going. I can
assure you that a LG/STG pair is faster than a 16 byte MVC. Anyone writing
a length-1 MVC instead of an IC/STC would be laughed out of their code
review. Length-16 as well.  - R.Timothy Tomaselli"

And indeed, as we learn later on in that same discussion, LOAD/STORE
sequences (rather than MVC) are *exactly* what the MVS PL/I, C/370 and
COBOL 5.x compilers generate for single byte fields and fields up to 16
bytes long and divisible by 4.

Reply via email to