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
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
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
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
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
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
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
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
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
