AW: Re: Performance of Decimal Floating Point Instruction

[Peter Hunkeler]

> We have this "technique" as well.  Interestingly, at least the last time I 
> checked, it still works (causes the S0C7) if the packed decimal field is 
> signed (PIC S9), but not if its unsigned (PIC 9).

>?What is the fix?  When was it released?


Be careful, and change your technique. In another case. I was looking at what 
the compiler generate, depending on the number of digits define for a variable. 
I found at least four different instruction sequences being generated for the 
same MOVE statement. And this is also heavily dependent on the ARCH level used 
to compile.


If you need a way to ABEND, use the proper LE service, or an assembler routine. 
Anything else will bite you sooner or later.


--
Peter Hunkeler










---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

> If you need a way to ABEND, use the proper LE service, or an assembler
routine. Anything else will bite you sooner or later.

AMEN!

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Hunkeler
Sent: Thursday, May 11, 2017 4:33 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: AW: Re: Performance of Decimal Floating Point Instruction

 
> We have this "technique" as well.  Interestingly, at least the last time I
checked, it still works (causes the S0C7) if the packed decimal field is
signed (PIC S9), but not if its unsigned (PIC 9). 
 
>?What is the fix?  When was it released? 


Be careful, and change your technique. In another case. I was looking at
what the compiler generate, depending on the number of digits define for a
variable. I found at least four different instruction sequences being
generated for the same MOVE statement. And this is also heavily dependent on
the ARCH level used to compile.


If you need a way to ABEND, use the proper LE service, or an assembler
routine. Anything else will bite you sooner or later.

Re: Performance of Decimal Floating Point Instruction

[Swarbrick, Frank]

Oh I know.  We've already stated the direction to not use this method going 
forward.  But with 30+ years of legacy code in place that uses it...

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Peter Hunkeler
Sent: Thursday, May 11, 2017 5:33 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: AW: Re: Performance of Decimal Floating Point Instruction


> We have this "technique" as well.  Interestingly, at least the last time I 
> checked, it still works (causes the S0C7) if the packed decimal field is 
> signed (PIC S9), but not if its unsigned (PIC 9).

>?What is the fix?  When was it released?


Be careful, and change your technique. In another case. I was looking at what 
the compiler generate, depending on the number of digits define for a variable. 
I found at least four different instruction sequences being generated for the 
same MOVE statement. And this is also heavily dependent on the ARCH level used 
to compile.


If you need a way to ABEND, use the proper LE service, or an assembler routine. 
Anything else will bite you sooner or later.


--
Peter Hunkeler










---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

Re: Performance of Decimal Floating Point Instruction

[Paul Gilmartin]

On 2017-05-11, at 06:34, Charles Mills wrote:

>> If you need a way to ABEND, use the proper LE service, or an assembler
> routine. Anything else will bite you sooner or later.
> 
> AMEN!
>  
No more "DC H'0'"

-- gil

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

DC H'0' *is* an assembler routine!

It's like when my code blew up on a S0C1 because the customer was running on
too low an architecture. (Yes, pre-sales was supposed to ask but forgot.) My
boss said "can't you put in an error message for that?" and I said "S0C1
*is* an error message." (Didn't fly.)

Regarding H'0' as a termination routine, 0 is architecturally guaranteed to
always be an invalid opcode, so I say it passes the "bite" test.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Thursday, May 11, 2017 10:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On 2017-05-11, at 06:34, Charles Mills wrote:

>> If you need a way to ABEND, use the proper LE service, or an assembler
> routine. Anything else will bite you sooner or later.
> 
> AMEN!
>  
No more "DC H'0'"

-- gil

Re: Performance of Decimal Floating Point Instruction

[John McKown]

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>

​My current favorite is : J *+2 which results in a S0C1, since it is now
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces
my previous favorite of: EX * which is an S0C3.

But I agree that using something like CEE3ABD​ is the "proper" way to go in
an LE environment. Most of my HLASM code is now LE enabled (the main
exceptions being "user exits").



