MVCL question



High Level Assembler(HLASM) for MVS & VM & VSE

MVCL question

Postby BillyBoyo » Mon Mar 14, 2011 10:17 pm

This is question is prompted by reading an old (last October) post from steve-myers. He had been researching the actual operation of a packed -0 (minus zero).

This lead to me googling for a POP manual. On the way (I never actually got to the packed instructions) I looked at my old friend MVCL.

Now, a common Cobol Caution (sorry to mention that name in here :-) ) that we used to get was "An MVCL has been generated for an item in the File or Linkage Section. The move will not be performed if it overlaps destructively".

Now, in the POP I looked at, it seems to say that MVCL cannot overlap at all. It says that the "initialisation" that you can do using MVC (set the first byte to the character to initialise to, then do the MVC offset by one byte, and as if by magic the whole field is set to the same amount) cannot be done with MVCL. Now in Cobol (sorry again) I used to do this all the time to initialise arrays without have to do the looping. And I'm sure that most of the tables I did it with were longer than 256 bytes. I'm sure it did the initialisation, as no abends. I'm sure (fairly, anyway) that the compiler didn't "spot" what I was doing and put a load of MVC's together to do it. I did this lots and lots.

So, has something changed? Or is the POP not quite clear? Does Cobol (maybe the wrong place to ask :-) ) still give the same Caution?
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: MVCL question

 

Re: MVCL question

Postby steve-myers » Mon Mar 14, 2011 11:14 pm

Billyboyo is correct. MVCL cannot do something like -
         MVI   AREA,C' '
         MVC   AREA+1(L'AREA-1),AREA

However, it can do -
         LA    14,AREA
         LA    15,L'AREA
         L     1,=AL1(C' ',0,0,0)
         MVCL  14,0

Since the source length in register 1 is 0, you don't have to set register 0 because it will never be used. What we're doing is using the ability of MVCL to insert a "fill" character if the target length is greater than the source length.

One might think the MVC would be slow, but the microcode understands this very common "trick" and optimizes it.

You will see something like this in my code quite often -
         LA    5,LENGTH
         GETMAIN R,LV=(5)
         LR    4,1
         SR    15,15
         MVCL  4,14
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: MVCL question

Postby BillyBoyo » Mon Mar 14, 2011 11:45 pm

And I assume this is not in any way a "recent" innovation. Having received confirmation that the POP is correct :-), I am sore confused about what I used to do.

To make a simple example:


  01  SOME-ARRAY.
        03  SOME-ARRAY-ENTRIES OCCURS 100.
              05  SOME-ARRAY-CODE PIC XX.
              05  SOME-ARRAY-COUNT COMP-3 PIC S9(7).
  01 FILLER REDEFINES SOME-ARRAY.
      03  SOME-ARRAY-LENGTH-OF-ONE-ITEM PIC X(6).
      03  SOME-ARRAY-ITEMS-TO-INITIALISE PIC X(594).

MOVE SPACE TO SOME-ARRAY-CODE (1).
MOVE ZERO TO SOME-ARRAY-COUNT (1).
MOVE SOME-ARRAY TO SOME-ARRAY-ITEMS-TO-INITIALISE.



I tried this after an Assembler guy explained to me about the MVC method to set something to a repeating value. He was only talking about a simple repeating value, as in Steve's example, but, I thought, why not try it with something more complex?

It works (worked). But now, I have no idea how. It is definitely not using the "fill" character. It is longer than 256 bytes. I used it on arrays much more complicated that this one and never had a problem.

And I'm also not sure about the "destructive" overlap in the Caution I got from Cobol. Previously, I thought this to mean that the address being moved to was above the start of the address being moved from and overlapped (so that bytes which have previously been moved from the sourece would be changed). That sounded "destructive" to me. But now I am at a loss :-)
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: MVCL question

Postby dick scherrer » Tue Mar 15, 2011 3:17 am

Hello,

It works (worked). But now, I have no idea how.
Once upon a time multiple MVCs were generated (at least as i recall :roll: ). But this was more than 30 years ago. . . On a much older compiler. . .
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: MVCL question

Postby BillyBoyo » Tue Mar 15, 2011 5:05 am

