New z16 Instructions

[Ed Jaffe]

We just applied this APAR to our systems:

https://www.ibm.com/support/pages/apar/PH39324

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Paul Gilmartin]

On Apr 16, 2022, at 14:22:59, Ed Jaffe <edj...@phoenixsoftware.com> wrote:
>
> We just applied this APAR to our systems:
>
> https://www.ibm.com/support/pages/apar/PH39324
>

... which links to a "Fix Readme" with recommendations
for dealing with possible clashes between 30 new
instruction mnemonics and customer-defined macro names.

One suggested remedy is:
If the macro names cannot be easily changed, then
the programs can use the ":MAC" suffix to ensure that
the macro is used rather than the instruction.

Would defensive programming recommend that all macro
invocations use the ":MAC" suffix lest a name become
an instruction mnemonic in the z17?

An alternative not mentioned might be if references
are numerous to COPY the affected macro definitions
into source programs.

--
gil

[Gibney, Dave]

It seems problematic to do a STBEAR, but I can see the utility of LBEAR. Assuming the BEAR is the one I am thinking of.

RDP probably not the Remote Desktop Protocol...

> -----Original Message-----
> From: IBM Mainframe Assembler List <ASSEMBLER-
> LI...@LISTSERV.UGA.EDU> On Behalf Of Ed Jaffe
> Sent: Saturday, April 16, 2022 1:23 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: New z16 Instructions
>
> [EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognize
> the sender and know the content is safe.

>
> We just applied this APAR to our systems:
>

> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/P
> H39324__;!!JmPEgBY0HMszNaDT!rPDjomswWP2y5mkawNAu53gfZXJG95AsC
> Wb0yhSE1fFkkKvRgXw7BtYZiPf-oYBleeEIU7yU0xD0sEkSrS7qQw$

>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245

> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> EgBY0HMszNaDT!rPDjomswWP2y5mkawNAu53gfZXJG95AsCWb0yhSE1fFkkK
> vRgXw7BtYZiPf-oYBleeEIU7yU0xD0sEn7Lc_7ZA$

[Steve Smith]

Another alternative is to OPSYN delete the new instructions that conflict.
I think that will work: I rtfm, but not tested.

Personally, I think adding :MAC would just be more work. You might as well
rename the macro.

While I really find gratuitous usage of national character prefixes to be
ugly, it does tend to future-proof macros named with such, as I think we
can assume IBM won't ever invent an instruction mnemonic that starts with
one.

Anyway, nothing here looks nearly as bad as the infamous introduction of
the MSG operation.

sas

[Paul Gilmartin]

On Apr 16, 2022, at 17:32:03, Steve Smith wrote:
>
> Another alternative is to OPSYN delete the new instructions that conflict.
> I think that will work: I rtfm, but not tested.
>

A group I worked with did that and also used OPTABLE, partly to ensure
That our code worked with downlevel customer hardware.

> Personally, I think adding :MAC would just be more work. You might as well
> rename the macro.
>

Adding ":MAC" could be done with an Edit macro: one CHANGE command
for each of the announced new instructions; manual tweaks for
such as column 72 overflow. Or, FLOWASM its your friend. That
leaves the option of using the new instructions in the future.

> While I really find gratuitous usage of national character prefixes to be
> ugly, it does tend to future-proof macros named with such, as I think we
> can assume IBM won't ever invent an instruction mnemonic that starts with
> one.
>

Do any mnemonics use numeric digits? Is it IBM's intention never
to use digits in mnemonics? (But at one time IBM seemed committed
never to use mnemonics longer than four letters.)

> Anyway, nothing here looks nearly as bad as the infamous introduction of
> the MSG operation.
>

I don't know that one. Did IBM step on its own toes?

--
gil

[Martin Trübner]

Dave,


what would LBEAR do other than a LG Rn,X'110' ?


and what is STBEAR good for? to falsify the original?


I wait for the POP to describe them in more detail


Martin

Am 16.04.22 um 23:47 schrieb Gibney, Dave:

[ess...@juno.com]

.
If the POP manual is not available, where can one find the new instructions ?

[Steve Smith]

--->

On Sat, Apr 16, 2022 at 8:33 PM Paul Gilmartin <
00000014e0e4a59...@listserv.uga.edu> wrote:

> On Apr 16, 2022, at 17:32:03, Steve Smith wrote:

> ...

> Do any mnemonics use numeric digits? Is it IBM's intention never
> to use digits in mnemonics? (But at one time IBM seemed committed
> never to use mnemonics longer than four letters.)
>

SAM31 & its friends are all that come to mind.

>
> > Anyway, nothing here looks nearly as bad as the infamous introduction of
> > the MSG operation.
> >
> I don't know that one. Did IBM step on its own toes?
>

I'd say it stepped on a lot of toes with that one, but not necessarily its
own. It's one of 11 varieties of MULTIPLY SINGLE (13 inc. immediate forms).

>
> --
> gil
>

sas

[Gibney, Dave]

I guess it's possibly some other BEAR. I agree that until we have a POP, I am just WAGing

> -----Original Message-----
> From: IBM Mainframe Assembler List <ASSEMBLER-

> LI...@LISTSERV.UGA.EDU> On Behalf Of Martin Trübner
> Sent: Sunday, April 17, 2022 1:12 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: the BEAR (was: New z16 Instructions)
>

[Seymour J Metz]

Presumable LBEAR would load the actual breaking-event-address register, not set the PSA field.

How would STBEAR falsify the original? Were you thinking of LBEAR?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Martin Trübner [mar...@PI-SYSPROG.DE]
Sent: Sunday, April 17, 2022 4:12 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: the BEAR (was: New z16 Instructions)

[Gibney, Dave]

You are correct, I reversed L and ST in my thought

> -----Original Message-----
> From: IBM Mainframe Assembler List <ASSEMBLER-

> LI...@LISTSERV.UGA.EDU> On Behalf Of Seymour J Metz
> Sent: Sunday, April 17, 2022 1:48 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: the BEAR (was: New z16 Instructions)
>
> Presumable LBEAR would load the actual breaking-event-address register,
> not set the PSA field.
>
> How would STBEAR falsify the original? Were you thinking of LBEAR?
>
>
> --
> Shmuel (Seymour J.) Metz

> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!r7dai4jAuwG_m8yJhCQL7ijFUUMQ2TaWGy8lb-
> 5dXT5MQ5RwlutyjtWtRqv6myI15Y8QQhWaYjk7LQ$
>
> ________________________________________
> From: IBM Mainframe Assembler List [ASSEMBLER-
> LI...@LISTSERV.UGA.EDU] on behalf of Martin Trübner [martin@PI-

[Ed Jaffe]

On 4/17/2022 1:12 AM, Martin Trübner wrote:
> what would LBEAR do other than a LG Rn,X'110' ?

Martin, X'110' is not the BEAR. The BEAR is a special register that
holds the last Breaking Event Address (BEA). X'110' is simply the place
where the BEAR is automatically stored when an interrupt occurs.

My assumption is that STBEAR stores the BEAR into into virtual storage
so the last BEA can be inspected *without* forcing an interrupt.

Presumably LBEAR is a way of loading the BEAR without requiring a
breaking event to do so.

I can envision the usefulness of this for functions that interrupt
normal instruction flow (e.g., an interrupt) and wish to restore things
back the way they were (including the pre-interrupt BEAR) to maintain
transparency.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245

https://www.phoenixsoftware.com/

[Martin Trübner]

Ed,


after I wrote back to Dave- just what you said occurred to me too. In
some cases It might be nice to find out "how was I called" or from where
(and thus reading the bear and not location 110).


And maybe the two (LBEAR and STBEAR) are just two flavors of the very
same- one against memory and the other against a register.


But the final truth will be in the book.


Martin

[Peter Relson]

Both LBEAR and STBEAR are created for OS's other than z/OS.

Could z/OS use them constructively? Possibly. If by "constructive" we positively balance functional benefit over performance cost.

Could an application use STBEAR constructively? Possibly. Probably more likely to be of constructive use if the OS itself uses LBEAR and STBEAR.

Peter Relson
z/OS Core Technology Design

[Martin Trübner]

Peter,


I still have no exact idea what both instructions do (waiting for the
book of books) , but your stmt

>>  Both LBEAR and STBEAR are created for OS's other than z/OS

let me hope that both where for ALSO not for the little stepbrother z/VSE.


And now I can even visualise "constructive" use for my (wrong) idea of
addressing the location (and not the hardware as Ed pointed out).


Martin


Am 27.04.22 um 01:51 schrieb Peter Relson:

[Martin Trübner]

Now that POPS-13 is out:


I see and understand LBEAR and STBEAR.


But I wounder why RP did not get a non-bear destruction brother of RPY
like LPSWE did with LPSWEY.



Martin

[Martin Trübner]

HLASM APAR PH39324 mentions new op-codes


but


neither POP nor shortref have some of them. The missing mnemonics are

LFI
LLGFI
SLLHH
SLLHL
SLLLH
SRLHH
SRLHL
SRLLH

While I can fantasize about what they do, I have no idea of the real
op-code.


Can someone (with the PTF applied) please compile code that reveals the
op-code?


It is all that is needed for my free of charge debugger for HLASM on
zVSE or nVSE.

As long as they are no instructions that change the flow of execution.


Martin

[Jonathan Scott]

> HLASM APAR PH39324 mentions new op-codes ...

The following mnemonics are new extended mnemonics for existing
instructions and are listed in the new very helpful Appendix J
of z/Architecture Principles of Operation.

1. Alternative mnemonics for existing instructions which fit
into more than one naming pattern:

LFI for IILF, LLGFI for LLILF

2. Shifts involving high word, mapped to RISBHGZ and RISBLGZ:

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.

Jonathan Scott, HLASM
IBM Hursley, UK

[Martin Trübner]

Jonathan, thank you!

Am 08.05.22 um 13:14 schrieb Jonathan Scott:

[David Cole]

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.
> >
> >Jonathan Scott, HLASM
> >IBM Hursley, UK

<brag on>
Except for z/XDC...
z/XDC understands extended mnemonics,
uses them in disassembly displays,
and lets you make mnemonic zaps with 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.
</brag on>



David Cole
President
ColeSoft

dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)

[Paul Gilmartin]

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

[Gary Weinhold]

I think VM/370 (CP or CMS, perhaps both) used to rely on the CC after a
calls to internal routines.

As a debugger, since it's tracing the instructions, I wouldn't be
surprised if it knew exactly which instruction set the CC.

On 2022-05-10 2:29 p.m., Paul Gilmartin wrote (snipped):
> 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.)
>

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: wein...@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.