>
> -- gil
>



-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Performance of Decimal Floating Point Instruction

[Ze'ev Atlas]

Many years ago I knew a guy who would terminare programs by EX  *

Sent from Yahoo Mail on Android 
 
  On Thu, May 11, 2017 at 1:18 PM, Charles Mills wrote:   DC 
H'0' *is* an assembler routine!

It's like when my code blew up on a S0C1 because the customer was running on
too low an architecture. (Yes, pre-sales was supposed to ask but forgot.) My
boss said "can't you put in an error message for that?" and I said "S0C1
*is* an error message." (Didn't fly.)

Regarding H'0' as a termination routine, 0 is architecturally guaranteed to
always be an invalid opcode, so I say it passes the "bite" test.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Thursday, May 11, 2017 10:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On 2017-05-11, at 06:34, Charles Mills wrote:

>> If you need a way to ABEND, use the proper LE service, or an assembler
> routine. Anything else will bite you sooner or later.
> 
> AMEN!
>  
No more "DC H'0'"

-- gil
  

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

And one of these days the architecture starts allowing EX of an EX and it fails 
the bite test.

 

Charles

 

From: Ze'ev Atlas [mailto:zatl...@yahoo.com] 
Sent: Thursday, May 11, 2017 10:24 AM
To: charl...@mcn.org; ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

 

Many years ago I knew a guy who would terminare programs by EX  *

Sent from Yahoo Mail on Android 
 

 

On Thu, May 11, 2017 at 1:18 PM, Charles Mills

 wrote:

DC H'0' *is* an assembler routine!

It's like when my code blew up on a S0C1 because the customer was running on
too low an architecture. (Yes, pre-sales was supposed to ask but forgot.) My
boss said "can't you put in an error message for that?" and I said "S0C1
*is* an error message." (Didn't fly.)

Regarding H'0' as a termination routine, 0 is architecturally guaranteed to
always be an invalid opcode, so I say it passes the "bite" test.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Thursday, May 11, 2017 10:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On 2017-05-11, at 06:34, Charles Mills wrote:

>> If you need a way to ABEND, use the proper LE service, or an assembler
> routine. Anything else will bite you sooner or later.
> 
> AMEN!
>  
No more "DC H'0'"

-- gil

Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Charles Mills]

What is *wrong* with DC H'0'? It has the advantage of being incredibly 
straightforward. I had to spend a minute thinking about J *+2; I pretty much 
guarantee you anyone with six months of HLASM experience would "get" DC H'0'.

I don't write much assembler anymore but if I did I think I might define a 
bunch of error situation equates in the 0 < value < 256 range:

Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.

Then one could code 

  DC  Y(Blowup_no_input) 

And it would (a.) be somewhat self-documenting in the source code and (b.) 
would more or less diagnose itself in a dump.

And if 255 were not enough codes, one could go to 16 million+ with DC 
FL4(Blowup_whatever).

Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't 
possibly be going through this code, could I?"). If is a "real" error then it 
should have a "real" termination with messages, a return code, a user ABEND, 
whatever is appropriate to the context, but something better than a 
S0C1/S0C3/S0C7. Three years from now if our support crew gets a call reporting 
a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked out a user 
ABEND number that we always used then they could go "aha!" and look up the 
reason code.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an 
> >> assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>

​My current favorite is : J *+2 which results in a S0C1, since it is now 
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my 
previous favorite of: EX * which is an S0C3.

Re: Performance of Decimal Floating Point Instruction

[John McKown]

On Thu, May 11, 2017 at 12:32 PM, Charles Mills  wrote:

> And one of these days the architecture starts allowing EX of an EX and it
> fails the bite test.
>

