HLASM support for z13

[Richard Cebula1]

Following on from the recent announcement of the new IBM z13, HLASM has
been updated to support the new instructions. HLASM APAR PM79901
introduces over 660 new mnemonics and extended mnemonics to support the
new instructions. The new instructions are available in both the new ZS7
OPTABLE as well as the UNI OPTABLE. Full details on how to code the new
instructions will be available in the zArchitecture Principles Of
Operation guide.

There are however a number of new zArchitecture vector instructions using
the same mnemonics as old ESA/390 vector instruction mnemonics. These old
ESA/390 vector instruction mnemonics have therefore been removed from the
UNI OPTABLE, but are still available in the ESA OPTABLE. It is important
that if you have ESA/390 vector instruction mnemonics in your code that
after applying APAR PM79901 you use the ESA OPTABLE when assembling code
containing the ESA/390 vector instruction mnemonics.

Whenever new instructions become available in hardware and extra mnemonics
and extended mnemonics are added to HLASM, there is always a potential for
a clash between the new mnemonics / extended mnemonics and existing user
macros with the same name. To assist in identifying any such macros, we
have released a technote which details how SuperC (ISRSUPC) can be used to
assist in finding such clashes in your source and macro libraries. The
technote also gives guidance on how such clashes may be resolved.

For further details please see:
http://www.ibm.com/support/docview.wss?uid=swg21693594
http://www.ibm.com/support/docview.wss?uid=isg1PM79901
http://www.ibm.com/support/docview.wss?uid=swg21694301

Richard Cebula
IBM HLASM
HLASM is The IBM z Systems Assembler




Phone: 44-(0)1962 818113
Mobile: 44-(0)7895989126
E-mail: ric...@uk.ibm.com
HLASM: www.ibm.com/software/awdtools/hlasm/

RTC - Enhancing the HLASM Development Environment RFE – Enhancing HLASM
capabilities RCF – Enhancing HLASM documentation
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Tony Thigpen]

None of the links work for me.

Tony Thigpen

[Ray Mansell]

I've had variable success. Richard tells me the pages were posted
yesterday, but I suspect the servers may still be 'spreading the word'
amongst themselves, so to speak. I've managed to reach each of the pages
at least once, although it has always been a very slow experience.

Ray

[Blaicher, Christopher Y.]

Is there a new POP available? I can't find it so far.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803    
E: cbla...@syncsort.com

[John McKown]

Doesn't look like it to me. I went to the z13 library page on ResourceLink
and there isn't anything there. There is a "Technical Guide" Redbook at
http://www.redbooks.ibm.com/redpieces/pdfs/sg248251.pdf

--
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity. In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

[Paul Raulerson]

Hi Richard - 

None of the included links worked for me. Can you post a different link to reach them? 

Thanks 
-Paul 

[Farley, Peter x23353]

Richard,

Thanks for the links, but the third one always seems to result in "Our apologies… The page you requested cannot be displayed" from ibm.com (tested on both IE9 and Firefox 35.0). Is there another way to get to that technote?

Peter

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Tom Marchant]

On Fri, 16 Jan 2015 15:32:20 +0000, Blaicher, Christopher Y. <cbla...@SYNCSORT.COM> wrote:

>Is there a new POP available? I can't find it so far.

Neither can I. The page at http://www.vm.ibm.com/devpages/jelliott/cmosproc.html
has been updated, but the POO and the reference summary aren't on it yet.

IIRC, the POO usually becomes available at about GA, not announcement time.

--
Tom Marchant

[Mar...@pi-sysprog.de]

Tom,

thank you for that page- I am enrolled

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[John Ehrman]

A new Principles of Operations should be available at GA.
John Ehrman

[Richard Cebula]

The links provided are the correct ones - I too was having unreliable connections to the pages but it seems to be fine today.
As Ray said, it seems as if some of the webservers providing the pages were still catching up.

[Farley, Peter x23353]

The first two links seem to work today, but the third one still got not found in IE9, even with several separate tries and multiple refresh attempts. Firefox was able to retrieve it first time around, but only the first text attachment on the page will open or download (SMORSA.DUP.INSTRUC.txt).

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Richard Cebula

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Farley, Peter x23353]

Follow up: A further final try with IE9 actually got the third link to work, and I was able to get to all three attached texts. Patience required, I guess, to deal with the uncertainties of web servers.

[Mar...@pi-sysprog.de]

I did some counting on the lists in the third of the links