Thanks. I've been thinking since the post, and I came to that conclusion as well. I guess it still works, due to "backwards compatability" if nothing else. It's just funny that I always assumed it was an MVCL, being "misguided" as well by the MVCL caution and never having checked what was generated by the compiler. Everywhere I used it I explained "exactly" what was happening, and I was wrong (I got the effect right, but the wrong instruction - never as stupid as when I'm being clever :-) ).

The Caution is correct. It won't do the move if it overlaps. We lost a file header that way once, but that is another story.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: MVCL question

Postby steve-myers » Tue Mar 15, 2011 11:10 am

I no longer have an early System/370 Principles of Operation, but I suspect MVCL hasn't changed; it will reject a destructive move and set condition code 3 even in 1971.

I looked up MVCL in a fairly current z/Architecture Principles of Operation. It really is kind of ridiculous. I think it extends over 4 or 5 pages. I lost the page count while cursing PDF (it just does not work well when there are 2 columns on a page) and paging down through the description.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: MVCL question

Postby dick scherrer » Tue Mar 15, 2011 11:58 pm

Hello,

but I suspect MVCL hasn't changed; it will reject a destructive move and set condition code 3 even in 1971.
If the older compilers used a series of MVCs, how/why does this apply . . . :?
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: MVCL question

Postby BillyBoyo » Wed Mar 16, 2011 6:44 am

I think it was just a confirmation that it couldn't be MVCL that was generated, since it is unlikely to have changed "recently".

A POP I found by google, does explain the "destructive overlap" for me. Can't say as I actually understand it. Or, more accurately, I don't exactly understand what a "non-destructive overlap" is. The POP describes it negatively, at several levels. It would seem that the only overlap (for this usage of MVCL) is something like the leftmost byte of each operand can coincide and then it is non-destructive.

Also, how would you use this: the MVLC can "wrap around" from maximum storage address through 0 to whatever in low storage address?

So there is a non-destructive overlap, I'm just unsure as to how it would be used, or what it really consists of, to be honest.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: MVCL question

Postby steve-myers » Thu Mar 17, 2011 10:25 am

The issue of address wraparound with MVCL has always been more theoretical than real.

In practice, it was not possible with non-virtual memory System/370 machines. None of them had anything close to 16 meg real storage, so any attempt to invoke address wraparound with MVCL on those machines would most likely terminate with the long forgotten S0C5 ABEND.

I don't recall for sure, but I believe even OS/VS2 Rel 1 defined virtual storage up to 16 meg, so, at least in theory, you could do address wraparound with that system.

I think early MVS systems defined storage the same way.

The virtual storage restructure with MVS/XA had the nucleus straddling the 16 meg virtual storage line. I think the same storage map is still in use with z/OS, so you should be able to do MVCL wrap around in the 24-bit address mode in both MVS/XA and later MVS releases, as well as z/OS.
IEAV9CM2   FFFFB0     50   24   ANY  R/O  IEAVCMS2   FFFFC8     18
                                          IEAVCMS1   FFFFCC     1C
                                          IEAVCMR3   FFFFD0     20
                                          IEAVCMR1   FFFFD4     24
                                          IEAVCMR4   FFFFD8     28
                                          IEAVCMR2   FFFFDC     2C
                                          IEAVCMST   FFFFE0     30
                                          IEAVCMSB   FFFFE4     34
IECVXURS  1000000     F0   31    31  R/O
Part of a nucleus map of a z/OS nucleus

I don't know if MVS/XA defined virtual storage up to 2 gig, so it may not be possible to do address wraparound in the 31-bit addressing mode in MVS/XA and later MVS systems, or with z/OS.

Similarly, I don't know if z/OS defines virtual storage up to the end og 64-bit virtual memory, so I don't know if address wrap around is possible in 64-bit addressing mode.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: MVCL question

Postby steve-myers » Sat Mar 19, 2011 6:10 am

I wrote up a small program to try MVCL wrapping in the 24-bit addressing mode. The program did an MVCL 4,2. I printed before and after images of the registers, and got -

R2 = 00FFFF80 R3 = 00000100 R4 = 0002AC30 R5 = 00000100
R2 = 00000080 R3 = 00000000 R4 = 0002AD30 R5 = 00000000

What I find interesting is reg 2 didn't just keep bumping; I would have expected 01000080.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Next

Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post