COBOL version was 6.3 using ARCH(13) OPT(2) -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of John Melcher Sent: Tuesday, October 20, 2020 12:09 To: [email protected] Subject: Re: Conditional MVCL macro?
JES2 has had a $MVCL macro since SP2.2.0. What version of COBOL, I wonder? -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Charles Mills Sent: Tuesday, October 20, 2020 12:05 PM To: [email protected] Subject: Re: Conditional MVCL macro? *** External email: Verify sender before opening attachments or links *** Note that in neither case does it use MVCL or MVCLE! The 4097 boundary may simply be a reasonableness thing, not a performance thing. For a 150K move, 600-or-so MVC's in-line might be faster than a loop, but does it really seem reasonable? Slightly OT to 'move' but I find it interesting that in the second case it uses LA Rx,256(,Rx) to increment the registers. I was told that AHI is sometimes faster. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Mike Hochee Sent: Tuesday, October 20, 2020 9:40 AM To: [email protected] Subject: Re: Conditional MVCL macro? Really interesting thread to start the day with! Our experience has been that the MVC loops are typically faster, up to a point, that being about 30-40 instructions in the pipeline and as mentioned, and this seemed very processor dependent. However when source and target operands happen to both be aligned on a page boundary, then the opportunity exists for the async data mover to kick in if a move long is being used. I think this applied to both MVCL and MVCLE, but not sure. So ideally a macro would want to utilize both MVCs and MVCL/E. More grist for the mill! -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, October 20, 2020 12:12 PM To: [email protected] Subject: Re: Conditional MVCL macro? Caution! This message was sent from outside your organization. The COBOL compiler for a 4000 byte move, from to the same with OPT(2) generates LAY R10,5072(,R9) FROM LA R7,1072(,R9) TO MVC 0(256,R7),0(R10) MVC 256(256,R7),256(R10) MVC 512(256,R7),512(R10) MVC 768(256,R7),768(R10) MVC 1024(256,R7),1024(R10) MVC 1280(256,R7),1280(R10) MVC 1536(256,R7),1536(R10) MVC 1792(256,R7),1792(R10) MVC 2048(256,R7),2048(R10) MVC 2304(256,R7),2304(R10) MVC 2560(256,R7),2560(R10) MVC 2816(256,R7),2816(R10) MVC 3072(256,R7),3072(R10) MVC 3328(256,R7),3328(R10) MVC 3584(256,R7),3584(R10) MVC 3840(160,R7),3840(R10) However for 5000 bytes it generates: LAY R7,6072(,R9) LA R10,0(,R7) LA R7,1072(,R9) LHI R11,0x13 EQU * MVC 0(256,R7),0(R10) LA R10,256(,R10) LA R7,256(,R7) BRCT R11,L0128 MVC 0(136,R7),0(R10) And yes the change occurred at 4097 bytes.