439 ops starting with V

29 ops starting with W

14 starting with CAD (looks like just one with different codnitions)

without grouping CDPT
without grouping CPDT
without grouping CPXT
without grouping CXPT
without grouping LCBB
without grouping LLZRGF

106 starting with LOC (permutations of conditions + adressing +
G,F,H)

2 with LZ (LZRF LZRG)

31 starting with STOC (complements to the LOC?)

I do not expect it to be too hard to get the hang of the new
instructions for those already fluent in Pops.

[Robert Ngan]

Some(?) of the LOC/STOC extended mnemonics are probably just the missing
conditions I noticed in the original implementation of these extended
mnemonics. Only the COMPARE conditions were originally implemented, the
ARITHMETIC and TEST UNDER MASK conditions were missing and I opened a RFE
for this.

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
2015/01/20 02:01:15:

> From: Mar...@PI-SYSPROG.DE
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 2015/01/20 01:56
> Subject: Re: HLASM support for z13

[Mar...@pi-sysprog.de]

so we are down to 22 new instructions

[Tom Marchant]

On Tue, 20 Jan 2015 21:52:28 +0100, wrote:

>so we are down to 22 new instructions
>

How did you arrive at that conclusion? I'll wait for GA so I can see the POO.

--
Tom Marchant

[David Cole]

Correct me if I'm wrong (John Ehrman),
but I thought that IBM once upon a time,
way back when they started to create mnemonics longer than 5 characters...

I thought they said
their new limit was going to be seven characters.
Well... "VSTRCZFS".

[sigh]



Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com

Home page: www.colesoft.com
User's Group: www.xdc.com (on LinkedIn)
Facebook: www.facebook.com/colesoftware
Videos: www.youtube.com/user/colesoftware

[Paul Gilmartin]

On 2015-01-21, at 08:37, David Cole wrote:

> Correct me if I'm wrong (John Ehrman),
> but I thought that IBM once upon a time,
> way back when they started to create mnemonics longer than 5 characters...
>
> I thought they said
> their new limit was going to be seven characters.
> Well... "VSTRCZFS".
>
> [sigh]
>

How many collisions are there between z13 mnemonics and z/OS
library macro names and HLASM instructions.

I think it was said here that if hardware design tried to name
instructions such as POP, PUSH, WAIT, POST, ... HLASM would
prevail with possible intercession of Marketing. But are
new mnemonics vetted against all member names in all maclibs
of all IBM products? (Do significant ISVs count?)

Has Colesoft been using VSTRCZFS?

If seven characters is enough for TSO user IDs, it ought to be
enough for instruction mnemonics.

What about 9? Would that require a redesign of HLASM? UNIX
file names can easily be 9 and more, but BPAM wouldn't support
them.

-- gil

[David Cole]

>Has Colesoft been using VSTRCZFS?

No, I noticed it while developing SIMD support. In my disassembly
displays, the 8th character was being truncated.

It's no big deal really, I just need to change an EQU and reassemble.
But it does make me wonder if they might eventually go to 9 or longer...

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902

EADDRESS: dbc...@colesoft.com

Home page: www.colesoft.com
User's Group: www.xdc.com (on LinkedIn)
Facebook: www.facebook.com/colesoftware
Videos: www.youtube.com/user/colesoftware

[John McKown]

On Wed, Jan 21, 2015 at 9:37 AM, David Cole <dbc...@colesoft.com> wrote:

> Correct me if I'm wrong (John Ehrman),
> but I thought that IBM once upon a time,
> way back when they started to create mnemonics longer than 5 characters...
>
> I thought they said
> their new limit was going to be seven characters.
> Well... "VSTRCZFS".
>

​Ah! the old "if you like your 8 character macro name, you can keep your 8
character macro name" trick, eh? (Texan disguising himself as a Canadian).​

>
> [sigh]
>
>
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com
>
> Home page: www.colesoft.com
> User's Group: www.xdc.com (on LinkedIn)
> Facebook: www.facebook.com/colesoftware
> Videos: www.youtube.com/user/colesoftware

[John Ehrman]

Dave Cole noted...

>> Correct me if I'm wrong (John Ehrman),
but I thought that IBM once upon a time,
way back when they started to create mnemonics longer than 5 characters...

I thought they said
their new limit was going to be seven characters.
Well... "VSTRCZFS".
<<

