Never mind, I realize I misunderstood the question.  Apologies.

Sent from my iPad

> On Dec 14, 2015, at 10:49 AM, Gerhard Adam <[email protected]> wrote:
> 
> MVC does not modify registers, so there is no way to get data into or out of 
> registers.
> 
> Sent from my iPad
> 
> On Dec 14, 2015, at 10:42 AM, "David S." <[email protected]> wrote:
> 
>>> 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