Hi Paul,
For which of these instructions do you agree/disagree with HLASM's
behavior:
It's a good set, even better than mine :-)
The most important thing is "does the coding method make it more readable or
understandable within the context of the surrounding code ?"
If yes, all valid things must be allowed
Also remember that some of these parameters may be generated from macro
variables
To get specific:
I can only use the DeZhi mainframe which uses HLASM V5...apologies if V6
differs
A fine example is LHI 1,H2 and the next
Both of these assemble without error or warning (that's a big disagree)
Compare this with LHI 1,H5 and the next which generate a warning (do we need
the warning ?)
I used to present students with DC X'5C'. What is it ?
Is it binary 92, or +5 in decimal, or an asterisk ?
Interesting that all of your code, despite E and W messages assemble
correctly, except the last LHI which has the invalid 2AL1...doh
Melvyn Maltz.
----- Original Message -----
From: "Paul Gilmartin" <00000014e0e4a59b-dmarc-requ...@listserv.uga.edu>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Saturday, March 18, 2017 2:10 PM
Subject: Re: HLASM "Anomaly"
On 2017-03-17, at 17:40, MELVYN MALTZ wrote:
A pity our Emails crossed, with regards to the 2X'FF issue please read my
latest post
As for the Scon...I agree with you, you must submit a bug report for that
one
For which of these intructions do you agree/disagree with
HLASM's behavior:
START
H1 EQU -1
LHI 1,H1
LHI 1,-1
DC Y(H1)
DC Y(-1)
H2 EQU X'FFFFFFFF'
LHI 1,H2
LHI 1,X'FFFFFFFF'
DC Y(H2)
DC Y(X'FFFFFFFF')
H3 EQU X'FFFFFFFF'
LHI 1,H3
LHI 1,0+X'FFFFFFFF'
DC Y(H3)
DC Y(X'FFFFFFFF')
H4 EQU 65535
LHI 1,H4
LHI 1,65535
DC Y(H4)
DC Y(65535)
DC H'65535'
H5 EQU X'FFFF'
LHI 1,H5
LHI 1,0+X'FFFF'
DC Y(H5)
DC Y(X'FFFF')
TABLE DC 2AL1(*-TABLE)
LHI 1,2AL1(*-TABLE)
END
As I said earlier, I place considerable value on simplicity and
uniformity of syntax rules. I believe HLASM meets my expectations
well here.
As I also said, I'd welcome additional operators for forming expressions:
AND, OR, XOR, SLL, SLA, SRL, SRA, LT, LE, EQ, NE, GE, and GT.
And 64-bit arithmetic. I'd not like to see distinct 32-bit and 64-bit
exprssion types, Rather, all expressions should have 64-bit values.
But a switch to allow compatibility with existing ASMADATA format.
-- gil