​I really doubt that IBM would make such a change to the existing EX
instruction. IBM well knows that people (idiots? like me) use EX 0,* as a
one instruction guaranteed abend. If they did do such a thing, I would
expect them to deliberately check for that specific case and force a S0C3
(actually PIC 3 - not COBOL). I don't actually like the EX instructions. I
remember the implementation of such in the Xerox Sigma series. Every
instruction on it was 4 bytes long and so would fit into one of the general
purpose registers. That would allow you to "execute" any instruction, which
was created inside any register. (another weird aspect is that "absolute"
address 0x00 .. 0x0F actually mapped to general registers 0x00..0x0F, so
you couldn't really use the 16 bytes of memory as actual memory. And for
those 16 addresses, the "memory" accessed 32 bits instead of 8 bits.)
Seeing as how the longest instruction on the z is 48 bits (6 bytes), such
an implementation might even possible in today's IBM z by using a 64 bit
register.


> Charles
>

-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Richard Kuebbing]

The only issue I ever had with this is that S0C1's are common "real" abends.  
On the other hand this almost never occurs:

EX 0,*
EXRL 0,*

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Charles Mills
Sent: Thursday, May 11, 2017 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Quick error termination of an assembler routine (Was: Performance of 
Decimal Floating Point Instruction)

What is *wrong* with DC H'0'? It has the advantage of being incredibly 
straightforward. I had to spend a minute thinking about J *+2; I pretty much 
guarantee you anyone with six months of HLASM experience would "get" DC H'0'.

I don't write much assembler anymore but if I did I think I might define a 
bunch of error situation equates in the 0 < value < 256 range:

Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.

Then one could code 

  DC  Y(Blowup_no_input) 

And it would (a.) be somewhat self-documenting in the source code and (b.) 
would more or less diagnose itself in a dump.

And if 255 were not enough codes, one could go to 16 million+ with DC 
FL4(Blowup_whatever).

Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't 
possibly be going through this code, could I?"). If is a "real" error then it 
should have a "real" termination with messages, a return code, a user ABEND, 
whatever is appropriate to the context, but something better than a 
S0C1/S0C3/S0C7. Three years from now if our support crew gets a call reporting 
a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked out a user 
ABEND number that we always used then they could go "aha!" and look up the 
reason code.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an 
> >> assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>

​My current favorite is : J *+2 which results in a S0C1, since it is now 
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my 
previous favorite of: EX * which is an S0C3.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you

Re: Performance of Decimal Floating Point Instruction

[Farley, Peter x23353]

PMFJI, but really, even for non-LE subroutines how hard is it to save your 
registers in your own R13 area, write an inline WTO with message indicating 
where and why you want to blow up and an ABEND macro right after?  Yes, the WTO 
is non-reentrant.  Making it reentrant is not that hard.  IMHO an ABEND macro 
with a unique abend code is far preferable to any of the discussed techniques 
except during actual development unit testing (before any client/user ever sees 
it), but maybe that's just me.

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 1:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:32 PM, Charles Mills  wrote:

> And one of these days the architecture starts allowing EX of an EX and it
> fails the bite test.
>

​


> Charles
>

-- 


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.

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Tony Thigpen]

For initial testing and debugging, I like:
DC X'00xx' where 'nn' is a unique number. I get a blow-up and by looking 
at the instruction in the dump, I know which condition I hit without 
thinking.


Tony Thigpen

Charles Mills wrote on 05/11/2017 01:44 PM:

What is *wrong* with DC H'0'? It has the advantage of being incredibly straightforward. I 
had to spend a minute thinking about J *+2; I pretty much guarantee you anyone with six 
months of HLASM experience would "get" DC H'0'.

I don't write much assembler anymore but if I did I think I might define a bunch of 
error situation equates in the 0 < value < 256 range:

Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.

Then one could code

   DC  Y(Blowup_no_input)

And it would (a.) be somewhat self-documenting in the source code and (b.) 
would more or less diagnose itself in a dump.

And if 255 were not enough codes, one could go to 16 million+ with DC 
FL4(Blowup_whatever).

Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't possibly be going through this code, 
could I?"). If is a "real" error then it should have a "real" termination with messages, a 
return code, a user ABEND, whatever is appropriate to the context, but something better than a S0C1/S0C3/S0C7. Three 
years from now if our support crew gets a call reporting a S0C1/S0C3/S0C7 are they going to have a clue? But if we 
staked out a user ABEND number that we always used then they could go "aha!" and look up the reason code.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:


On 2017-05-11, at 06:34, Charles Mills wrote:


If you need a way to ABEND, use the proper LE service, or an
assembler

routine. Anything else will bite you sooner or later.

AMEN!


No more "DC H'0'"



​My current favorite is : J *+2 which results in a S0C1, since it is now 
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my 
previous favorite of: EX * which is an S0C3.

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

Absent EX how do you do a variable length PACK or MVO or ...

Surely not with an MVI into the instruction stream ...

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:32 PM, Charles Mills  wrote:

> And one of these days the architecture starts allowing EX of an EX and 
> it fails the bite test.
>

​I really doubt that IBM would make such a change to the existing EX 
instruction. IBM well knows that people (idiots? like me) use EX 0,* as a one 
instruction guaranteed abend. If they did do such a thing, I would expect them 
to deliberately check for that specific case and force a S0C3 (actually PIC 3 - 
not COBOL). I don't actually like the EX instructions. I remember the 
implementation of such in the Xerox Sigma series. Every instruction on it was 4 
bytes long and so would fit into one of the general purpose registers. That 
would allow you to "execute" any 

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Gibney, Dave]

In days of limited storage, sure. But, today, why not
DC X''
DC C'I blew up here because the moon is blue'

> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Tony Thigpen
> Sent: Thursday, May 11, 2017 11:28 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Quick error termination of an assembler routine (Was:
> Performance of Decimal Floating Point Instruction)
> 
> For initial testing and debugging, I like:
> DC X'00xx' where 'nn' is a unique number. I get a blow-up and by looking at
> the instruction in the dump, I know which condition I hit without thinking.
> 
> Tony Thigpen
> 
> Charles Mills wrote on 05/11/2017 01:44 PM:
> > What is *wrong* with DC H'0'? It has the advantage of being incredibly
> straightforward. I had to spend a minute thinking about J *+2; I pretty much
> guarantee you anyone with six months of HLASM experience would "get" DC
> H'0'.
> >
> > I don't write much assembler anymore but if I did I think I might define a
> bunch of error situation equates in the 0 < value < 256 range:
> >
> > Blowup_no_input EQU 1
> > Blowup_invalid_parm EQU 2
> > Etc.
> >
> > Then one could code
> >
> >DC  Y(Blowup_no_input)
> >
> > And it would (a.) be somewhat self-documenting in the source code and
> (b.) would more or less diagnose itself in a dump.
> >
> > And if 255 were not enough codes, one could go to 16 million+ with DC
> FL4(Blowup_whatever).
> >
> > Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't
> possibly be going through this code, could I?"). If is a "real" error then it
> should have a "real" termination with messages, a return code, a user ABEND,
> whatever is appropriate to the context, but something better than a
> S0C1/S0C3/S0C7. Three years from now if our support crew gets a call
> reporting a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked
> out a user ABEND number that we always used then they could go "aha!" and
> look up the reason code.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Assembler List
> > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown
> > Sent: Thursday, May 11, 2017 10:24 AM
> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > Subject: Re: Performance of Decimal Floating Point Instruction
> >
> > On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 0014e0e4a59b-
> dmarc-requ...@listserv.uga.edu> wrote:
> >
> >> On 2017-05-11, at 06:34, Charles Mills wrote:
> >>
>  If you need a way to ABEND, use the proper LE service, or an
>  assembler
> >>> routine. Anything else will bite you sooner or later.
> >>>
> >>> AMEN!
> >>>
> >> No more "DC H'0'"
> >>
> >
> > ​My current favorite is : J *+2 which results in a S0C1, since it is now
> guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my
> previous favorite of: EX * which is an S0C3.
> >
> >

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

> how hard is it to save your registers in your own R13 area, write an inline 
> WTO

VERY hard if you are on an SRB, X-memory, or hold any locks.

