On 6/7/24 11:53, Jonathan Scott wrote:
...
The SIGNED built-in function was
introduced as a partial workaround.
.
I had been unaware of the SIGNED BiF. I find the examples
in the Language Ref. inadequate:
SIGNED(10)has value '10'
SIGNED(-10) has value '-10'^M SETA 10
FYI:
A while back, I needed to test if a vector register contained all zeroes, but
could not figure out how without loading another register via VZERO and then
using VCEQGS but I didn't like that since it is really comparing two 64-bit
elements.
Finally, I found I could use VTM against another
On 6/7/24 11:53, Jonathan Scott wrote:
Compatibility is critically important.
.
Thanks for your reply. I'm hardly surprised that it
mentions "compatibility".
And I'm astonished that the behavior had been institutionalized
in macros etc. before it surfaced as a problem. And dismayed
that the
True; make that AL2 except where HW alignment is required.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Assembler List on behalf
of g...@altiboxmail.no
Sent: Friday,
Compatibility is critically important.
Even small changes can have unforeseen compatibility impacts.
When we allowed decimal self-defining terms to be negative, we
thought that was harmless, as self-defining terms have always
been allowed to be negative if expressed as binary, hexadecimal
or
On 6/7/24 10:23, Seymour J Metz wrote:
Metz's Law: You may be good at arithmetic but the assembler is better
.
Except for negative SETA values.
How did that happen and why wasn't it fixed promptly
or ever? Lexical entanglement?
--
gil
Note that an Y type without explicit length specified will have halfword
alignment, so there may by a pad byte between an entry string and the next
length field.
That will make it more complicated (but not impossible) to advance to the next
entry based on the length fields.
Gunnar
Metz's Law: You may be good at arithmetic but the assembler is better: let it
do the calculations.
LAR9,TEND
...
TABLE1 DS0F
DCY(TLEN)
DCY(L'E1)
E1 DCCL14'AA'
DCY(L'E2)
E2 DCCL15'BBB'
I don't think that HLASM ever aspired to be a high-level language, but it may
still be a high-level assembler.
I agree that the logical construct macros should be included.
Gunnar
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of David Clark
Sent: Friday, June 7, 2024
Note that
LAR9,TABLE1+2 ADDRESS OF BEGINNING OF TABLE
AHR9,TABLE1 CALC ADDR OF END OF TABLE
will not establish the end of table suitable for the BXLE instruction.
The table coded in the example below has a wrong total length (XL2'008F'),
>> As it is now, there's the IBM macros and there's other versions from
other sources,
>> which may not be consistent in syntax and implementation.
>> I've already had to rewrite a large assembler program to remove the
macros,
>> because they were licensed when I wrote it but then the license was
> However, that's not how IBM works.
Now isn't that just the truth?
We identified a missing essential feature in an IBM product recently, coded up
a solution, and sent it in a PMR to the owners.
You can guess their response.
IBM is like the man from Del Monte's evil twin.
Best wishes / Mejores
I agree that the macros should be in the base, but even without them HLASM has
features that, IMHO, justify the term high level.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM
My opinion is that the structured programming macros should be included with
HLASM, at no extra cost. For four reasons:
1. How can you call it High Level assembler without the macros?
2. The macro library is already a prerequisite for other IBM products, such as
IMS.
3. Having the macros part
The CIJ works for IF / ENDIF, as well as
STRTSRCH/EXITIF/ORELSE/ENDLOOP/ENDSRCH, but NOT for DOEXIT
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Friday, 07 June 2024 15:23
To:
Pieter Wiid writes:
> Found a bug in this implementation:
> ... 1686 DOEXIT CIJ,R15,NE,0
> ... 1696+ CIJ R15,0
> ** ASMA175S Delimiter error, expected comma -
This example appears to be simply due to using an old level of
the HLASM Toolkit Structured Programming Macro macro
On 6/7/2024 4:05 AM, Pieter Wiid wrote:
Found a bug in this implementation:
It looks to me like you simply do not have the necessary APAR/PTF applied.
What is your HLASM service level?
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
On Thu, 6 Jun 2024 at 23:55, Dan Greiner wrote:
> AFAIK, there is no reason to expect that the execution of a 64-bit
> instruction takes any longer than the execution of an equivalent 32-bit
> instruction. For example, the execution of the 32-bit ADD (AR) instruction
> should be comparable to
Found a bug in this implementation:
1676 DO ,
00160102
00441684+#@LB2 DC
0H 02-ASMMDOPR
1686
19 matches
Mail list logo