I don't remember any such claim, but I agree that the potential for
collisions between mnemonics and macro names has increased. That's why
HLASM added the operation-code suffixes ("tags") :ASM and :MAC so you can
explicitly specify which mnemonic resolution you want.

John Ehrman

[John Ehrman]

Dave Cole noted again...

<<But it does make me wonder if they might eventually go to 9 or
longer...>>

I think HLASM has supported operation field entries longer than 8
characters for a long time, but resolution was possible only to source
macros. (No, I haven't tried it.)

John Ehrman

[John Ehrman]

Paul Gilmartin asked...

<<But are new mnemonics vetted against all member names in all maclibs of
all IBM products? (Do significant ISVs count?)>>

That was indeed done many moons ago, but the number of products with
"private" macro libraries grew far beyond the capabilities of the
"vetters" so it's not done any longer.

John Ehrman

[Paul Gilmartin]

Ain't progress wonderful?

-- gil

[Sharuff Morsa3]

>Ain't progress wonderful?

Anyone know how to stop it ? (progress that is)

I would not rule out > 8 character mnemonics nor > 8 character HLASM
assembler directives (not that I'm currently planning any).

Because of the very large number of mnemonics and extended mnemonics which
have been added, there are some ISPF SuperC commands to assist users in
searching their source, copybook and macro libraries to see if they may be
affected (http://www.ibm.com/support/docview.wss?uid=swg21694301).

The new instructions have highlighted a problem for which we have to
strike a balance. Several of the new instructions have the same mnemonics
but differing instruction formats. Who can successfully execute ESA/390
vector instructions ? But some users will have these mnemonics are coded
in their applications (anyone want to own up having some?).

Should we always (100%) maintain the ability for users programs to
assemble programs cleanly even though they would not execute successfully?
How much can a product change (or evolve) without users having to make
some or consider those changes ?

IBM z Systems have a very long history of minimising the affect of changes
on users - but products and their usage change over time. How customers
use our products changes over time. Is that progress ?

Sharuff

Sharuff Morsa IBM Hursley Labs


>
> Date: Wed, 21 Jan 2015 11:03:34 -0800
> From: John Ehrman <ehr...@US.IBM.COM>
> Subject: Re: 8 character mnemonics

>
> Paul Gilmartin asked...
> <<But are new mnemonics vetted against all member names in all maclibs
of
> all IBM products? (Do significant ISVs count?)>>
>
> That was indeed done many moons ago, but the number of products with
> "private" macro libraries grew far beyond the capabilities of the
> "vetters" so it's not done any longer.
>

> John Ehrman
>
> ------------------------------
>
> Date: Wed, 21 Jan 2015 15:18:27 -0700
> From: Paul Gilmartin <PaulGB...@AIM.COM>
> Subject: Re: 8 character mnemonics

> ------------------------------
>
> End of ASSEMBLER-LIST Digest - 20 Jan 2015 to 21 Jan 2015 (#2015-12)
> ********************************************************************

[Richard Cebula]

Having a quick scan of our SYS1.MACLIB - I've found only 2 clashes between the z/OS macros and the instructions mnemonics - CHI and DSG.

[Peter Relson]

>But are new mnemonics vetted against all member names in all maclibs
>of all IBM products? (Do significant ISVs count?)

ISVs (and IBM products) are informed ahead of the general public of the
new mnemonics; it is conceivable that a change/accommodation would be made
if there were a good business need. Likely? I don't know.

Peter Relson
z/OS Core Technology Design

[John McKown]

On Thu, Jan 22, 2015 at 4:28 AM, Sharuff Morsa3 <Sharuf...@uk.ibm.com>
wrote:

> >Ain't progress wonderful?
>
> Anyone know how to stop it ? (progress that is)
>
> I would not rule out > 8 character mnemonics nor > 8 character HLASM
> assembler directives (not that I'm currently planning any).
>
> Because of the very large number of mnemonics and extended mnemonics which
> have been added, there are some ISPF SuperC commands to assist users in
> searching their source, copybook and macro libraries to see if they may be
> affected (http://www.ibm.com/support/docview.wss?uid=swg21694301).
>
> The new instructions have highlighted a problem for which we have to
> strike a balance. Several of the new instructions have the same mnemonics
> but differing instruction formats. Who can successfully execute ESA/390
> vector instructions ? But some users will have these mnemonics are coded
> in their applications (anyone want to own up having some?).
>
> Should we always (100%) maintain the ability for users programs to
> assemble programs cleanly even though they would not execute successfully?
> How much can a product change (or evolve) without users having to make
> some or consider those changes ?
>
> IBM z Systems have a very long history of minimising the affect of changes
> on users - but products and their usage change over time. How customers
> use our products changes over time. Is that progress ?
>
> Sharuff
>
> Sharuff Morsa IBM Hursley Labs
>
>

​One thing that I can think of which _might_ be of some help would be to
have either another program, or a PARM= value for HLASM for a source
validation. That is, it would act like HLASM, but would flag all opcodes
which are HLASM machine opcodes and which _also_ exist as members in the
SYSLIB concatenation. I don't know if HLASM does this already, but it would
be nice if all machine instructions supported by HLASM, but _excluded_ by
using the OPTABLE/MACHINE compile parameter, were only searched for as
macros. ​Lastly, it might be nice to have a program which can
"pseudo-compile" a source program and not only flag machine instruction
opcodes which exist as members in the SYSLIB concatenation, but would also
create an IEBUPDTE control deck which puts a ":MAC" on the end of the
opcode. The user could then edit this and use it to more easily update
their source.

​Just some ideas.​

[Tony Thigpen]

I have used longer-than-8 macros for many years. Works great. I have one
source macro that I include at the top of the member that is just 8
characters long. Inside, it has many macro 'redefs' so that I can use a
long macro name in the code, but it gets converted to a shorter 8
character macro before going out to the library to get the macro.

A short example:

MACRO
&NAME PERFORM_ON &ADDR,&BAD_VALUE=
&NAME PERFORMO &ADDR,BAD_VALUE=&BAD_VALUE
MEND


Then, in my code, I use the longer PERFORM_ON.

Some of my macro names are quite long, like:
GET_FIRST_IN_CHAIN
ADD_END_OFF_CHAIN
FIND_IN_CHAIN


Tony Thigpen

[Paul Gilmartin]

On 2015-01-22, at 06:54, Tony Thigpen wrote:

> I have used longer-than-8 macros for many years. Works great. I have one source macro that I include at the top of the member that is just 8 characters long. Inside, it has many macro 'redefs' so that I can use a long macro name in the code, but it gets converted to a shorter 8 character macro before going out to the library to get the macro.
>
> A short example:
>
> MACRO
> &NAME PERFORM_ON &ADDR,&BAD_VALUE=
> &NAME PERFORMO &ADDR,BAD_VALUE=&BAD_VALUE
> MEND
>

An excellent refutation of those who insist that 8 characters
are all that anybody should ever need. or that 44 characters
are all that anybody should ever need. Those limits impel
users such as you to reinvent that wheel repeatedly, repeatedly.

Of course, the z/OS UNIX filesystem has far more generous limits.
If only HLASM would exploit them as XLC does ...

BTW, it's regrettable that HLASM has no constructs such as POSIX
shell has to designate the entire argument list (viz. "$@").
I could imagine the renamed macro call as something such as:

&NAME PERFORMO &(1-*)

... where "&(1-*)" would mean the entire argument list. Likewise,
an analogue of "shift N" to delete the first n arguments and shift
the remaining ones left N positions could be very useful, often
removing the requirement to code tedious loops.

-- gil

[Tony Thigpen]

I don't have z/OS, I actually code assembler using:
VM, VSE, and Dignus (to upload as objects to VSE).

Dignus lets me use long macro names natively. And, I use it for most
things, but one of my jobs requires me to assemble code for VSE using
VM's assembler, so that is why I came up with the remapping macros.

Tony Thigpen

[Ze'ev Atlas]

   
>​Lastly, it might be nice to have a program which can
>"pseudo-compile" a source program and not only flag machine instruction
>opcodes which exist as members in the SYSLIB concatenation, but would also
>create an IEBUPDTE control deck which puts a ":MAC" on the end of the
>opcode. The user could then edit this and use it to more easily update
>their source.

Extracting all member names (and their library names) in the SYSLIB concatenation, should be trivial even in Rexx.  The z13 mnemonics table is available.  Now use ICETOOLS and find all corresponding names.ZA

[M. Ray Mullins]

The HLASMTK SPMs have been doing this for years. Macros like IF are
OPSYNed to ASM_IF, and the source for ASM_IF is in the copy member.

-- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/
http://www.z390.org/ German is essentially a form of assembly language
consisting entirely of far calls heavily accented with throaty guttural
sounds. ---ilvi French is essentially German with messed-up
pronunciation and spelling. --Robert B Wilson English is essentially
French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]

-- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/
http://www.z390.org/ German is essentially a form of assembly language
consisting entirely of far calls heavily accented with throaty guttural
sounds. ---ilvi French is essentially German with messed-up
pronunciation and spelling. --Robert B Wilson English is essentially
French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]

[Ray Mullins]

Of course, it would have helped if I'd provided an actual example of
something longer than 8. SELECT -> ASM_SELECT. :)

[Abe Kornelis]

John,

I have various macros that use embedded macros.
To avoid naming collisions I have always used more than 8 characters to
name these macros.

I can tell you: it has worked fine for me from day one.

Kind regards,
Abe Kornelis.
==========

John Ehrman schreef op 21-1-2015 om 20:02:

[Robert Ngan]

I've actually used both the new instruction and the macro of the same name,
e.g. for MVHHI

MACRO ,
&Label MVHHI &S,&I
PUSH ACONTROL,PRINT,NOPRINT
PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL
ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages
POP PRINT,NOPRINT Print following instruction
&Label MVHHI &S,&I
POP ACONTROL,NOPRINT
MEND


for values less than 32K, I just use the actual instruction:

MVHHI field,12345

but for (unsigned) values 32K or larger, I use the macro to avoid that (in
this particular situation) annoying warning:

MVHHI:MAC field,40000

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

2015/01/22 07:42:47:

> From: John McKown <john.arch...@GMAIL.COM>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 2015/01/22 07:46
> Subject: Re: 8 character mnemonics

> Sent by: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU>
>

[Chris Bowen]

With apologies for lateness and to those with unaware of the received wisdom about parts of Southern England (almost everybody?).

>>Ain't progress wonderful?

>Anyone know how to stop it ? (progress that is)

Relocate to the Isle of Wight?

[Steve Smith]

For this case you can append "-65536" (or x'10000') to get the value
without a warning.

00000080 E544 D120 3039 00000120 210 MVHHI
FIELD1,12345
00000086 E544 D120 9C40 00000120 211 MVHHI
FIELD1,40000
** ASMA320W Immediate field operand may have incorrect sign or
magnitude
** ASMA435I Record 71 in TSSAS.WORK.ASM(TEST3) on volume:
TSO003
0000008C E544 D120 9C40 00000120 212 MVHHI
FIELD1,40000-65536
214
@AUTO
00000120 00000000 00000128 215+@@TEST3D DSECT
00000120 216 FIELD1 DS H

Another alternative is to just specify SUPRWARN(320), or
TYPECHECK(NOMAGNITUDE) once, since it's typically not that useful anyway.

--
sas

[Robert Ngan]

The warning is not useful for MVHHI since there's no actual sign extension.
For MVGHI and MVHI, it is useful for flagging (unexpected) sign extension,
specifically when the immediate value is an expression.

I remember using the -65536 trick, but for some reason I stopped using it
and then forgot about it (must be getting old!).

Robert Ngan
CSC financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

2015/01/26 10:37:40:

[Abe Kornelis]

Chris,

Unless my grasp of the English language it failing me,
I would be utterly hesitant to relocate to any location ascribed to a
Wight ;-)

Kind regards
Abe Kornelis
==========

Chris Bowen schreef op 26-1-2015 om 10:34:

[Steve Smith]

Yeah, I should have just left that last sentence out. My typical isn't
necessarily anyone else's, and besides, I don't like to suppress warnings
myself.

sas

--
sas

[Mar...@pi-sysprog.de]

Reading the new POP I have a hard time to find

CAD CADE CADG CADGE CADGH CADGL CADGNE CADGNH CADGNL CADH
CADL CADNE CADNH CADNL

they are mentioned in "New hardware support - APAR PM79901"

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[Ray Mansell]

That would be because they are not there. They are undocumented
instructions.

Ray

[John P. Baker]

Martin,

I believe that these are new extended mnemonics rather than new hardware
instructions.

John P. Baker

[Mar...@pi-sysprog.de]

John,

>> I believe that these are new extended mnemonics rather than new hardware
instructions.

Yes and no- I believe that
CAD and CADG are instructions. All others are extended mnemonics

CAD(/G)

compare and die (/gorgeous)

compute (first add then divide) (/gorgeous)

calculate absorbation deflate (/general)

confederated academy decent

but these are based on fantasy and too much Andromeda/Starwars/Startrek