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

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,

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

‎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

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.

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. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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:

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

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,

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