> IMHO an ABEND macro with a unique abend code is far preferable to any of the 
> discussed techniques except during actual development unit testing

Agreed.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: Thursday, May 11, 2017 11:23 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

PMFJI, but really, even for non-LE subroutines how hard is it to save your 
registers in your own R13 area, write an inline WTO with message indicating 
where and why you want to blow up and an ABEND macro right after?  Yes, the WTO 
is non-reentrant.  Making it reentrant is not that hard.  IMHO an ABEND macro 
with a unique abend code is far preferable to any of the discussed techniques 
except during actual development unit testing (before any client/user ever sees 
it), but maybe that's just me.

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 1:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:32 PM, Charles Mills  wrote:

> And one of these days the architecture starts allowing EX of an EX and 
> it fails the bite test.
>

​


> Charles
>

-- 


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.

Re: Performance of Decimal Floating Point Instruction

[John McKown]

On Thu, May 11, 2017 at 1:28 PM, Charles Mills  wrote:

> Absent EX how do you do a variable length PACK or MVO or ...
>

​I said that I didn't _like_ EX. Not that I didn't _use_ it. I'd prefer to
"synthesize" an instruction into a 64 bit GPR​ and then "EX" the contents
of the GPR. That would allow me to do more than just modify the value in
second byte of the instruction. I understand why EX exists (just as you
have pointed out) and why it does what it does. But a more generalized
facility would be, to me, "nicer". But, in reality (which stinks in some
ways), I understand that IBM won't create a new instruction "because John
thinks it would be nice". [grin]


> Surely not with an MVI into the instruction stream ...
>
> Charles
>
>
-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Tony Thigpen]

Easier my way to find and replace the traps with better code. Or, to 
remove. Just one line to fix. (I use xedit, so it's easier to do this 
than in ISPF.)


Tony Thigpen

Gibney, Dave wrote on 05/11/2017 02:34 PM:

In days of limited storage, sure. But, today, why not
DC X''
DC C'I blew up here because the moon is blue'


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
l...@listserv.uga.edu] On Behalf Of Tony Thigpen
Sent: Thursday, May 11, 2017 11:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

For initial testing and debugging, I like:
DC X'00xx' where 'nn' is a unique number. I get a blow-up and by looking at
the instruction in the dump, I know which condition I hit without thinking.

Tony Thigpen

Charles Mills wrote on 05/11/2017 01:44 PM:

What is *wrong* with DC H'0'? It has the advantage of being incredibly

straightforward. I had to spend a minute thinking about J *+2; I pretty much
guarantee you anyone with six months of HLASM experience would "get" DC
H'0'.


I don't write much assembler anymore but if I did I think I might define a

bunch of error situation equates in the 0 < value < 256 range:


Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.

Then one could code

DC  Y(Blowup_no_input)

And it would (a.) be somewhat self-documenting in the source code and

(b.) would more or less diagnose itself in a dump.


And if 255 were not enough codes, one could go to 16 million+ with DC

FL4(Blowup_whatever).


Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't

possibly be going through this code, could I?"). If is a "real" error then it
should have a "real" termination with messages, a return code, a user ABEND,
whatever is appropriate to the context, but something better than a
S0C1/S0C3/S0C7. Three years from now if our support crew gets a call
reporting a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked
out a user ABEND number that we always used then they could go "aha!" and
look up the reason code.


Charles


-Original Message-
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 0014e0e4a59b-

dmarc-requ...@listserv.uga.edu> wrote:



On 2017-05-11, at 06:34, Charles Mills wrote:


If you need a way to ABEND, use the proper LE service, or an
assembler

routine. Anything else will bite you sooner or later.

AMEN!


No more "DC H'0'"



​My current favorite is : J *+2 which results in a S0C1, since it is now

guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my
previous favorite of: EX * which is an S0C3.

AW: Re: Performance of Decimal Floating Point Instruction

[Martin Trübner]

