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

[Tony Harminc]

On 16 May 2017 at 10:31, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> I have wondered in cases where the programmer knows a priori
> that branch taken is more likely whether a branch around a
> branch better exploits the branch prediction rules.  For
> example, instead of:
>
>  BCMASK,TARGET  Incorrectly predicts branch not taken
>
> How about:
>
>  BC15-MASK,*+8  Correctly predicts branch not taken
>  B TARGET   Correctly predicts branch taken
>
> Of course it would be better, if practical, to rearrange the code.
>

Or to use the Branch Prediction [Relative] Preload instruction. Assuming
recent hardware, etc. etc.

Tony H.

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

[Charles Mills]

I've wondered the same thing. Does it make sense to use two branches where
one would do, to make the conditional branch the unlikely path?

> And next year's model may negate the effort with something such as JIT
analysis.

I think even last year's model is more sophisticated than simply "always
assuming the branch will not be taken" but that is the default if all other
analyses fail.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Tuesday, May 16, 2017 7:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

On 2017-05-16, at 07:59, Pieter Wiid wrote:

> That's what the book says -- except for unconditional branches, BCT 
> and BXLE (and the relative and G variants) which predicts a branch.
>  
I have wondered in cases where the programmer knows a priori that branch
taken is more likely whether a branch around a branch better exploits the
branch prediction rules.  For example, instead of:

 BCMASK,TARGET  Incorrectly predicts branch not taken

How about:

 BC15-MASK,*+8  Correctly predicts branch not taken
 B TARGET   Correctly predicts branch taken

Of course it would be better, if practical, to rearrange the code.

And next year's model may negate the effort with something such as JIT
analysis.

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

[Paul Gilmartin]

On 2017-05-16, at 07:59, Pieter Wiid wrote:

> That's what the book says -- except for unconditional branches, BCT and BXLE
> (and the relative and G variants) which predicts a branch.
>  
I have wondered in cases where the programmer knows a priori
that branch taken is more likely whether a branch around a
branch better exploits the branch prediction rules.  For
example, instead of:

 BCMASK,TARGET  Incorrectly predicts branch not taken

How about:

 BC15-MASK,*+8  Correctly predicts branch not taken
 B TARGET   Correctly predicts branch taken

Of course it would be better, if practical, to rearrange the code.

And next year's model may negate the effort with something such as
JIT analysis.

-- gil

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

[Pieter Wiid]

That's what the book says -- except for unconditional branches, BCT and BXLE
(and the relative and G variants) which predicts a branch.


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent: 16 May 2017 14:44
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

Peter,

I never have gotten a handle on "branch prediction" within the i-cache
discussion. Are you saying that, for the most part, we should always try to
code so that the normal path is to not-branch wherever possible?

(I know, within limits.)

Tony Thigpen

Peter Relson wrote on 05/16/2017 08:31 AM:
> 
> Well, in reality you are right of course (who cares about the 
> i-cache?) but in theory one is branching around and NOT crashing, so 
> not wasting the i-cache is a desirable goal.
> 
>
> A program coded with any thought for performance would not be 
> "branching around and NOT crashing". It would be branching out of line 
> upon detecting the error so that the normal path takes no branch at all.
>
> Thus instead of "BZNOERROR" (or JZ or whatever), "BNZ   ERROR".
>
> Peter Relson
> z/OS Core Technology Design
>
>


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

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

[Charles Mills]

That's what makes the JNx *+2 technique kind of cool. It is both "branch on
error" and simultaneously "in line."

My "who cares about the i-cache" was premised on my earlier assertion that
S0C1'ing is appropriate only for quick testing and so forth, not as a
"production" technique.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Relson
Sent: Tuesday, May 16, 2017 5:31 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)


Well, in reality you are right of course (who cares about the i-cache?) 
but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.
 

A program coded with any thought for performance would not be "branching 
around and NOT crashing". It would be branching out of line upon detecting 
the error so that the normal path takes no branch at all.

Thus instead of "BZNOERROR" (or JZ or whatever), "BNZ   ERROR".

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

