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"
<cblaic...@syncsort.com> 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!
