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 EXR0=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" To: 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, October 26, 2020 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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 On Behalf Of Christopher Y. Blaicher Sent: Monday, October 26, 2020 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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.
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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, October 26, 2020 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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 On Behalf Of Christopher Y. Blaicher Sent: Monday, October 26, 2020 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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.
Re: Is TESTCB a bad boy ?
A performance hit is only a factor if this will run many times an hour in an application. However as a possible future example of how to code a TESTCB that might end up in a heavily used subroutine, I believe the standard form of TESTCB should never be used without lots of warnings if anyone else will ever see it. TESTCB has list, execute, and generate forms; they generate reentrant code. On 2020-10-26 2:07 p.m., Christopher Y. Blaicher wrote: 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 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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.
Re: Is TESTCB a bad boy ?
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 On Behalf Of Christopher Y. Blaicher Sent: Monday, October 26, 2020 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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.
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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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.
Selective upper casing of assembler source code
Also, long ago and far away, I wrote a Rexx program to read the assembler source file, perform selective upper casing and write a new file. Comments (both free standing and line end) were left as is; labels, operation codes and most operands were upper cased. My Rexx code did its best to parse the source lines, recognizing quoted strings, continuation lines and so on. I also recognized "special" free standing begin/end comments to tell the Rexx code to simply leave the intervening lines alone. The code certainly wasn't perfect, but it worked well for my style of coding. I chose Rexx because it was easy to "port" to VM/CMS, MVS and the PC. Having a separate program did away with editor dependencies, as well as specific assembler dependencies (such as exits). Yes, it was an extra step in my overall development process and it added a little bit of overhead, but for me this was an acceptable solution. Bob
Re: Is TESTCB a bad boy ?
Any store of any sort into the instruction sequence will be bad. The cache does not know an IBM macro from a newbie's code. You want to post the actual code? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 8:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Is TESTCB a bad boy ? 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.
Re: Is TESTCB a bad boy ?
This is what we used to call a Pipe Cleaner in the old days. It caused the CPU pipe to be flushed. One used to do this to get ready for an interlocking instruction, to make sure that everything in the pipe ahead of this instruction was committed. In certain cases, we followed the instruction that needed this with a Pipe Cleaner as well. I have not read the PoOP at this level for years so I don't even know if that instruction still clears the pipe or not. Or if Out of Order instruction operations would go nutz with it. Regards, Steve Thompson --- 072265160664-dmarc-requ...@listserv.uga.edu wrote: From: Melvyn Maltz <072265160664-dmarc-requ...@listserv.uga.edu> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Is TESTCB a bad boy ? Date: Mon, 26 Oct 2020 11:15:44 -0400 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.
Is TESTCB a bad boy ?
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.