>> J * 
that sure is nice...But a baseless EX would be a EXRL 0,* ..nice 0C3 
(op-sys Independent as opposed to an LE-conforming Abend which IBM can not 
produce without an indication of the op-sys in the name)
Send by Martin from a smart phone = no keyboard  but lots of typos.

 Ursprüngliche Nachricht 
Von: John McKown  
Datum: 11.05.17  19:23  (GMT+01:00) 
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Betreff: Re: Performance of Decimal Floating Point Instruction 

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>

​My current favorite is : J *+2 which results in a S0C1, since it is now
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces
my previous favorite of: EX * which is an S0C3.

But I agree that using something like CEE3ABD​ is the "proper" way to go in
an LE environment. Most of my HLASM code is now LE enabled (the main
exceptions being "user exits").



>
> -- gil
>



-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[John McKown]

On Thu, May 11, 2017 at 1:34 PM, Gibney, Dave  wrote:

> In days of limited storage, sure. But, today, why not
> DC X''
> DC C'I blew up here because the moon is blue'
>
>
​Looks nice. I'd probably do
   DC H'0',C'FIXME: YOU DID SOMETHING WEIRD AND I''M CONFUSED.'​


-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Performance of Decimal Floating Point Instruction

[Charles Mills]

Ah. I get what you are saying. That would be cool -- an "EXG," that would 
execute the contents of a grande register. You could build (reentrantly) any 
instruction you wanted. How about EXMG, that would execute the contents of a 
series of multiple adjacent registers, analogous to LMG?

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 11:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 1:28 PM, Charles Mills  wrote:

> Absent EX how do you do a variable length PACK or MVO or ...
>

​I said that I didn't _like_ EX. Not that I didn't _use_ it. I'd prefer to 
"synthesize" an instruction into a 64 bit GPR​ and then "EX" the contents of 
the GPR. That would allow me to do more than just modify the value in second 
byte of the instruction. I understand why EX exists (just as you have pointed 
out) and why it does what it does. But a more generalized facility would be, to 
me, "nicer". But, in reality (which stinks in some ways), I understand that IBM 
won't create a new instruction "because John thinks it would be nice". [grin]


> Surely not with an MVI into the instruction stream ...
>
> Charles
>
>
--
Advertising is a valuable economic factor because it is the cheapest way of 
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Performance of Decimal Floating Point Instruction

[John McKown]

On Thu, May 11, 2017 at 1:54 PM, Charles Mills  wrote:

> Ah. I get what you are saying. That would be cool -- an "EXG," that would
> execute the contents of a grande register. You could build (reentrantly)
> any instruction you wanted. How about EXMG, that would execute the contents
> of a series of multiple adjacent registers, analogous to LMG?
>

​That would probably be an excellent way to synthesize a small fast loop.​
I don't know how the internals of the z machines work (behind the ISA), but
if they are like Intel, where the ISA instructions are "decomposed" into
micro-ops, that might be a real nice way to tell the machine: "these
instructions are a loop - create a micro-ops program and run it."


> Charles
>
>
-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

Re: Performance of Decimal Floating Point Instruction

[Farley, Peter x23353]

Excellent idea!  Could be a superb mechanism for setting up instruction-tracing 
or debugging software (see program TRACE390 in CBT file 391, for example) 
without the overhead of ESTAE or the (currently unsupported under z/OS) TRAP 
exits.

But perhaps not directly from any general register (think extreme EREG that 
reloads ALL registers from the last stack entry, including the one you used to 
execute the EREG, or LMG 0,15,...).  Perhaps a dedicated (set of?) "instruction 
register(s)"?  That would be cool.  Would need at least RR type instructions to 
load them from GR's.

Just dreaming . . . 

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 2:39 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 1:28 PM, Charles Mills  wrote:

> Absent EX how do you do a variable length PACK or MVO or ...
>

​I said that I didn't _like_ EX. Not that I didn't _use_ it. I'd prefer to
"synthesize" an instruction into a 64 bit GPR​ and then "EX" the contents
of the GPR. That would allow me to do more than just modify the value in
second byte of the instruction. I understand why EX exists (just as you
have pointed out) and why it does what it does. But a more generalized
facility would be, to me, "nicer". But, in reality (which stinks in some
ways), I understand that IBM won't create a new instruction "because John
thinks it would be nice". [grin]


