On 7/7/22 15:42:28, Jonathan Scott wrote:
The general rule is that HLASM programs which assemble without
error should always continue to generate compatible binary code, ...
Ouch!
A consequence of this "general rule" is that various HLASM
bugs, even some which result in behavior contrary to
Thanks for the explain and history Jonathan. Much appreciated.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Jonathan Scott
Sent: Thursday, July 7, 2022 5:42 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Type attribute changes in a new HLASM version
Caution!
The general rule is that HLASM programs which assemble without
error should always continue to generate compatible binary code,
preferably identical. In this case we failed to spot that
people could be using the type attribute to test for a
self-defining term and assume that it was positive as a
Hi Tony,
Thank you very much for bringing this issue to everyone's attention. I too
have a 'need to know when things like this are being changed'.
Our initial macro lib scans have found appx. 60 occurrences where type
attribute values of U or N are being evaluated and others where we
Those aren't the only options, and unless the program was going to be a real
CPU hog I would probably ask what code sequence will be the easiest to maintain.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List
Tony H writes:
> In the old version, the type attribute (T') of a macro operand of -1
> was U; in the new one it is, not unreasonably, N. This seems like a
> positive change, but it actually broke a macro of ours ...
This particular change was APAR PH10081 in March 2019, which
allowed decimal
We went from an old HLASM version at UI50739 to a new one at UI78656
(both these were delivered as part of z/OS ADCD bundled maintenance).
In the old version, the type attribute (T') of a macro operand of -1
was U; in the new one it is, not unreasonably, N. This seems like a
positive change, but
On Thu, 7 Jul 2022 08:19:42 -0700, Charles Mills wrote:
>
>> The CLI chain might be optimized by CLI first for the median value
>
>In fact, if there were enough I values, might one not effectively do a binary
>search? There is an amusing coding problem.
>
Why didn't I think of that!? And
For sure. I seem to recall that Ed Jaffe reported great success in using vector
instructions for character searches.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ngan, Robert (DXC Luxoft)
Sent: Thursday, July 7,
For values of "several" up to 16, you might want to look at VFAE.
I haven't had a chance to use it yet, but it's on my list of vector
instructions potentially useful for general coding.
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul
gil writes:
> Given several target characters, at what value of "several" is the
> break-even between TRT and a chain of CLI; BC?
Branching and looping are expensive, so for scanning more than
one byte, I would always use TRT for more than one target value
and in most cases I would use SRST for a
Model dependent and perhaps what-happens-to-be-in-cache dependent.
> The CLI chain might be optimized by CLI first for the median value
In fact, if there were enough I values, might one not effectively do a binary
search? There is an amusing coding problem.
Charles
-Original Message-
Given several target characters, at what value of "several" is the
break-even between TRT and a chain of CLI; BC?
(It's probably model-dependent.)
The CLI chain might be optimized by CLI first for the median value and
using the outcome to bypass half the remaining tests.
--
gil
13 matches
Mail list logo
