To Charles...
EX 0, on a dynamically constructed TM...the hard way doing whatever...
had to be done
I don't want to get off topic, but TESTCB is the worst IBM macro I have ever
seen
Syntax checking...none, documentation...awful and misdescribed in the VSAM
Macro manual...I won't go on
And using an index register instead of a base register is frowned upon
(440D0014)
I doubt if it matters now, but you are right, back in 360/370 days the use
of index carried a 50uS overhead
I well remember obsessively recoding LA R5,1(R5) as LA R5,1(,R5) back in the
days
Melvyn Maltz.
----- Original Message -----
From: "Charles Mills" <[email protected]>
To: <[email protected]>
Sent: Tuesday, October 27, 2020 8:22 PM
Subject: Re: Is TESTCB a bad boy ?
Interesting code.
I suspect that others are correct: the EX target is far enough away as to
not adversely affect the pipeline.
Two other comments though: EX 0, on a dynamically constructed TM seems like
the hard way of doing whatever it was that had to be done. I would have to
understand all the code to be sure, but that sure seems like doing things
the hard way.
And using an index register instead of a base register is frowned upon
(440D0014). Not sure if it is still true today, but once upon a time at
least the use of an index register slowed things down by a cycle.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of MELVYN MALTZ
Sent: Monday, October 26, 2020 7:22 PM
To: [email protected]
Subject: Re: Is TESTCB a bad boy ?
Thanks for all the responses, very useful
Perhaps I'd better state what environment I'm working in
I'm using the MVS 3.8 version of VSAM macros which are in the Public Domain
IDA019C1 is the xCB processor and I have the source code from that era
All of this has been adapted in z390 so that I have a emulated IBM VSAM
environment as far as xCB operations go
To respond to most of you
To Charles...
Rather than send you the unfathomable code from IDA019C1 here is an extract
from a z390 trace which shows a typical situation, code followed by source
800FDCCA 0 9291D014 MVI S2(000FF98C)=96 I2=91='j'
IDA019C1 00105A MVI TSTOP(REG13),X'91'
800FDCCE 0 440D0014 EX R0=800FD42E S2(000FF98C)=91804001
IDA019C1 00105E EX REG0,BITSTINS(REG13)
To Gary...
TESTCB has list, execute, and generate forms; they generate reentrant
code
Mostly they don't, some like MF=G have the potential but as always it's up
to the skill of the programmer to ensure re-entrancy
To Christopher...
As you can see from the above code the instruction doing the mod is about 7K
from the instruction being modified, so only that cache would be refreshed,
a minor overhead provided is wasn't being done a lot
I'm still a little concerned that TESTCB might be used internally by COBOL
etc and be taking a performance hit unknown to the users
Melvyn Maltz.
----- Original Message -----
From: "Christopher Y. Blaicher" <[email protected]>
To: <[email protected]>
Sent: Monday, October 26, 2020 7:21 PM
Subject: Re: Is TESTCB a bad boy ?
A cache line is 256 bytes. If the code that modifies an instruction is in
the same cache line as the instruction, then multiple cache line refreshes
have to happen.
The cache line for the modified instruction has to be brought into the
data cache and modified. This causes the cache line in the instruction
cache to be invalidated. The cache line then has to be refreshed into the
instruction cache and then the next instruction re-fetched. Doing an EX
causes no cache line refreshes and does not interfere with the pipeline.
As I said, EX has its own set of overheads, but are a very small fraction
of modifying an instruction.
Chris Blaicher
Technical Architect
Precisely.com
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:[email protected]] On Behalf Of Farley, Peter x23353
Sent: Monday, October 26, 2020 2:33 PM
To: [email protected]
Subject: Re: Is TESTCB a bad boy ?
This message originated Externally. Use proper judgement and caution with
attachments, links, or responses.
Isn't that true only if the dynamically built instruction isn't in the
same cache line as the code that performs the build and EX?
I've seen examples where the "built" instruction was a non-reentrant
location in the same CSECT and very near to the "build" instructions. Not
my code, but I have seen it.
Peter
-----Original Message-----
From: IBM Mainframe Assembler List <[email protected]> On
Behalf Of Christopher Y. Blaicher
Sent: Monday, October 26, 2020 2:07 PM
To: [email protected]
Subject: Re: Is TESTCB a bad boy ?
This will not have the same performance hit.
The problem with the MVI was the CPU had to 1) bring the cache line into
the data cache; 2) apply the MVI data; 3) refresh the cache line in the
instruction cache; and finally 4) execute the instruction.
Doing an EX skips steps 1, 2 and 3. EX has its own set of overheads, but
nowhere near what all the cache hits have.
Chris Blaicher
Technical Architect
Precisely.com
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:[email protected]] On Behalf Of Melvyn Maltz
Sent: Monday, October 26, 2020 11:16 AM
To: [email protected]
Subject: Is TESTCB a bad boy ?
This message originated Externally. Use proper judgement and caution with
attachments, links, or responses.
In ancient times it was common practice to do this sort of thing...
SWITCH NOP GO
MVI SWITCH+1,X'F0'
I believe this clears the cache and causes severe performance hits
In my research into TESTCB for the z390 Project I found that it
dynamically builds the subject instruction for an EX
Would this have the same performance hit ?
Melvyn Maltz.
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.