[Paul Gilmartin]

On May 10, 2022, at 13:06:21, Gary Weinhold wrote:
>
> I think VM/370 (CP or CMS, perhaps both) used to rely on the CC after a
> calls to internal routines.
>
> As a debugger, since it's tracing the instructions, I wouldn't be
> surprised if it knew exactly which instruction set the CC.
>

I agree; that works ini a dynamic trace or single-step. For a
Static disassembly, it's safest just to show a numeric CC mask.

> On 2022-05-10 2:29 p.m., Paul Gilmartin wrote (snipped):
>> 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

[David Cole]

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

[Jonathan Scott]

The new extended mnemonics for existing instructions are
just to make it easier for programmers, as usual, once
they can rely on having the appropriate level of HLASM.

I have been asked more than once why there isn't an LFI
instruction and had to point users to IILF which does exactly
what LFI would be expected to do, so I suggested the alternative
mnemonic to the architects myself. They agreed with the
suggestion, and suggested similarly LLGFI for LLILF, and also
called to my attention the extended shifts which had previously
been requested but not implemented.

[Schmitt, Michael]

There's a LFI mnemonic? Where is this documented?

The HLASM Language Reference just says that extended mnemonics for non-branch instructions are documented in PoP. But I'm not finding it in PoP either.

And if it was in PoP, where would it be documented? In the IILF topic?

The problem I have is that there are so many instructions now it is difficult to know all of them, especially when some have unexpected uses. Like in this case: I know I want to load a fullword immediate. So I look at the Chapter 7 General Instructions > Instructions topics for something that matches. All I see is LOAD IMMEDIATE (LGFI) and LOAD LOGICAL IMMEDIATE (LLIHF/LLIHH/LLIHL), which all look to be affecting 64-bits.

I wouldn't think to look at INSERT IMMEDIATE because I'm not thinking I'm inserting.

(And it doesn't help that the instruction topics are not in alphabetical order, with LOAD IMMEDIATE way at the TOP of the list!)

Is there a presentation or document somewhere on How to do Simple Things With Unexpected Instruction Use? Like how those ROTATE THEN instructions really aren't just for when you want to *rotate* a register.

[David Cole]

Michael,

There now in PoOps-13) an Appendix J where all expented mnemonics
have been gathered together into one place.

Dave