[Tony Thigpen]

Peter,

I never have gotten a handle on "branch prediction" within the i-cache 
discussion. Are you saying that, for the most part, we should always try 
to code so that the normal path is to not-branch wherever possible?


(I know, within limits.)

Tony Thigpen

Peter Relson wrote on 05/16/2017 08:31 AM:


Well, in reality you are right of course (who cares about the i-cache?)
but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.


A program coded with any thought for performance would not be "branching
around and NOT crashing". It would be branching out of line upon detecting
the error so that the normal path takes no branch at all.

Thus instead of "BZNOERROR" (or JZ or whatever), "BNZ   ERROR".

Peter Relson
z/OS Core Technology Design

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

[Peter Relson]

Well, in reality you are right of course (who cares about the i-cache?) 
but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.
 

A program coded with any thought for performance would not be "branching 
around and NOT crashing". It would be branching out of line upon detecting 
the error so that the normal path takes no branch at all.

Thus instead of "BZNOERROR" (or JZ or whatever), "BNZ   ERROR".

Peter Relson
z/OS Core Technology Design

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

[Ngan, Robert]

When using multiple EX instructions within a program to generate S0C3's, I'd 
use different registers to differentiate the S0C3's.
However, with EXRL, if you use a non-zero register, and it modifies the 
low-order nybble, the target instruction in no longer a EXRL!

Robert Ngan
CeleritiFinTech

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

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


CSC - This is a PRIVATE message - If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery.  NOTE: Regardless of content, this e-mail shall not operate to bind 
the Company to any order or other contract unless pursuant to explicit written 
agreement or government initiative expressly permitting the use of e-mail for 
such purpose.

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

[Tony Thigpen]

That is the problem with clipping emails, the original post was dropped 
and someone elses example was left in.


My original post was:
-
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.

-
Thus the reference to "2 bytes" in both of my last two posts.

Tony Thigpen

Gary Weinhold wrote on 05/14/2017 08:22 AM:

‎The example showed a prose constant following the abend-causing code.
   Original Message
From: Tony Thigpen
Sent: Sunday, May 14, 2017 07:06
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Reply To: IBM Mainframe Assembler List
Subject: Re: Quick error termination of an assembler routine (Was: Performance 
of Decimal Floating Point Instruction)


But, is 2 bytes "wasting the i-cache" in today's boxes?

Tony Thigpen

Charles Mills wrote on 05/14/2017 01:19 AM:

Well, in reality you are right of course (who cares about the i-cache?) but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.

Charles





Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone   +1.613.523.5500 x216
Email:  weinh...@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.


-Original Message-

From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent: Saturday, May 13, 2017 7:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

Who cares about the Instruction Cache? You are crashing the program.

Especially with just a one byte error code. We are talking about "it should
never get there" code, or test code to abend.

Tony Thigpen

Keven Hall wrote on 05/12/2017 06:53 PM:

Regarding code like:

   BZNOERROR  (If RC==0.)
   DCX'00',C'You shouldn'ta done that.'


I'd suggest documenting the error in source code rather than the

