On 28/4/23 19:57, Robin Atwood wrote:
I need to know the length of the string, preferably without needing a new
parameter and altering a lot of code. At which
point I remembered that the XL/C compiler generates inline code for the
strlen(s) function. For those who are interested,
this is:
Why don't you just use TRT like the C/C++ compiler does for it's inline
string handling optimizations? In our experience those interruptible
instructions
may seem like syntactic sugar but they don't perform better. The only
noticeable difference was the introduction of the SIMD instructions.
LR R4,R2 copy string ptr
XR R0,R0 search for zero byte
SRST R0,R4 search
BO *-4 resume search
SLR R0,R2 get length
I assume some magic causes the SRST not to "recognize an access exception"
because normally the first register
(R0 here) contains an address limiting the search. Well, that was an
interesting exercise!
Thanks
On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood <abend...@gmail.com> wrote:
Thanks, Michael, that is the problem. The next page is available, but
the one after that isn't. Obviously, I had read the entry for TRE in
the PoOps but didn't take in the significance of the Access Exceptions
clause. (In fact, I still don't understand it:
"may or may not"!)
The problem is I maintain legacy C code originally developed with
SAS/C, which had a strupr(s) function. There is no length parameter,
so I was at a loss what to set R1+1 to for the TRE instruction.
I could search for the zero bytes using SRST but presumably that would
hit the same problem going off the end of a page.
Although, the SRST will wrap at top of storage - what does that imply?
I could invent the strnupr(s,n) function but that will involve many
code changes. ☹
@Ed Jaffe: thanks for the tip about the TEA, but where do you find it?
IPCS STATUS FAILDATA displays it but, in my dumps, PSA+90 and PDS+A8
both have zero in the address part.
Thanks to all who replied.
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Michael Stein
Sent: Thursday, April 27, 2023 10:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!
On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote:
I have had two of these during the course of two months, so it's
getting serious!
The abend happens in my implementation of a C strupr() function when
the TRE instruction is executed:
TST TRE R2,R1 fold string
R0 R1 R2 R3 PSW
00000000 0009C5EC 1AA748F8 7FFFFFFF 078D04008009BD14
from principles of operation TRE:
Access exceptions for the portion of the first operand to the right of
the last byte processed may or may not be recognized. For an operand
longer than 4K bytes, access exceptions are not recognized for locations
more than 4K bytes beyond the last byte processed.
Access exceptions for all 256 bytes of the second operand may be
recognized, even if not all bytes are used.
The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of
the next page?
R1 looks ok as the 2nd operand only needs to clear 256 bytes.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
