COBOL “01” level definitions (and “77” level as well) in WORKING-STORAGE and
LOCAL-STORAGE are doubleword-aligned. This was the case even before Enterprise
COBOL. I don’t remember at this point whether ANS COBOL V4 introduced that
alignment or if even the old MVT COBOL’s (E and F) aligned as well.
Peter
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Schmitt, Michael
Sent: Friday, November 1, 2024 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bounded string move?
No cases of loops of more than one MVC. And to answer someone else's post: both
work areas were aligned (they were COBOL "01" levels). I think they're fullword
aligned. If anyone wants to try this test, my complete program is:
---------------------
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
No cases of loops of more than one MVC.
And to answer someone else's post: both work areas were aligned (they were
COBOL "01" levels). I think they're fullword aligned.
If anyone wants to try this test, my complete program is:
---------------------
identification division.
program-id. 'cobtest'.
data division.
working-storage section.
01 in-w pic x(5000).
01 out-w pic x(5000).
procedure division.
call 'get' using in-w.
display 'before'.
move in-w to out-w.
display 'after'.
call 'put' using in-w
out-w.
goback.
end program cobtest.
---------------------
The displays were just so it was easier to see the start and end of the MOVE
code in the PMAP.
The reason for the two CALLS was to ensure that the optimizer had no idea what
was in IN-W before the move, would not know what OUT-W is used for, and
wouldn't try and use the same area for both.
This program wouldn't link, because 'get' and 'put' don't actually exist. I
just wanted the compile listing.
I changed the size of the PIC clauses for each test.
Also, I said "What does IBM think is the fasted move for various lengths?".
That's not exactly right. The compiler /could/ have generated even more MVCs,
but there's a trade-off at some point of code size vs. performance. So the
actual question is "What does IBM think is the OPTIMUM move for various
lengths? *".
I should also have said that I'm compiling with:
MAXPCF(100000)
RENT
NOSSRANGE
NOTEST(NODWARF,NOSOURCE,NOSEPARATE)
And it is amode 31
* for this particular program
-----Original Message-----
From: IBM Mainframe Discussion List
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Kirk
Wolf
Sent: Friday, November 1, 2024 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: Bounded string move?
That's Interesting Michael.
Did you see any cases where the Cobol compiler generated unrolled loops of MVCs
(like 4 each iteration)? I've seen that in cases with C/C++, but I don't
remember the conditions. It's really wild how they do it as I recall. It
may have to do with the settings of the compiler optimization options (size vs
speed related).
Kirk Wolf
Dovetailed Technologies
https://urldefense.com/v3/__https://coztoolkit.com/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGgQs7o2KI_yTA6EooYy_T_MNuKcqLbWJOxuJZHn-7XKegeOlJ2sR64lE5qVhT7EhAkqxrtUYmwaLi-ly5HhfPhBjYXeM7g$<https://urldefense.com/v3/__https:/coztoolkit.com/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGgQs7o2KI_yTA6EooYy_T_MNuKcqLbWJOxuJZHn-7XKegeOlJ2sR64lE5qVhT7EhAkqxrtUYmwaLi-ly5HhfPhBjYXeM7g$>
On Thu, Oct 31, 2024, at 4:54 PM, Schmitt, Michael wrote:
> That made me wonder: What does IBM think is the fasted move for various
> lengths?
>
> Testing with IBM Enterprise COBOL for z/OS 6.2, compiled at OPT(2),ARCH(12)
> on a z/14, moving from a fixed length field to a field of the same length and
> can't be optimized away...
>
> - 1 to 4,096 bytes: generates a series of MVCs
> - 4,097 to 77,824 bytes: generates an MVC loop, followed by one more if
> needed
> - 77,825 and up: generates an MVCL
>
> 77,824 is an odd number to break on. It is 19 * 4096.
>
>
> If you're interested, the MVC loop for a length of 77,824 is:
>
> 000013 LA R2,152(,R9) # IN-W
> 000013 LA R1,0(,R4) # OUT-W
> 000013 LHI R0,0x12f
> 000013 NOP
> 000013 L0052: EQU *
> 000013 MVC 0(256,R1),0(R2) #
> 000013 LA R2,256(,R2) #
> 000013 LA R1,256(,R1) #
> 000013 BRCT R0,L0052
> 000013 MVC 0(256,R1),0(R2) #
>
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List
> <IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of
> Steve Thompson
> Sent: Thursday, October 31, 2024 4:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: Re: Bounded string move?
>
> Uh, isn't that true up to about 1024 bytes (MVCs stacked)? And
> then after the MVCL seems to be faster.
>
> I think I was at some disclosure meeting or SHARE when that was
> said prior to 2010 (can't remember the exact year).
>
> I Remember that the MVCL is interruptible at end of a unit of
> operation.
>
> This may have changed since the z/13s.
>
> Steve Thompson
>
> On 10/31/2024 4:18 PM, Charles Mills wrote:
> > @Kirk: +1
> >
> > @Shmuel: you know that an MVC loop is dramatically faster than MVCL?
> >
> > Surprising but true.
> >
> > CM
> >
> > On Wed, 30 Oct 2024 22:40:52 +0000, Seymour J Metz
> > <sme...@gmu.edu<mailto:sme...@gmu.edu>> wrote:
> >
> >> I'm leaning towards SRST/MVCL.
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGgQs7o2KI_yTA6EooYy_T_MNuKcqLbWJOxuJZHn-7XKegeOlJ2sR64lE5qVhT7EhAkqxrtUYmwaLi-ly5HhfPhB3p_7Uus$<https://urldefense.com/v3/__http:/mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGgQs7o2KI_yTA6EooYy_T_MNuKcqLbWJOxuJZHn-7XKegeOlJ2sR64lE5qVhT7EhAkqxrtUYmwaLi-ly5HhfPhB3p_7Uus$>
> >> עַם יִשְׂרָאֵל חַי
> >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> >>
> >>
> >>
> >> ________________________________________
> >> From: IBM Mainframe Discussion List
> >> <IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of
> >> Kirk Wolf <k...@coztoolkit.com<mailto:k...@coztoolkit.com>>
> >> Sent: Wednesday, October 30, 2024 4:41 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> >> Subject: Re: Bounded string move?
> >>
> >> Caution: This email did not originate from George Mason’s mail system. Do
> >> not click links or open attachments unless you recognize the sender and
> >> know the content is safe.
> >>
> >>
> >> It appears to me that your requirement matches the C function below. (?)
> >> I would probably just use C/C++, but you can see what the IBM C/C++
> >> optimizing compiler generated. It seems unlikely to me that there is a
> >> significantly better way. You might ask on mvs-asm370.
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu>
> > with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with
> the message: INFO IBM-MAIN
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with
> the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with
the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with
the message: INFO IBM-MAIN
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