> Surely not with an MVI into the instruction stream ...
>
> Charles
>
>
-- 


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.

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Tom Marchant]

On Thu, 11 May 2017 10:44:25 -0700, Charles Mills wrote:

>What is *wrong* with DC H'0'? It has the advantage of being incredibly 
>straightforward. I had to spend a minute thinking about J *+2; I pretty much 
>guarantee you anyone with six months of HLASM experience would "get" DC H'0'.

I wouldn't say that anything is wrong with it. But when it is included in code 
for a condition that should never occur and you haven't (yet) coded a proper 
error routine, the instruction before it is typically a branch over it. I don't 
know how big the branch taken hit on the pipeline is in that case. But in the J 
*+2 case, the normal path is to fall through, and only take the branch under 
the error condition.

-- 
Tom Marchant

Re: Performance of Decimal Floating Point Instruction

[Tom Marchant]

On Wed, 10 May 2017 19:08:01 +0200, Peter Hunkeler wrote:

>Is the performance of floating point instruction so much better today? I seem 
>to remember that floating point instructions had not been the fastest in 
>earlier times and machines (I may be wrong with this).

My understanding is that Decimal Floating Point was implemented in Millicode on 
the z9, but on the z10, it was implemented entirely in hardware. As such, I 
would expect it to be quite fast.

-- 
Tom Marchant

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Charles Mills]

Got it. Assuming the J *+2 is actually JNx *+2, where 'x' is the expected 
condition (Z following an LTR of a return code, for example).

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Tom Marchant
Sent: Thursday, May 11, 2017 12:36 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was: Performance 
of Decimal Floating Point Instruction)

On Thu, 11 May 2017 10:44:25 -0700, Charles Mills wrote:

>What is *wrong* with DC H'0'? It has the advantage of being incredibly 
>straightforward. I had to spend a minute thinking about J *+2; I pretty much 
>guarantee you anyone with six months of HLASM experience would "get" DC H'0'.

I wouldn't say that anything is wrong with it. But when it is included in code 
for a condition that should never occur and you haven't (yet) coded a proper 
error routine, the instruction before it is typically a branch over it. I don't 
know how big the branch taken hit on the pipeline is in that case. But in the J 
*+2 case, the normal path is to fall through, and only take the branch under 
the error condition.

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Paul Gilmartin]

On 2017-05-11, at 12:42, John McKown wrote:

> On Thu, May 11, 2017 at 1:34 PM, Gibney, Dave  wrote:
> 
>> In days of limited storage, sure. But, today, why not
>> DC X''
>> DC C'I blew up here because the moon is blue'
>> 
> ​Looks nice. I'd probably do
>   DC H'0',C'FIXME: YOU DID SOMETHING WEIRD AND I''M CONFUSED.'​
>  
Once, under a severe resource constraint, I wrote an error reporting
routine that just printed out its return address, leaving the user to
refer to the assembler listing to see a comment describing the error.

The developer was half the user base.  The other half frowned, but
tolerated it.

I believe PDP-6 allowed EX *.  Ooooh!  The 0-instruction loop!  EX
must have been interruptible so a single mischievous job couldn't
bogart the entire system.  PDP-6 and PDP-10 had indirect addressing
to arbitrary depth, but address generation was interruptible.  I never
got to try on PDP-10 an indirect addresing chain that threaded through
a number of pages exceeding the size of real memory.

On PDP-6, all instructions, registers, and memory locations were 36
bits.  The first 16 memory locations were the GRs unless you paid
extra for transistorized registers (in an outboard chassis!)  One
could copy a short loop into those registers and execute it there;
DIY caching.

CDC 3600 followed CDC 1604 which already had nearly fully populated
instruction space, so 3600 provided a "modify next instruction"
meta-instruction.  I believe there were extended mnemonics for many
of these.

-- gil

Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[Steve Thompson]

