Re: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02, at 11:27:28, Charles Mills wrote: >> Can EX modify the CC mask in a target branch instruction? > > You bet! > Branch prediction is always ... well, like any other prediction. > It was mentioned in IBM-MAIN that BCT(R) is predicted to always branch; BC is predicted to never branch. I hope there's an exception for BC 15: EX targets, syscall arguments, etc. If so, I wondered if: BC cond,target Highly probable branch, but predicted not to branch Might be better optimized as: BC 15-cond,*+8 Probable not branch; correctly predicted BC 15,targetPredictably certain to branch. (JIT compilation is supposed to fix things like this.) -- gil
Re: Instruction/Data Cache Usage (was EQU *)
> Can EX modify the CC mask in a target branch instruction? You bet! Branch prediction is always ... well, like any other prediction. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, August 2, 2018 10:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instruction/Data Cache Usage (was EQU *) On 2018-08-02, at 08:22:52, Alan Atkinson wrote: > "Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache" > > Is that also now true for the target of an execute perchance? > Surely this is model-dependent. On S/360, I doubt it mattered. > We went through a whole exercise to get rid of all the > > EX *+8 > J *+?? > > A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) -- gil
Re: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02, at 08:22:52, Alan Atkinson wrote: > "Inline data is no more expensive than data in another page. In either case, > the reference to the data requires a cache line load to the D-cache, but does > not invalidate/disturb the I-cache" > > Is that also now true for the target of an execute perchance? > Surely this is model-dependent. On S/360, I doubt it mattered. > We went through a whole exercise to get rid of all the > > EX *+8 > J *+?? > > A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) -- gil
Re: Instruction/Data Cache Usage (was EQU *)
On 2018-08-02 10:22 AM, Alan Atkinson wrote (snipped): If it's not necessary we can go back to being able to see what you meant to do without scrolling. Could that be accomplished with a comment on the EX statement? Of course to prevent the comment from getting out of date, you'd have to use a hyperlink back to the actual target. And then you'd have to implement hyperllink resolution in the ISPF editor. 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.
Re: Instruction/Data Cache Usage (was EQU *)
"Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache" Is that also now true for the target of an execute perchance? We went through a whole exercise to get rid of all the EX *+8 J *+?? in the code a few years back in the name of efficiency We needed to do it after the way pipelining was handled changed between machines - it made a huge difference to performance inside a very very active chunk of code. It was enough to affect the entire machine throughput. If I was mildly less demented I'd recall the machine versions (I'm sorta thinking going from a Z9 to a Z11) but it was a few years back. If it's not necessary we can go back to being able to see what you meant to do without scrolling. I haven't looked at MF architecture in a couple of years so I'm a bit behind the times in this area.
Re: Instruction/Data Cache Usage (was EQU *)
The IBM z Systems Processor Optimization Primer v2 by C. K. Shum supports your assertion. One could argue that grouping all literals/constants so they are only in the D-cache and not in I-cache is a slightly more efficient use of total cache, assuming other literals/constants in that D-cache line will also be referenced. But it's probably a moving target; i believe I recall that I read/heard that the translation table referenced by TRT will be placed in I-cache. On 2018-08-01 9:17 PM, Christopher Y. Blaicher wrote (snipped): Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. 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.
Re: Instruction/Data Cache Usage (was EQU *)
Well, yes, as a matter of fact, I mentioned it in an e-mail to you and an associate of yours on December 13, 2016. I did not request nor did I expect some sort of "resolution" from IBM. I of course would never expect that my macro would automagically support some new MODESET feature. It is not named MODESET so the lack of the feature should not boggle my successor, whoever he or she may be. > Most developers choose not to spend their time looking for "what did my > predecessor do that works but could have been done better". Of course. Including me. As I said "I know it is nothing but it just annoyed me ..." The paragraph was about an oddity in me, not an oddity in z/OS. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Thursday, August 2, 2018 6:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Did you ever mention that to anyone who might have been able to address your disfavor? I suspect not. Having our own MODESET macro, you'd be unhappy if MODESET ever chose to use any of the first 16 bits of its flag word, if you ever wanted to use whatever new option did so. And of course the macro was written years (decades?) before LHI was available and, until there was no chance of someone using that macro to run on an older system, changing to LHI would have been unacceptably incompatible. Most developers choose not to spend their time looking for "what did my predecessor do that works but could have been done better". So if there's any chance of it getting changed, you'd have to bring it to our attention. Would it have been done? Who knows. Will it be done? Maybe. I can at least say that we no longer feel there to be any impediment to unconditionally using anything in base z/Architecture (and of course the relative/immediate instruction set pre-dates that). We will not typically use by default instructions that correspond to a release's architecture level set, because a product might compile with the "new release macros" but run on an older release. But if dual-pathing were deemed worthwhile, the macro could rely on the SYSSTATE ARCHLVL value set by a program. Peter Relson z/OS Core Technology Design
Re: Instruction/Data Cache Usage (was EQU *)
My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Did you ever mention that to anyone who might have been able to address your disfavor? I suspect not. Having our own MODESET macro, you'd be unhappy if MODESET ever chose to use any of the first 16 bits of its flag word, if you ever wanted to use whatever new option did so. And of course the macro was written years (decades?) before LHI was available and, until there was no chance of someone using that macro to run on an older system, changing to LHI would have been unacceptably incompatible. Most developers choose not to spend their time looking for "what did my predecessor do that works but could have been done better". So if there's any chance of it getting changed, you'd have to bring it to our attention. Would it have been done? Who knows. Will it be done? Maybe. I can at least say that we no longer feel there to be any impediment to unconditionally using anything in base z/Architecture (and of course the relative/immediate instruction set pre-dates that). We will not typically use by default instructions that correspond to a release's architecture level set, because a product might compile with the "new release macros" but run on an older release. But if dual-pathing were deemed worthwhile, the macro could rely on the SYSSTATE ARCHLVL value set by a program. Peter Relson z/OS Core Technology Design
Re: Instruction/Data Cache Usage (was EQU *)
On 2018-08-01, at 21:29:05, Keven wrote: > > Hmm,My last post wasn’t formatted correctly in my mail reader > so I’ll try it again. There should be three separated lines of text > following. The last line should be indented relative to the penultimate line. > PERTURBED_BY_THIS CLC THIS,THAT > PREFER DS 0H CLC THIS,THAT > Still No Good, despite teeming NBSP. Curse you, Outlook for Handhelds! (Might there be a native mail client for your handheld better than Outlook? Or would it be even worse?) > On Wed, Aug 1, 2018 at 10:18 PM -0500, "Keven" wrote: > > In general I think code labels should be associated with locations and not > specific instructions although it seems appropriate to label instructions > that are the target of Execute. > PERTURBED_BY_THIS CLC THIS,THAT > PREFER DS 0H CLC THIS,THAT -- gil
Re: Instruction/Data Cache Usage (was EQU *)
From: "Christopher Y. Blaicher" Sent: Thursday, August 02, 2018 11:17 AM Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. And with good reason. A labelled instruction usually means that it is the head of a loop or the object of a branch. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Instruction/Data Cache Usage (was EQU *)
Hmm,My last post wasn’t formatted correctly in my mail reader so I’ll try it again. There should be three separated lines of text following. The last line should be indented relative to the penultimate line. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT On Wed, Aug 1, 2018 at 10:18 PM -0500, "Keven" wrote: Chris, I share your dislike for labeled instructions, albeit with somewhat less passion in that my perturbation falls short of all-caps animus. In general I think code labels should be associated with locations and not specific instructions although it seems appropriate to label instructions that are the target of Execute. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT My tuppence-ha’penny worth Keven On Wed, Aug 1, 2018 at 8:33 PM -0500, "Christopher Y. Blaicher" wrote: Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: Instruction/Data Cache Usage (was EQU *)
Chris, I share your dislike for labeled instructions, albeit with somewhat less passion in that my perturbation falls short of all-caps animus. In general I think code labels should be associated with locations and not specific instructions although it seems appropriate to label instructions that are the target of Execute. PERTURBED_BY_THIS CLC THIS,THAT PREFER DS 0H CLC THIS,THAT My tuppence-ha’penny worth Keven On Wed, Aug 1, 2018 at 8:33 PM -0500, "Christopher Y. Blaicher" wrote: Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: Instruction/Data Cache Usage (was EQU *)
Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. My 2 cents. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, August 1, 2018 7:54 PM To: MVS List Server 2 Subject: Re: Instruction/Data Cache Usage (was EQU *) My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
Re: Instruction/Data Cache Usage (was EQU *)
I would suggest that the reason for the moving of "IBM's" data is because of the I-Bank D-Bank cache issue (I think it is actually a processor-pipeline stall -- but I have not done this level of work since 1990 -- Yes, long before the CMOS G3 chips were announce in 1997). What I have been doing to programs that do not have to be RENT but must become AMODE 31 is use the MF=L and MF=(E,???) formats where the List version of the macro is in "working storage" of the program (not GETMAINed, but right after the Register Save area). This allows short instruction lengths and the PLIST is in a data area that can't be part of any instruction cache lines. Regards, Steve Thompson On 08/01/2018 06:57 PM, Keith Moe wrote: "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned! Keith Moe BMC Software, Inc. On Wed, 8/1/18, Charles Mills wrote: Subject: Re: EQU * considered harmful To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Date: Wednesday, August 1, 2018, 1:41 PM "Avoid instructions (executable code) and operand data (working storage or stack storage) in the same cache lines; which can be costly due to moving cache lines between the separated (split) local caches (instruction/data L1/L2)" -- C. Kevin Shum, Distinguished Engineer, IBM z Systems Microprocessor Development (March 2016) Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 1:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EQU * considered harmful Inline data is only a killer if it is updated. It is merely less efficient if it is read only (same cache line in instruction and data caches). My example was merely to show that the "INSTRUCT" statement would force half word alignment. Aside from macros that expand inline CONSTANTS (not updatable areas), I generally avoid mixing instructions and data. Even in non-reentrant code (unfortunately there's a lot here that I have to maintain and it's not worth it to make it reentrant), I try to isolate code blocks and data blocks. Keith Moe BMC Software, Inc. On Wed, 8/1/18, Charles Mills wrote: Subject: Re: EQU * considered harmful To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Date: Wednesday, August 1, 2018, 1:05 PM Well, one could argue that "DS" implies a variable, not instructions, and is therefore inappropriate as something on which to hang an instruction label. I like the idea of some kind of "instruction" attribute for EQU, with an error if you branched to a non-instruction symbol. I think I might argue for an EQU operand rather than a new opcode, but that is a quibble. J NEXTL DC CL(oddnumber)' ' NEXTL INSTRUCT You know that data mixed with instructions is just a performance KILLER on modern CPUs? They have separate i- and data caches, and mingling the two makes a mess that must be straightened out, at a cost of CPU cycles. Charles
Re: Instruction/Data Cache Usage (was EQU *)
My favorite (not!) is MODESET which generates (IIRC) in-line data and a branch around it and a LOAD from storage. I know it is nothing but it just annoyed me so much that I created my own that uses LHI and no branch. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 3:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Instruction/Data Cache Usage (was EQU *) "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned!