instruction cache (or using a 1-byte numeric error code.


Possibly I'm being pedantic.  For sure I'm dragging this thread ever

further from its original subject.


Keven


On May 12, 2017, at 11:57, Paul Gilmartin

<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:



On 2017-05-12, at 09:56, somitcw wrote:

My favourite was to branch to an odd address.

S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
If an operator called at 2:00AM, I would know who caused 3 pair of

socks.



Unfortunately, IIRC the exception occurs after the branch is taken so
the PSW provides no ready indication of the point of error.


Coding so that the assembler didn't flag it was needed but easy.
Something like:

BNE ERRLABEL-CSECT-1(BASEREG)


I suppose that could be doctored so the PSW points near either the
point at which the error was detected or to an error message.

I think of:
   BZNOERROR  (If RC==0.)
   DCX'00',C'You shouldn'ta done that.'
NOERROR  DS0X

-- gil

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

[Gary Weinhold]

‎The example showed a prose constant following the abend-causing code.
  Original Message
From: Tony Thigpen
Sent: Sunday, May 14, 2017 07:06
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Reply To: IBM Mainframe Assembler List
Subject: Re: Quick error termination of an assembler routine (Was: Performance 
of Decimal Floating Point Instruction)


But, is 2 bytes "wasting the i-cache" in today's boxes?

Tony Thigpen

Charles Mills wrote on 05/14/2017 01:19 AM:
> Well, in reality you are right of course (who cares about the i-cache?) but
> in theory one is branching around and NOT crashing, so not wasting the
> i-cache is a desirable goal.
>
> Charles
>
>
>

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone   +1.613.523.5500 x216
Email:  weinh...@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.


-Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Saturday, May 13, 2017 7:20 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Quick error termination of an assembler routine (Was:
> Performance of Decimal Floating Point Instruction)
>
> Who cares about the Instruction Cache? You are crashing the program.
>
> Especially with just a one byte error code. We are talking about "it should
> never get there" code, or test code to abend.
>
> Tony Thigpen
>
> Keven Hall wrote on 05/12/2017 06:53 PM:
>> Regarding code like:
>>>   BZNOERROR  (If RC==0.)
>>>   DCX'00',C'You shouldn'ta done that.'
>>
>> I'd suggest documenting the error in source code rather than the
> instruction cache (or using a 1-byte numeric error code.
>>
>> Possibly I'm being pedantic.  For sure I'm dragging this thread ever
> further from its original subject.
>>
>> Keven
>>
>>> On May 12, 2017, at 11:57, Paul Gilmartin
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>>>
 On 2017-05-12, at 09:56, somitcw wrote:

 My favourite was to branch to an odd address.

 S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
 If an operator called at 2:00AM, I would know who caused 3 pair of
> socks.

>>> Unfortunately, IIRC the exception occurs after the branch is taken so
>>> the PSW provides no ready indication of the point of error.
>>>
 Coding so that the assembler didn't flag it was needed but easy.
 Something like:

 BNE ERRLABEL-CSECT-1(BASEREG)

>>> I suppose that could be doctored so the PSW points near either the
>>> point at which the error was detected or to an error message.
>>>
>>> I think of:
>>>   BZNOERROR  (If RC==0.)
>>>   DCX'00',C'You shouldn'ta done that.'
>>> NOERROR  DS0X
>>>
>>> -- gil
>>
>>
>
>

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

[Tony Thigpen]

But, is 2 bytes "wasting the i-cache" in today's boxes?

Tony Thigpen

Charles Mills wrote on 05/14/2017 01:19 AM:

Well, in reality you are right of course (who cares about the i-cache?) but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent: Saturday, May 13, 2017 7:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

Who cares about the Instruction Cache? You are crashing the program.

Especially with just a one byte error code. We are talking about "it should
never get there" code, or test code to abend.

Tony Thigpen

Keven Hall wrote on 05/12/2017 06:53 PM:

Regarding code like:

  BZNOERROR  (If RC==0.)
  DCX'00',C'You shouldn'ta done that.'


I'd suggest documenting the error in source code rather than the

instruction cache (or using a 1-byte numeric error code.


Possibly I'm being pedantic.  For sure I'm dragging this thread ever

further from its original subject.


Keven


On May 12, 2017, at 11:57, Paul Gilmartin

<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:



On 2017-05-12, at 09:56, somitcw wrote:

My favourite was to branch to an odd address.

S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
If an operator called at 2:00AM, I would know who caused 3 pair of

socks.



Unfortunately, IIRC the exception occurs after the branch is taken so
the PSW provides no ready indication of the point of error.


Coding so that the assembler didn't flag it was needed but easy.
Something like:

BNE ERRLABEL-CSECT-1(BASEREG)


I suppose that could be doctored so the PSW points near either the
point at which the error was detected or to an error message.

I think of:
  BZNOERROR  (If RC==0.)
  DCX'00',C'You shouldn'ta done that.'
NOERROR  DS0X

-- gil

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

[Charles Mills]

Well, in reality you are right of course (who cares about the i-cache?) but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent: Saturday, May 13, 2017 7:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was:
Performance of Decimal Floating Point Instruction)

Who cares about the Instruction Cache? You are crashing the program.

Especially with just a one byte error code. We are talking about "it should
never get there" code, or test code to abend.

Tony Thigpen

Keven Hall wrote on 05/12/2017 06:53 PM:
> Regarding code like:
>>  BZNOERROR  (If RC==0.)
>>  DCX'00',C'You shouldn'ta done that.'
>
> I'd suggest documenting the error in source code rather than the
instruction cache (or using a 1-byte numeric error code.
>
> Possibly I'm being pedantic.  For sure I'm dragging this thread ever
further from its original subject.
>
> Keven
>
>> On May 12, 2017, at 11:57, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>>
>>> On 2017-05-12, at 09:56, somitcw wrote:
>>>
>>> My favourite was to branch to an odd address.
>>>
>>> S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
>>> If an operator called at 2:00AM, I would know who caused 3 pair of
socks.
>>>
>> Unfortunately, IIRC the exception occurs after the branch is taken so 
>> the PSW provides no ready indication of the point of error.
>>
>>> Coding so that the assembler didn't flag it was needed but easy.
>>> Something like:
>>>
>>> BNE ERRLABEL-CSECT-1(BASEREG)
>>>
>> I suppose that could be doctored so the PSW points near either the 
>> point at which the error was detected or to an error message.
>>
>> I think of:
>>  BZNOERROR  (If RC==0.)
>>  DCX'00',C'You shouldn'ta done that.'
>> NOERROR  DS0X
>>
>> -- gil
>
>

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

[Tony Thigpen]

Who cares about the Instruction Cache? You are crashing the program.

Especially with just a one byte error code. We are talking about "it 
should never get there" code, or test code to abend.


Tony Thigpen

Keven Hall wrote on 05/12/2017 06:53 PM:

Regarding code like:

 BZNOERROR  (If RC==0.)
 DCX'00',C'You shouldn'ta done that.'


I'd suggest documenting the error in source code rather than the instruction 
cache (or using a 1-byte numeric error code.

Possibly I'm being pedantic.  For sure I'm dragging this thread ever further 
from its original subject.

Keven


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


On 2017-05-12, at 09:56, somitcw wrote:

My favourite was to branch to an odd address.

S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
If an operator called at 2:00AM, I would know who caused 3 pair of socks.


Unfortunately, IIRC the exception occurs after the branch is taken
so the PSW provides no ready indication of the point of error.


Coding so that the assembler didn't flag it was needed but easy.
Something like:

BNE ERRLABEL-CSECT-1(BASEREG)


I suppose that could be doctored so the PSW points near
either the point at which the error was detected or to
an error message.

I think of:
 BZNOERROR  (If RC==0.)
 DCX'00',C'You shouldn'ta done that.'
NOERROR  DS0X

-- gil

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

[Paul Gilmartin]

On 2017-05-12, at 16:53, Keven Hall wrote:

> Regarding code like:
>>BZNOERROR  (If RC==0.)
>>DCX'00',C'You shouldn'ta done that.'
> 
> I'd suggest documenting the error in source code rather than the instruction 
> cache (or using a 1-byte numeric error code.
>  
Good point.  So bunch them under a LOCTR far away and unlikely to
contend with cache.  1-byte error codes and reporting errors by
program check are a relic of antiquated storage constraints.  Even
decades ago, I remember a system from another vendor which had no
error codes.  Explanations appeared in the diagnostic manual
arranged by message texts in alphabetical order.  I suppose that
paid too little attention to national languages.  Nowadays for
systems lacking message codes, GIYF.

-- gil

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

[Keven Hall]

Regarding code like:
> BZNOERROR  (If RC==0.)
> DCX'00',C'You shouldn'ta done that.'

I'd suggest documenting the error in source code rather than the instruction 
cache (or using a 1-byte numeric error code.

Possibly I'm being pedantic.  For sure I'm dragging this thread ever further 
from its original subject.

Keven

> On May 12, 2017, at 11:57, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
>> On 2017-05-12, at 09:56, somitcw wrote:
>> 
>> My favourite was to branch to an odd address.
>> 
>> S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
>> If an operator called at 2:00AM, I would know who caused 3 pair of socks.
>> 
> Unfortunately, IIRC the exception occurs after the branch is taken
> so the PSW provides no ready indication of the point of error.
> 
>> Coding so that the assembler didn't flag it was needed but easy.
>> Something like:
>> 
>> BNE ERRLABEL-CSECT-1(BASEREG)
>> 
> I suppose that could be doctored so the PSW points near
> either the point at which the error was detected or to
> an error message.
> 
> I think of:
> BZNOERROR  (If RC==0.)
> DCX'00',C'You shouldn'ta done that.'
> NOERROR  DS0X
> 
> -- gil

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

[Webster, Chris]

The BEA tells where you came from.  It means (going back to an earlier comment) 
you don't need to branch around x'00'.  You can freely branch to it.  It is so 
useful I wish it was part of the symptom dump.

...chris.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Paul Gilmartin
Sent: May-12-17 9:57 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was: Performance 
of Decimal Floating Point Instruction)

On 2017-05-12, at 09:56, somitcw wrote:

> My favourite was to branch to an odd address.
> 
> S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
> If an operator called at 2:00AM, I would know who caused 3 pair of socks.
>  
Unfortunately, IIRC the exception occurs after the branch is taken so the PSW 
provides no ready indication of the point of error.

> Coding so that the assembler didn't flag it was needed but easy.
> Something like:
> 
>  BNE ERRLABEL-CSECT-1(BASEREG)
>  
I suppose that could be doctored so the PSW points near either the point at 
which the error was detected or to an error message.

I think of:
 BZNOERROR  (If RC==0.)
 DCX'00',C'You shouldn'ta done that.'
NOERROR  DS0X

-- gil

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

[Paul Gilmartin]

On 2017-05-12, at 09:56, somitcw wrote:

> My favourite was to branch to an odd address.
> 
> S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
> If an operator called at 2:00AM, I would know who caused 3 pair of socks.
>  
Unfortunately, IIRC the exception occurs after the branch is taken
so the PSW provides no ready indication of the point of error.

> Coding so that the assembler didn't flag it was needed but easy.
> Something like:
> 
>  BNE ERRLABEL-CSECT-1(BASEREG)
>  
I suppose that could be doctored so the PSW points near
either the point at which the error was detected or to
an error message.

I think of:
 BZNOERROR  (If RC==0.)
 DCX'00',C'You shouldn'ta done that.'
NOERROR  DS0X

-- gil

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

[somitcw]

My favourite was to branch to an odd address.

S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine.
If an operator called at 2:00AM, I would know who caused 3 pair of socks.

Coding so that the assembler didn't flag it was needed but easy.
Something like:

  BNE ERRLABEL-CSECT-1(BASEREG)

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

[Bill Hitefield]

An advantage of "DC X'00xx'" is it shows up in the "data at the PSW" in the 
abend summary.

Use a combination of both: 
DC X'00xx'
DC C'This is why the moon is blue.'

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 2:43 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, 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: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

[MELVYN MALTZ]

>>> I've never seen one, that I can remember, occur when executing data 

Way back when, I discovered this code in an IGZ (COBOL module)
BALR 14,15
DC CL6'PATCH'
etc.

According to IBM a return wasn't possible (it did), the DC is a nasty XC
This was done inside CICS and did sufficent damage to cause the CICS region to 
crash

I raised an APAR

Melvyn Maltz.

- Original Message - 
From: "Steve Thompson" 
To: 
Sent: Friday, May 12, 2017 3:07 AM
Subject: Re: Quick error termination of an assembler routine (Was: Performance 
of Decimal Floating Point Instruction)


> 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: 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)

[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)

[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: 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: 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: 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

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.