Can you share your $MVC macro?
Brian
On Tue, 20 Oct 2020 17:42:55 +, Christopher Y. Blaicher
wrote:
>We just got a z15 and I have not tested MVCL vs MVC loop, but on all prior
>machines a MVC loop beat a MVCL up to about 32K. Over 32K MVCL is the way to
>go. In our environment we
One of the questions that I always ask in response to concerns about whether
one instruction is better than another is, "Do you ever expect to recoup the
number of instructions needed to reassemble, rebind, and retest the code?"
Assuming that the answer is "Yes, this code is executed a
Likewise CLCL.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Charles Mills [charl...@mcn.org]
Sent: Tuesday, October 20, 2020 6:35 PM
To:
I'm pretty sure that testing for pending interrupts didn't slow down CLCL or
MVCL on the 370/165 or 370/168. But the microinstruction was 108 bits; longer
if you had an emulator feature.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From:
umm, another meme looking for idle minds to prosper in?
I use eyecatchers A LOT, and I want every instance of the string to be easily
find-able.
Cheers from Fort Lockdown,
The Masked Marauder
> On 21 Oct 2020, at 9:12 am, Keven wrote:
>
>
>
>
>
>For the 0.75 seconds it would take
So it was written, and it is so done.
sas
On Tue, Oct 20, 2020 at 6:35 PM Charles Mills wrote:
> Unless I am thinking fuzzily, an interrupted MVCL leaves the PSW pointing
> to
> the MVCL (not past it) and the relevant registers incremented and
> decremented appropriately, so the supervisor may
Interrupts can only be handled between instructions (don't ask me how
pipelining figures) except, MVCL has the potential to delay that too
long, so it (and a handful of others) were made to be interruptible.
Probably, that just means the micro/milli-code program gets interrupted
between
Unless I am thinking fuzzily, an interrupted MVCL leaves the PSW pointing to
the MVCL (not past it) and the relevant registers incremented and
decremented appropriately, so the supervisor may dispatch other tasks on the
affected CPU, let them run as they will, and then resume the interrupted
task
A simpler solution would be
MVC Real_Eyecatcher(8),=C'MY BLOCK-not really, just the literal'
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Keven
Sent: Tuesday, October 20, 2020 3:12 PM
To:
I’d say you were both correct.
Keven
On Tue, Oct 20, 2020 at 5:01 PM -0500, "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
On 2020-10-20, at 14:58:52, Steve Smith wrote:
>
> There's actually a big
For the 0.75 seconds it would take to differentiate an eye catching
string in program storage from an instance of it in in use to nominate a
control block, I have to wonder if this is a solution looking for a problem to
solve.
Keven
On 2020-10-20, at 14:58:52, Steve Smith wrote:
>
> There's actually a big difference between MVCL being interruptible, and
> MVCLE stopping periodically before it's finished. The latter is not
> interruptible, it just stops before completion periodically for the program
> to do something else if
It's not complicated if you know how to manipulate strings in Conditional
Assembly. There's no much way around the fact it's vanity programming
though.
Besides, the technique is defeated by palindromes :-).
sas
On Tue, Oct 20, 2020 at 4:16 PM Tom Harper
wrote:
> I already have such a macro.
The first, base code, is just the following to get the overhead of loop control;
TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM
LOOPBDS0H
L R3,POOLADDRGET FROM ADDRESS
L
There's actually a big difference between MVCL being interruptible, and
MVCLE stopping periodically before it's finished. The latter is not
interruptible, it just stops before completion periodically for the program
to do something else if it wants to. Checking a flag is a possibility, but
to
Thanks for sharing your test results, although I had trouble explaining the
results of the first two tests, and maybe this is related to how the $MVC macro
does its thing.
Anyway, If you throw out the first two tests, the $MVC technique appears to be
250-300% more efficient than the MVCL
I already have such a macro. I’ll post it later.
Sent from my iPhone
> On Oct 20, 2020, at 4:06 PM, Tony Thigpen wrote:
>
> While we are talking about macros, a while back, someone posted they liked to
> fill eye-catchers using MVCIN so that scans of the dump for a tag only found
> the real
While we are talking about macros, a while back, someone posted they
liked to fill eye-catchers using MVCIN so that scans of the dump for a
tag only found the real eye-catcher, not the literal used to fill the
eye-catcher.
So, instead of:
MVC EYE1,=C'(BTABLE>'
use:
MVCIN
There may be a hint to the reason for the jump in the explanation of MVCLE,
programming note 3.
"The function of not processing more than approximately 4K bytes of either
operand is intended to permit software polling of a flag that may be set by a
program on another CPU during long
I just re-ran a test on our z15 machine and got interesting numbers. The $MVC
was reasonably linear from start to finish. The MVCL has a big jump from 2K to
4K, but was also reasonably linear outside of that jump. It never caught up to
the $MVC implementation.
TEST TYPE = BASE CODE
Right.
I should have said "an interruptibility that is visible to the surrounding
assembler instructions via the CC."
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Tuesday, October 20, 2020 10:52
COBOL version was 6.3 using ARCH(13) OPT(2)
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of John Melcher
Sent: Tuesday, October 20, 2020 12:09
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Conditional MVCL macro?
JES2 has had a $MVCL macro since SP2.2.0.
What
> What version of COBOL, I wonder?
Presumably 6.
COBOL 4 does not have OPT(2) and COBOL 5 was mostly a non-starter.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of John Melcher
Sent: Tuesday, October 20, 2020 10:09
MVCL is, and always has been, interruptible.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Charles Mills [charl...@mcn.org]
Sent: Tuesday, October 20, 2020
We just got a z15 and I have not tested MVCL vs MVC loop, but on all prior
machines a MVC loop beat a MVCL up to about 32K. Over 32K MVCL is the way to
go. In our environment we rarely are moving more than 32K. We built a $MVC
macro with 3 parameters, destination, source and length and use
Our testing on a Z14 (MVS under VM), MVCL was considerably slower than a
256-byte MVC loop plus an executed MVC for various unaligned data
lengths from 40 bytes to 32K.
For zeroing memory up to 1G, XC in a loop was about the same as MVCL up
to 256 bytes, then MVCL was faster (MVCLE was slightly
On 10/20/2020 8:54 AM, Charles Mills wrote:
@Ed, can you elaborate a little on your reasoning? (Not doubting it; just
curious.) Is it that the interruptibility provides a significant improvement
over MVCL? Or the support for lengths greater than 16M? Or ... ?
MVCL with anything other than zero
JES2 has had a $MVCL macro since SP2.2.0.
What version of COBOL, I wonder?
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Charles Mills
Sent: Tuesday, October 20, 2020 12:05 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Conditional MVCL macro?
*** External
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
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
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
I don't know how today's machines (z13 and up) perform, but back when I had
access to Strobe it regularly pointed out long MVCL / CLCL instructions
generated by COBOL 4.2 (in the specific application case I was working on these
were usually around 8K bytes) as relatively large "hot spots" of
@Ed, can you elaborate a little on your reasoning? (Not doubting it; just
curious.) Is it that the interruptibility provides a significant improvement
over MVCL? Or the support for lengths greater than 16M? Or ... ?
When I asked Dr. Shum about move strategies he seemed to indicate that for
data
We've switched almost exclusively to MVCLE except for short,
fixed-length moves.
On 10/20/2020 5:42 AM, Tony Thigpen wrote:
I have several programs that work with buffers and moving random
length data around using MVCLs. I am considering writing a
'conditional MVCL' macro that, at runtime,
Extract from a larger macro. And no, I was not overly concerned with
performance.
.* r15 : length
.* r14 -> source
.* r0 -> target
.* r1 used when short
>
> What is the effect of the conditional branch and the EX on the pipeline? Are
> the performance tradeoffs the same on all supported processors? Also, tuning
> code for a current processor may slow it down on a new one.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
In
What is the effect of the conditional branch and the EX on the pipeline? Are
the performance tradeoffs the same on all supported processors? Also, tuning
code for a current processor may slow it down on a new one.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
I have several programs that work with buffers and moving random length
data around using MVCLs. I am considering writing a 'conditional MVCL'
macro that, at runtime, looks at the lengths and either executes the
MVCL or bypasses it and uses a MVC via EX.
I know this would generate a longer
38 matches
Mail list logo
