Hi Gil,
There is no need, when disassembling code, for z/XDC's JZ/JE choice
to be perfect.
It just looks at the immediately prior few instructions and makes a
decision base on what it sees.
It the specific case of AL/SL, yeah it's kinda a toss-up. I chose to
consider them to be arithmetic, so z/XDC would show JZ, etc.
As regard to "multiple code paths" and "cc value", keep in mind that
the code being disassembled is not necessarily what is currently
being executed. So in the general case, neither issue is relevant.
Bottom line, if z/XDC makes the wrong BZ/BE choice, it's not a
particularly important error. But it is right more often than not.
Dave
At 5/10/2022 02:29 PM, Paul Gilmartin wrote:
On May 10, 2022, at 11:58:40, David Cole wrote:
>
> At 5/8/2022 07:14 AM, Jonathan Scott wrote:
>> >LFI for IILF, LLGFI for LLILF
>> >SLLHH, SLLHL, SLLLH, SRLHH, SRLHL, SRLLH
>> >
>> >As they are all extended mnemonics, they are not normally used
>> >by debugging tools. They are not used by the HLASM disassembler.
>> >
What product normally uses them?
> When disassembling a BRC 8,--- for example,
> z/XDC will actually go to the trouble
> to show either JE or JZ
> depending upon what the prior instruction is.
>
How does it decode a BC after AL/SL?
What if there are multiple code paths to the BC?
(I had one co-worker perverse enough to rely on the
CC after a subroutine return. He reset the program
Mask before the BR 14 and I had to support it on a
370.)
--
gil
