Wendell wrote:
> From Tony's explanation concerning moving the TR command to the data area
via LOCTR, can I surmise that it might be counter-productive to do so--that
leaving the TR and EX commands in consecutive memory is more efficient?
My $0.02 is that I'm not so sure about the "do it once
] on behalf
of Keith Moe [ke...@sbcglobal.net]
Sent: Thursday, November 11, 2021 4:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
Actually the inline TR/EX will do the TR the first time for ONE byte, not 256,
followed by the EX of the specified length
, November 10, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I'm reluctant to admit this, but I'm still unclear about SIIS is
] on behalf
of Tony Harminc [t...@harminc.com]
Sent: Wednesday, November 10, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I
Lovewell [09624390d784-dmarc-requ...@listserv.uga.edu]
Sent: Thursday, November 11, 2021 12:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
Adam & Tony--thanks for the good explanations.
>From Tony's explanation concerning moving the TR
Adam & Tony--thanks for the good explanations.
From Tony's explanation concerning moving the TR command to the data area via
LOCTR, can I surmise that it might be counter-productive to do so--that leaving
the TR and EX commands in consecutive memory is more efficient?
> Example 2:
>
If size isn't a problem:
"skel64" is csect name:
* Round start of data to next 256-byte boundary to separate from ipipe
zArchorg skel64+(((*+256)-skel64)/256)*256
LTORG
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could
> someone please explain what happens to the D- and I-cache in these situations?
I can tell you my
For current processors, 256 bytes.
Some IBMers talking with us on these topics suggested a macro called
NEXTCLB,
which inserts some space depending on some address arithmetic.
IMO, if you use this, you could adjust it later if a future processor
requires more.
(256 is a constant used inside
How do you ensure that your storage areas are far enough away from the code to
not be in the instruction cache line, when your data isn't in GETMAIN storage?
You can mitigate by putting constants in between, but how do you know if that's
enough?
For the first 2 examples, those are not SIIS violations because no
modification of storage takes place. The modification of the instruction
happens in the core itself (I once heard it called the "instruction
register" where this happens... I can't verify the validity of that
statement).
In
I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could
someone please explain what happens to the D- and I-cache in these situations?
Example 1:
TxtTRNull TR0(*-*,R14),NoNulls
EX R5,*-6
Example 2:
PgmConst LOCTR ,
TxtTRNull TR
12 matches
Mail list logo