Has anyone ever seen S0C3 (PIC 3) as an accident?

I use EX 0,* to trigger a failure. I've never seen one, that I 
can remember, occur when executing data (such as happens when one 
takes a wild branch).


Just thought I'd ask while you all are kind of on the subject.

Regards,
Steve.T

Re: Performance of Decimal Floating Point Instruction

[Pieter Wiid]

Notably, Software AG's "Com-plete" did this. With a text error message 
following the abend point.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Ze'ev Atlas
Sent: 11 May 2017 19:24
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

Many years ago I knew a guy who would terminare programs by EX  *

Sent from Yahoo Mail on Android

  On Thu, May 11, 2017 at 1:18 PM, Charles Mills wrote:   DC 
H'0' *is* an assembler routine!

It's like when my code blew up on a S0C1 because the customer was running on 
too low an architecture. (Yes, pre-sales was supposed to ask but forgot.) My 
boss said "can't you put in an error message for that?" and I said "S0C1
*is* an error message." (Didn't fly.)

Regarding H'0' as a termination routine, 0 is architecturally guaranteed to 
always be an invalid opcode, so I say it passes the "bite" test.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Thursday, May 11, 2017 10:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On 2017-05-11, at 06:34, Charles Mills wrote:

>> If you need a way to ABEND, use the proper LE service, or an
>> assembler
> routine. Anything else will bite you sooner or later.
>
> AMEN!
>
No more "DC H'0'"

-- gil



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Performance of Decimal Floating Point Instruction

[Pieter Wiid]

Agreed

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: 11 May 2017 20:23
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

PMFJI, but really, even for non-LE subroutines how hard is it to save your 
registers in your own R13 area, write an inline WTO with message indicating 
where and why you want to blow up and an ABEND macro right after?  Yes, the WTO 
is non-reentrant.  Making it reentrant is not that hard.  IMHO an ABEND macro 
with a unique abend code is far preferable to any of the discussed techniques 
except during actual development unit testing (before any client/user ever sees 
it), but maybe that's just me.

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 1:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:32 PM, Charles Mills  wrote:

> And one of these days the architecture starts allowing EX of an EX and
> it fails the bite test.
>

​


> Charles
>

--


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.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Performance of Decimal Floating Point Instruction

[Pieter Wiid]

I wrote my own trace after seeing TRACE390, and not liking the way it did 
things. My code is re-entrant, up to date with most new instructions, caters 
for 64-bit, etc.
Was originally published in the MVS Update in the 90's, but much modified since 
then.

Obviously, with the release of the HLASM Toolkit's IDF, the something like 
TRACE390 is not really as helpful as it was 20 years ago.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: 11 May 2017 21:32
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

Excellent idea!  Could be a superb mechanism for setting up instruction-tracing 
or debugging software (see program TRACE390 in CBT file 391, for example) 
without the overhead of ESTAE or the (currently unsupported under z/OS) TRAP 
exits.

But perhaps not directly from any general register (think extreme EREG that 
reloads ALL registers from the last stack entry, including the one you used to 
execute the EREG, or LMG 0,15,...).  Perhaps a dedicated (set of?) "instruction 
register(s)"?  That would be cool.  Would need at least RR type instructions to 
load them from GR's.

Just dreaming . . .

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 2:39 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 1:28 PM, Charles Mills  wrote:

> Absent EX how do you do a variable length PACK or MVO or ...
>

​I said that I didn't _like_ EX. Not that I didn't _use_ it. I'd prefer to 
"synthesize" an instruction into a 64 bit GPR​ and then "EX" the contents of 
the GPR. That would allow me to do more than just modify the value in second 
byte of the instruction. I understand why EX exists (just as you have pointed 
out) and why it does what it does. But a more generalized facility would be, to 
me, "nicer". But, in reality (which stinks in some ways), I understand that IBM 
won't create a new instruction "because John thinks it would be nice". [grin]


> Surely not with an MVI into the instruction stream ...
>
> Charles
>
>
--


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.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus