"(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 <[email protected]> wrote:
Subject: Re: EQU * considered harmful
To: [email protected]
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:[email protected]]
On Behalf Of Keith Moe
Sent: Wednesday,
August 1, 2018 1:27 PM
To: [email protected]
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 <[email protected]>
wrote:
Subject: Re: EQU *
considered harmful
To: [email protected]
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
