HLASM anomaly

[Melvyn Maltz]

Immediate operands won't accept a duplication factor...why not ?
Can't find a reason in the HLASM manual

Try these...
CFI R1,4X'FF'
CFI R1,X'FFFFFFFF'
CFI R1,-1
AHI R1,2X'FF'
AHI R1,X'FFFF'
AHI R1,-1

Melvyn Maltz

[Steve Smith]

That's just the way it is... i.e. there is no reason.

DC supports a whole bunch of stuff that immediate operands do not.
Sometimes, you just have to ORG *-2 (or 4), and DC it. Be careful with
f-word-aligned data!

e.g.:
CNOP 2,4
LLILF R15,*
ORG *-4
DC V(EXTRTN1)
BASSM R14,R15

AFAIK, you could use VL4 and skip the CNOP. Anyway, I don't think there's
any alternative to the above that doesn't use more storage or
instructions. Yet it's illegal ;-).

sas

On Wed, Feb 22, 2017 at 4:18 PM, Melvyn Maltz <zarf...@blueyonder.co.uk>
wrote:

--
sas

[Charles Mills]

Yeah, I whined on IBM-MAIN on Dec. 27 about not being able to use a relocatable address in LLILF. Same answer. It does not work because ... it does not work.

Charles

[Steve Thompson]

What does "immediate" mean to you?

In this case, it means immediately available within the
instruction itself.

Replication would then expand outside of the instruction and into
the instruction stream. That would then cause the next byte,
beyond the instruction, to be an OPCODE by instruction fetch (IF)
using the PSW's Instruction counter (IC).

When an instruction is fetched, the IC is advanced by the length
of the instruction -- which is based on the OP code (it defines
the length of the instruction).

Accordingly, there is nothing in the instruction to tell IF that
this instruction has a different length for updating the IC.

It would help to read the Principles of Operations manual for
more than just the instructions that you want to use.

Understanding how the machine actually works can keep you out of
trouble and make use of nuances at the same time.

Regards,
Steve Thompson

[Robin Vowels]

From: "Steve Thompson" <ste...@COPPER.NET>
Sent: Thursday, February 23, 2017 11:55 PM

> What does "immediate" mean to you?
>
> In this case, it means immediately available within the
> instruction itself.
>
> Replication would then expand outside of the instruction

Why? It is an Immediate instruction.

> and into the instruction stream. That would then cause the next byte,
> beyond the instruction, to be an OPCODE by instruction fetch (IF)
> using the PSW's Instruction counter (IC).
>
> When an instruction is fetched, the IC is advanced by the length
> of the instruction -- which is based on the OP code (it defines
> the length of the instruction).
>
> Accordingly, there is nothing in the instruction to tell IF that
> this instruction has a different length for updating the IC.
>
> It would help to read the Principles of Operations manual for
> more than just the instructions that you want to use.
>
> Understanding how the machine actually works can keep you out of
> trouble and make use of nuances at the same time.
>
> Regards,
> Steve Thompson

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Charles Mills]

> Replication would then expand outside of the instruction and into the instruction stream

Not necessarily. AHI R1,2X'FF', were it valid, would presumably generate exactly the same machine code as the valid AHI R1,X'FFFF'. One could, for example, write a series of macros (with names for example like AHI@) that would accept immediate operands with replication factors exactly as the OP wished, and assemble them into valid machine code.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Thompson
Sent: Thursday, February 23, 2017 4:56 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Steve Thompson]

Ah, I see why you all are having a problem with this.

And me, being an old ALC programmer, this is intuitively obvious.
In fact, there are several changes to HLASM that I disagreed
with, because they then caused programs I had written earlier to
start getting informative messages, where they didn't get them
before.

And when I first scanned the instructions, I was going quite
fast, and didn't catch the need for more than 1 byte of immediate
data.

So, you want the immediate area to be filled with a replication.
But that means that the assembler now must pay attention to the
replication value -- which it may not know until after the
instruction has to be generated, and ensure that it does not
exceed the immediate are of the instruction.

And the more such logic that is added to HLASM, the slower it
gets (my problem with this stuff).

I wish that IBM had made PLX or PL/AS a product for you
High-level Language programmers to work with...

Regards,
Steve Thompson

[Steve Thompson]

Yeah, I just answered another post on this. It explains my error
-- I was reading fast and thinking 1 byte immediates, not the
multi-byte of the newer instructions.

Still stuck in pre-z/Arch instructions. But, I am slowly using
the newer ones.

Regards,
Steve Thompson

[Paul Gilmartin]

On 2017-02-23, at 07:57, Steve Thompson wrote:

> Ah, I see why you all are having a problem with this.
>
> And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they didn't get them before.
>

Informative? Or Warning? Do you then disagree with warnings on
multiple base-displacement resolutions?

> So, you want the immediate area to be filled with a replication. But that means that the assembler now must pay attention to the replication value -- which it may not know until after the instruction has to be generated, and ensure that it does not exceed the immediate are of the instruction.
>

Any self-defining term ought to be acceptable as an immediate operand.
But can a self-defining term contain a replication factor?

On Wed, 22 Feb 2017 16:18:38 -0500, Melvyn Maltz wrote:

>Immediate operands won't accept a duplication factor...why not ?
>Can't find a reason in the HLASM manual
>
>Try these...

>AHI R1,2X'FF'
>AHI R1,X'FFFF'
>AHI R1,-1
>

How do you (and HLASM) feel about?:
AHI R1,X'00FFFF'

-- gil

[Steve Thompson]

On 02/23/2017 10:09 AM, Paul Gilmartin wrote:
> On 2017-02-23, at 07:57, Steve Thompson wrote:
>
>> Ah, I see why you all are having a problem with this.
>>
>> And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they didn't get them before.
>>
> Informative? Or Warning? Do you then disagree with warnings on
> multiple base-displacement resolutions?

I sometimes run into this, and can't figure out why the assembler
even issued the message. But when it happens I do verify that it
is using the correct base. This is actually a problem going back
to the "F" Assembler.

My gripe is, I removed a "," from the end of a line on purpose,
and because it is marked as continuing, I get a warning. That
didn't use to happen. This was done to test certain expansions of
Macros, or not pick up a debugging keyword (on the last line of
the continuation).

Yeah, I'm that old. And somewhere I still have the manuals for
that level of ASM so I can figure out certain things about
conditional assembly when I run into confusion because the
HLASM's manuals don't describe things as well as it used to be
done (and Dr. Ehrmann and I had discussed this at one point).

[Paul Gilmartin]

On 2017-02-23, at 10:31, Steve Thompson wrote:
>>>
>> Informative? Or Warning? Do you then disagree with warnings on
>> multiple base-displacement resolutions?
>
> I sometimes run into this, and can't figure out why the assembler even issued the message. But when it happens I do verify that it is using the correct base. This is actually a problem going back to the "F" Assembler.
>

It was a source of errors, difficult to analyze. Nowadays, the
best way to suppress this is with the "end" operand of the USING
instruction. In other cases, it may be necessary to:
PUSH USING
DROP
USING ...
...
POP USING

And the warning assumes 12-bit displacement. I believe it is not
issued for longer displacements. And with the advent of negative
displacements there is a need for a "begin" qualifier as well as
"end" on USING.

> My gripe is, I removed a "," from the end of a line on purpose, and because it is marked as continuing, I get a warning. That didn't use to happen. This was done to test certain expansions of Macros, or not pick up a debugging keyword (on the last line of the continuation).
>

Grrr. This shows that Assembler syntax was descriptive, not prescriptive.
Programmers used unspecified constructs that generated no error messages
or only warnings, and came to depend on them, and they had to become part
of the documented syntax. There was no a priori decision on whether a
continuation needed be indicated by a comma, or a mark in column 72,
or both.

>> On Wed, 22 Feb 2017 16:18:38 -0500, Melvyn Maltz wrote:
>>
>>> Immediate operands won't accept a duplication factor...why not ?
>>> Can't find a reason in the HLASM manual
>>>
>>> Try these...
>>> AHI R1,2X'FF'
>>> AHI R1,X'FFFF'
>>> AHI R1,-1
>>>
>> How do you (and HLASM) feel about?:
>> AHI R1,X'00FFFF'
>>

Earlier, I said self-defining term. I think that should have been
non-relocatable expression (and I don't think a constant with a
duplication factor is an expression).

What are the limits on the operand of AHI? What of:

A EQU -32768
DC Y(A)
AHI R1,A OK, I believe.

B EQU 32767
DC Y(B)
AHI R1,B OK, I believe.

c EQU 65535
DC Y(C)
AHI R1,C OK ???

Is the operand of AHI treated modulo 2^16, or ?

-- gil

[Steve Thompson]

On 02/23/2017 01:16 PM, Paul Gilmartin wrote:
> On 2017-02-23, at 10:31, Steve Thompson wrote:
>>>>
>>> Informative? Or Warning? Do you then disagree with warnings on
>>> multiple base-displacement resolutions?
>>
>> I sometimes run into this, and can't figure out why the assembler even issued the message. But when it happens I do verify that it is using the correct base. This is actually a problem going back to the "F" Assembler.
>>
> It was a source of errors, difficult to analyze. Nowadays, the
> best way to suppress this is with the "end" operand of the USING
> instruction. In other cases, it may be necessary to:
> PUSH USING
> DROP
> USING ...
> ...
> POP USING
>
> And the warning assumes 12-bit displacement. I believe it is not
> issued for longer displacements. And with the advent of negative
> displacements there is a need for a "begin" qualifier as well as
> "end" on USING.
>

I use it all the time and still get warning of multiple
base-displacement resolutions.

>> My gripe is, I removed a "," from the end of a line on purpose, and because it is marked as continuing, I get a warning. That didn't use to happen. This was done to test certain expansions of Macros, or not pick up a debugging keyword (on the last line of the continuation).
>>
> Grrr. This shows that Assembler syntax was descriptive, not prescriptive.
> Programmers used unspecified constructs that generated no error messages
> or only warnings, and came to depend on them, and they had to become part
> of the documented syntax. There was no a priori decision on whether a
> continuation needed be indicated by a comma, or a mark in column 72,
> or both.
>

Way back when, this was documented. If you needed to continue the
line, you had to have a non-blank character in 72. What you may
be continuing is a comment, but never-the-less, it required a
non-blank in cc72.

And as I recall, a non-macro statement for DOS could only be
continued for 3 lines. OS had a different limit.

As each "generation" of assembler came out, more limits were
lifted, more stuff supported. Finally we have HLASM.

[Paul Gilmartin]

On 2017-02-23, at 11:16, Paul Gilmartin wrote:
>
> What are the limits on the operand of AHI? What of:
>
> A EQU -32768
> DC Y(A)
> AHI R1,A OK, I believe.
>
> B EQU 32767
> DC Y(B)
> AHI R1,B OK, I believe.
>
> c EQU 65535
> DC Y(C)
> AHI R1,C OK ???
>
> Is the operand of AHI treated modulo 2^16, or ?
>

So, I RTFM and learned little:
• HLASM
• HLASM Language Reference
• Machine instruction statements
• Operand entries
• Immediate data
HLASM Language Reference
SC26-4940-06
...
Immediate data must be specified as absolute expressions whose range
of values depends on the machine instruction for which the data is
required. The immediate data is assembled into its binary representation.

"depends on the machine instruction". So I need to read the PoOps,
which says, for AHI:
... The second operand is two bytes in length and is treated
as a 16-bit signed binary integer. ...

Does "treated as" mean it's treated modulo size of field? Or ...?
That seems to be a HLASM question, not a zSeries question, so I guess
HLASM deserves an RCF; it shouldn't pass the responsibility (to PoOps?),
which offers no clarification. Are the limits of a halfword operand:
(-32768,32767)
(0,65535)
(-32768,65535)
Other (specify)?

Lore is not documentation.

-- gil

[Webster, Chris]

HLASM correctly refers to POPs since it is not describing each instruction. POPs uses 'treated as' for describing different operands. The term 'treated as' is used frequently with different instructions and appears to accurately describe the operand. How is it ambiguous? The limits of a 16-bit signed binary integer are well known aren't they? Not sure why you have examples of unsigned.

Sorry for getting defensive but I don't see a problem here,
...chris.

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: February-23-17 11:05 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

On 2017-02-23, at 11:16, Paul Gilmartin wrote:
>
> What are the limits on the operand of AHI? What of:
>
> A EQU -32768
> DC Y(A)
> AHI R1,A OK, I believe.
>
> B EQU 32767
> DC Y(B)
> AHI R1,B OK, I believe.
>
> c EQU 65535
> DC Y(C)
> AHI R1,C OK ???
>
> Is the operand of AHI treated modulo 2^16, or ?
>
So, I RTFM and learned little:

* HLASM
* HLASM Language Reference
* Machine instruction statements
* Operand entries
* Immediate data

[Paul Gilmartin]

On 2017-02-23, at 23:26, Webster, Chris wrote:

> HLASM correctly refers to POPs since it is not describing each instruction. POPs uses 'treated as' for describing different operands. The term 'treated as' is used frequently with different instructions and appears to accurately describe the operand. How is it ambiguous? The limits of a 16-bit signed binary integer are well known aren't they? Not sure why you have examples of unsigned.
>

Are you saying that I can infer (correctly?) that
AHI R1,X'FFFF'
results in an error because X'FFFF', taken as an expression, is not
in the range of 16-bit signed values?

But saying that an immediate datum must be an expression clarifies
a lot, because a data item containing a repetition factor is not
an expression.

-- gil

[John Dravnieks]

Fellow listers

I used to develop and maintain HLASM and there were lots of internal
discussions about how to handle items like 16 bit immediate opearnds.

One point is that internally the assembler has an expression processor for
instruction operands, and it has another one for DC operands - why it is
this way I do not know.
So sometimes there will be people expecting the DC type processing to be
done for the instruction operands, and getting confused/annoyed/bewildered
that it does not work that way.

Unless the assembler is redesigned to use just one expression processor,
there will always be differences in between instruction operands and DC
operands

And there are further complications - the instruction operand arithmetic
is done using 32 bit signed binary values and it is only at the end of the
process where the target operand properties are considered .
So by way of an example,16 bit immediate operands come in three flavours:

Arithmetic (for example, AHI) - the value is range checked to be
between -32768 and +32767. So AHI R1,-1 is acceptable, but AHI
R1,X'FFFF' is not

Bit string (for example, TMLL) - the value is range checked to be
between 0 and 65535. So TMLL R1,X'FFFF' is acceptable,
but TMLL R1,-1 is not

Branch operands - signed halfword count (for example, J LABEL) - the
value is an arithmetic value so it is range checked as for arithmetic
values. But the assembler will object if the user has coded J 10 as
it considers an absolute value a possible source of error as the value is
a count of halfwords (is the 10 intended as 10 bytes or 10 halfwords?)

Kind Regards

John R Dravnieks

[aldo....@csebo.it]

the two instructions

AHI 1,-1
AHI 1,X'FFFF'
-
if they are compiled produce coding

00000000 90EC D00C 0000000C 5 STM 14,12,12
(13)
00000004 A71A FFFF FFFFFFFF 6 AHI 1,-1

00000008 A71A FFFF 0000FFFF 7 AHI 1,X'FFFF'

the development in the compilation of any immediate operand depends on the
type of instruction in which it is used and how it is interpreted by the
instruction itself.

with reference to: principle of operation v2r2:

for example considering the move immediate instructions we have:

For MOVE (MVC), each operand is processed left to right. When the operands
overlap, the result is obtained as if the operands were processed one byte
at a time and each result byte were stored immediately after fetching the
necessary operand byte.
For MOVE (MVI, MVIY), the first operand is one byte in length, and only one
byte is stored.
For MOVE (MVGHI, MVHHI, and MVHI,), the second operand is treated as a
16-bit signed integer, signextended as necessary,
and placed in the first-operand location.
The first operand is two, four, or eight bytes for MVHHI, MVHI, and MVGHI,
respectively.

Aldo Crosio
tel: 051-4991812 /3488858416
fax: 051-6255762

CSE Consorzio Servizi Bancari
Società consortile a responsabilità limitata
Via Emilia n. 272
40068-San Lazzaro di Savena (BO)

Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute nel presente messaggio, corredato dei relativi allegati, sono strettamente riservate ed a uso esclusivo dei destinatari. Qualora Le fosse pervenuto per errore, La invitiamo ad eliminarlo immediatamente, dandocene gentilmente comunicazione. Grazie.
------------ *** ------------ *** ------------ *** ------------

[Paul Gilmartin]

On 2017-02-23, at 23:54, John Dravnieks wrote:
>
> Unless the assembler is redesigned to use just one expression processor,
> there will always be differences in between instruction operands and DC
> operands
>

I see little value in attempting to eliminate that difference
and much value in preserving the use of expressions as immediate
operands.

> And there are further complications - the instruction operand arithmetic
> is done using 32 bit signed binary values and it is only at the end of the
> process where the target operand properties are considered .
> So by way of an example,16 bit immediate operands come in three flavours:
>
> Arithmetic (for example, AHI) - the value is range checked to be
> between -32768 and +32767. So AHI R1,-1 is acceptable, but AHI
> R1,X'FFFF' is not
>

But I'd expect AHI R1,X'FFFF8000' to be acceptable (somewhat surprisingly).
And this would be a compatibility impediment to the (already unlikely)
extension of expressions to 64-bit arithmetic. Compatibility could be
preserved with an idiosyncratic rule that hexadecimal terms of 8 digits
are more are sign-extended to 64 bits; hexadecimal terms of 7 digits or
fewer are 0-extended.

On 2017-02-24, at 01:05, aldo....@CSEBO.IT wrote:
>
> the two instructions
>
> AHI 1,-1
> AHI 1,X'FFFF'
> -
> if they are compiled produce coding
>
> 00000000 90EC D00C 0000000C 5 STM 14,12,12
> (13)
> 00000004 A71A FFFF FFFFFFFF 6 AHI 1,-1
>
> 00000008 A71A FFFF 0000FFFF 7 AHI 1,X'FFFF'
>

You're contradicting John D. here. What about:

B EQU 65535
AHI R1,B * Should be invalid

A EQU X'FFFF'
AHI R1,A * ???


???
-- gil

[Steve Smith]

Have you not seen the many prior discussions of this excruciating topic?

HLASM's hex notation is a PIA! 2s-complement is great for computers, not
much so for humans. HLASM treats all hex constants as a 32-bit number, so
if you need to specify a negative number in hex, you have to spell out all
32 bits. Shorter hex constants are positive numbers. In addition, HLASM
treats hex constants sort of like strings sometimes, but mostly as numbers.

Signed half-words are generated from a number internally processed as 32
bits. 65535 is out-of-range, -1 is in range; regardless of the fact they
both truncate to X'FFFF'.

I'd bet a considerable sum that John Ehrman covers this in his book. Only
trouble is, he covers everything in that book, so it might take some time
to find. :-)

sas

--
sas

[Charles Mills]

Another way of looking at things is that X' serves two different roles in the assembler syntax. I became aware of this when I moved from a long career writing assembler to C++ as my primary language.

X' signifies (a.) that the constant that follows is in hexadecimal notation and (b.) a unit of storage, a byte.

Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). Consider the contrast with H' which is only a unit of storage. You can say DC H'23' but you would not expect to be able to code LHI 0,H'23'. So, similarly, you can code DC 2X'23' but not LHI 0,2X'23'

FWIW and OT, C/C++ separates the two functions. 0x23 represents only the quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly analogous to LHI) but if you want to define storage, you must explicitly state the unit of storage that you are defining: char foo = 0x23 or short foo = 0x23 (roughly equivalent to FOO DC X'23' and FOO DC H'35' respectively).

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
Sent: Saturday, February 25, 2017 7:06 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Steve Smith]

Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.)
and data types (B, X, C), which definitely adds to the confusion. C
(and its derivatives) makes more sense in this regard. OTOH, C does
have the interesting feature that the size of ints (and shorts and
longs) and pointers can vary. PL/I might have the best model, but I
haven't done any serious work with it in many years.

sas

[Ngan, Robert]

The ability to specify:

IIHF R00,H'12345,0'

to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would be useful.

Kludge for this is:

IIHF R00,12345*65536

which is ugly, while:

IIHL R00, 809041920

is even uglier!

Robert Ngan

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
Sent: Saturday, February 25, 2017 11:24
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

[Farley, Peter x23353]

Maybe a little less of a kludge using SETA arithmetic function SLL, but maybe not:

LCLA &IIHFARG
&IIHFARG SETA SLL(X'01', 16)+X'2345'
IIHF R00,&IIHFARG

Being able to code the SETA argument in the instruction would be nicer:

IIHF R00, SLL(X'01', 16)+X'2345'

Have not tried either of those in an actual assembly yet, just guessing here.

Peter

The ability to specify:

IIHF R00,H'12345,0'

Kludge for this is:

IIHF R00,12345*65536

which is ugly, while:

IIHL R00, 809041920

is even uglier!

Robert Ngan

sas

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Ngan, Robert]

I've tried using SETA functions directly as instruction operands, doesn't work.

[Steve Smith]

If possible, I'd arrange for LLIHH R00,12345, unless it leads to other
kludges. Otherwise, I'd code it as IIHF R00,12345*X'10000'. Your taste
may differ, but it's the least unpalatable to me.

sas

--
sas

[Melvyn Maltz]

To restate what I'm asking for...
Now that we have 2 and 4-byte immediate values it would make sense
to allow both duplication factor and explicit length for these
Currently the instructions below would fail
AHI 1,2X'FF'
CFI 1,XL4'FF'

Rather more contentious, I agree, is to imply an explicit length
of 1, 2, or 4 bytes to any immediate if there were no dup/explicit
already present

So, CFI 1,C'9' generates X'000000F9' (yuk)
But if it were forced to have an explicit length it would be
interpreted as CL4'9'=X'F9404040' which is what you might expect ???
Ok, I'll be shot down on that one, but I'll still submit it

Steve Thomas---What does "immediate" mean to you ?
It means a DC-type constant of any form that is only constrained by
the length of the immediate according to the instruction

Paul Gilmartin---How do you feel about AHI 1,X'00FFFF'
It exceeds the 2 byte limit and therefore invalid
If the explicit length were to be implemented, then it would
operate as XL2'00FFFF'=X'FFFF'
Yes, AHI 1,65535 is valid
In z390, AHI 1,X'00FFFF' is valid
In DeZhi, it generates but gives a warning

Yes, it's an HLASM problem, some immediates are logical, some are
algebraic, it doesn't really matter how the immediate is generated
provided you get the result you intended

John Ehrman---Immediates are not absolute
Sorry to disagree, 2X'FF' is just as absolute as X'FFFF'
I've always considered the result as definitive, not how we got there

>>>consider AHI 0,(N)X'F'
By that stage in the Assembly, it would be known (I hope) that
AHI takes a 2-byte immediate, if the parsing of the DC-type
immediate exceeded that, it's an error...no acrobatics needed

Chris Smith---Limits ot 16-bit signed...why examples of unsigned
Immediates can be logical or algebraic, compare CFI with CLFI
CLFI 1,-1 is a contradiction, but works !

John Dravnieks---
Read above stuff, AHI 1,X'FFFF' does assemble with a warning

Charles Mills---
Sorry, but an immediate operand is a unit of storage, the fact that
it's embedded into an instruction is irrelevant

I'm sure they'll be more flak flying, but I'll wait a few days for the smoke to clear before I annoy Sharuff :-)

Mel.

[Paul Gilmartin]

On 2017-02-28, at 14:02, Melvyn Maltz wrote:

> To restate what I'm asking for...
> Now that we have 2 and 4-byte immediate values it would make sense
> to allow both duplication factor and explicit length for these
> Currently the instructions below would fail
> AHI 1,2X'FF'
> CFI 1,XL4'FF'
>
> Rather more contentious, I agree, is to imply an explicit length
> of 1, 2, or 4 bytes to any immediate if there were no dup/explicit
> already present
>
> So, CFI 1,C'9' generates X'000000F9' (yuk)
> But if it were forced to have an explicit length it would be
> interpreted as CL4'9'=X'F9404040' which is what you might expect ???
> Ok, I'll be shot down on that one, but I'll still submit it
>

Bang!

C9 EQU C'9' Assigns x'000000F9 to the symbol.
Would you nave it otherwise?

Then, DC AL4(C9) generates x'000000F9'
Would you have it otherwise?

> Paul Gilmartin---How do you feel about AHI 1,X'00FFFF'

> ...

> Yes, AHI 1,65535 is valid
>

And here, I part company with HLASM, or at least with its Reference.
PoOps states that the operand of AHI is "taken as" a 16-bit
signed binary number. 65535 is not in that range. HLASM should
report an operand range error (best) or at least the Ref. should
clearly specify how out-of-range operands are treated.

HLASM would benefit for stricter operand checking, but also a
richer repertoire of arithmetic operators/functions.

-- gil

[John Dravnieks]

I did point out that the expression analyser is a 32 bit operand
processor - it does not know the origin or format of the original input,
it is just operating on the 32 bit values and only at the end is there
any consideration of the size of the target..
So at input, you might code any one of C'A', X'c1' or 193 - these will
all be the same as far as the expression analyser is concerned.

The possible target fields vary a lot - the sizes are 4, 8,12, 16, 20 and
32 bits and some are signed. The output values are range checked, but
remember that all we have is the final value from the analyser and the
target field attributes
So if you code AHI 1,65535 then HLASM will give you this

000000 A71A FFFF 0FFFF 2 ahi 1,65535
** ASMA320W Immediate field operand may have incorrect sign or magnitude

HLASM is warning you that this might not be correct - all it has is a 32
bit hex value X'0000FFFF' and a 16 bit signed target field - the range
check in this instance will be -32768 to +32767 so the assembler issues
the message.

(To me this is clearly an error, but I vaguely recall that there was some
resistance to making this message an error.)

This does tend to end up as a discussion of coding style

For example, you can code AHI 1,X'FFFF' and supress the warning
or AHI 1,-1 the object code for both will be the same - which
one is easier to understand reading the source?

Similarly you can code TMLL 1,x'00FF' or TMLL 1,1+2+4+8+16+32+64+128 -
exactly the same object code - again which is easier to understand from
the source?

Kind Regards

John Dravnieks

[Sharuff Morsa3]

SHARE starts next week. If those on the list that attend SHARE, they could
consider asking for this to be made a SHARE requirement.
Otherwise, consider a HLASM RFE. In both cases, you can put forward your
companies business justification for such changes.
Sharuff


IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
28/02/2017 21:02:09:

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Brent Longborough]

I really can't understand why we're making such an indigestible meal of
all this.

Take for example, AHI R1,2X'FF'. What does that even *mean*? If it
*means* AHI R1,-1, then write it like that, so that the unfortunate
programmer who has to maintain your code doesn't have to cast runes to
know what you mean!

In the context of DC/DS, 2X'FF' and X'FFFF' are completely different
things, except at the level of object code (which isn't what anyone is
looking for):

DC 2X'FF' defines an array of two 1-byte constants
DC X'FFFF' defines a single two-byte constant

The moral is this: say what you *mean*, not any old gibberish that gets
what you think you need into the object code.

[J R]

"The moral is this: say what you *mean*, not any old gibberish that gets what you think you need into the object code."

Hear, hear!

Sent from my iPhone

[Robert Netzlof]

Amen, brother. Hallelujah!

--
Bob Netzlof a/k/a Sweet Old Bob

[Charles Mills]

> > Take for example, AHI R1,2X'FF'. What does that even *mean*? If it

It is perhaps a silly example. But suppose R1 was to contain a pair of flag byte values. Suppose the flags were equated. Now it might make sense to code

LHI R1,2AL1(MYFLAG1)

Or something like that. Yes you can code the following but it is no great exemplar of coding clarity:

LHI R1,MYFLAG1*256+MYFLAG1

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Robert Netzlof
Sent: Wednesday, March 1, 2017 6:23 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Mark Boonie]

> It is perhaps a silly example. But suppose R1 was to contain a pair
> of flag byte values. Suppose the flags were equated. Now it might
> make sense to code
>
> LHI R1,2AL1(MYFLAG1)
>
> Or something like that. Yes you can code the following but it is no
> great exemplar of coding clarity:
>
> LHI R1,MYFLAG1*256+MYFLAG1

I probably wouldn't define them as two bytes of flags. Instead, I'd
define them as a single two-byte field of flags:

MYFLAGS DS XL2
FLAG1 EQU X'8000'
FLAG2 EQU X'4000'
Etc.

Setting bits is pretty clear:

LLILL R1,FLAG1+FLAG3+...

Plus, you don't have a field of flags being treated as signed, which most
likely isn't what was intended. Also, this way it would be clear that the
flags need to be contiguous so that they can be operated on as a unit, and
I don't have to worry that in a few years someone will rearrange the data
area and insert another field or two between the two bytes of flags.

- mb

[Charles Mills]

You can hypothesize objections to my hypothetical example. The example is
nonetheless instructive: there are situations where it would be clearer to
express the immediate operand of AHI or LHI as two bytes, not as a single
expression. Is it the most important shortcoming facing the mainframe? Of
course not.

Were I to rebut each of your hypothetical objections you could of course
rebut my rebuttals. I will only point out that often the coder does not have
control over how flags are defined: they are defined in some system or
"external" DSECT or similar.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Mark Boonie
Sent: Wednesday, March 1, 2017 7:53 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Mark Boonie]

> Were I to rebut each of your hypothetical objections you could of course
> rebut my rebuttals. I will only point out that often the coder does not
have
> control over how flags are defined: they are defined in some system or
> "external" DSECT or similar.

I concede that readily. My thinking was that if other approaches (mine
among them) were used for hopefully some non-trivial portion of the cases
you posited, perhaps the number of problematic cases remaining would
become small enough that they would be more of an anomaly than a recurring
irritation. :-)

- mb

[Charles Mills]

For sure! It's not a problem I lose sleep over -- perhaps because my primary
language is now C++, no longer assembler.

I don't recall ever thinking about the issue until it came up on this list.

I'm a "design elegance" guy. It would please me if there were a single
expression processor such that the syntax of immediate operands and of DC's
of the same length were the same.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Mark Boonie
Sent: Wednesday, March 1, 2017 8:51 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Paul Gilmartin]

On 2017-03-01, at 10:00, Charles Mills wrote:

> For sure! It's not a problem I lose sleep over -- perhaps because my primary
> language is now C++, no longer assembler.
>
> I don't recall ever thinking about the issue until it came up on this list.
>
> I'm a "design elegance" guy. It would please me if there were a single
> expression processor such that the syntax of immediate operands and of DC's
> of the same length were the same.
>

What lengths do you want? There are:
DC AL1(expression) 1 byte; unsigned
DC Y(expression) 2 bytes; signed
DC A(expression) 4 bytes; signed

Does HLASM issue any operand range warnings for any of LLI[HL][FHL]?
Is this implied by the PoOps "The condition code is unchanged." Or,
does HLASM simply ignore bits 0-15 of the immediate operand expression?
Is this documented?

-- gil

[Paul Gilmartin]

On 2017-03-01, at 00:03, John Dravnieks wrote:
>
> So if you code AHI 1,65535 then HLASM will give you this
>
> 000000 A71A FFFF 0FFFF 2 ahi 1,65535
> ** ASMA320W Immediate field operand may have incorrect sign or magnitude
>

Should the Reference specify the effect of using an out-of-range
operand? I can imagine two plausible interpretations:
o The rightmost bits matching the size of the instruction are used;
others are discarded (-1, as above).
o The algebraically nearest value is used (32767, in this case)

Or is it sufficient to rely on a blanket statement (if one exists)
that when warnings are ignored or suppressed the results are
unpredictable?

> (To me this is clearly an error, but I vaguely recall that there was some
> resistance to making this message an error.)
>

Heck, I even think division by zero should be an error. I know
it has a useful side effect, but that should be provided in a
more orderly fashion, by a BIF.

-- gil

[Paul Gilmartin]

On 2017-03-01, at 12:06, John Walker wrote:

> This sounds like a C person trying to get Assembler to conform to C coding expectations. Is that a correct perception?
>
Or, just expecting consistent behavior throughout HLASM.

X EQU C'x'
LHI R1,X

ought to have the same behavior as:

LHI R1,C'x'

then:

MVI TARGET,X

the same as

MVI TARGET,C'x'

and:
DC Y(X)

the same as

DC Y(C'x')

Remember John D. asserted that absolute expressions have no type.

Hmmm... What's the length attribute of a relocatable expression
containing additional paired relocatable terms? The length attribute
of the unpaired term, or the length attribute of the first term, or
nothing?

MVC A-B+C,'Whatever' ... where A pairs with B???

-- gil

[Steve Smith]

ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less
confusion if this was flagged as an *error*, which it is. It may sometimes
generate what the user wants, but the user didn't specify it correctly.

And the case where the assembler issues this for BR instructions is
egregiously wrong.

sas

--
sas

[Paul Gilmartin]

On 2017-03-01, at 13:24, Steve Smith wrote:

> ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less
> confusion if this was flagged as an *error*, which it is. It may sometimes
> generate what the user wants, but the user didn't specify it correctly.
>
> And the case where the assembler issues this for BR instructions is
> egregiously wrong.
>

Should/does HLASM require that the target of BR is within the owning CSECT?

Grrr... It's a shame that the length attribute of a CSECT isn't the
length of the CSECT. (Same for LOCTR?)

-- gil

[Charles Mills]

> Should/does HLASM require that the target of BR is within the owning
CSECT?

No and no. (Or should I say "No/no"?)

1. No, the target of a BR is quite often in another CSECT, and quite happily
so: L R15,=V(some_entry_point)/BR R15 or LM R14,R12,12(R13)/BR R14

2. No, it is not something the assembler has any way of knowing -- consider
the second example above. Unlike what we have been discussing, where the
assembler could "know" for example that 65535 is not a valid signed 16-bit
quantity, or "know" that OTOH X'FFFF' is a valid representation of a signed
16-bit -1. (By "can know" I mean it would be generally discernible for an
assembler of the general architecture of HLASM; I understand that internally
the expression processor is not quite in the right place at the right time
to figure this out, apparently.)

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, March 1, 2017 1:59 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Ngan, Robert]

I noticed the new COBOL compiler was generating:

MVHHI target,0
MVHHI target+2,48000

instead of:

MVC target,=F'48000'

and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal even when the top half of the value is non-zero. The assembler happily accepts:

MVHHI target+2,C'abcd'

truncating the leading 'ab', but I gave up since I could not determine how to consistently obtain the top half of the value when it is a general (resolvable at assembly) expression, except by doing:

MVHHI target,0
ORG *-2
DC A(expression)
ORG *-2
MVHHI target+2,expression

HLASM need logical shift operations to avoid requiring ORG/DC/ORG in the generate code.

Robert Ngan

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin

Sent: Wednesday, March 01, 2017 11:54
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Steve Smith]

Sorry for being unclear (not that it's *entirely* my fault), I meant BRANCH
RELATIVE.

sas

--
sas

[Paul Gilmartin]

On 2017-03-01, at 17:35, Ngan, Robert wrote:

> I noticed the new COBOL compiler was generating:
>
> MVHHI target,0
> MVHHI target+2,48000
>
> instead of:
>
> MVC target,=F'48000'
>
> and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal even when the top half of the value is non-zero. The assembler happily accepts:
>
> MVHHI target+2,C'abcd'
>

> truncating the leading 'ab', but I gave up since I could not determine how to consistently obtain the top half of the value when it is a general (resolvable at assembly) expression, ...
>
How about, with the miracle of integer arithmetic:

ABCD EQU c'abcd'

Then (best done in a macro):
DEN EQU 65536
M1.SYSNDX EQU ABCD-ABCD/DEN*DEN
M2.SYSNDX EQU (M1.SYSNDX+DEN)-(M1.SYSNDX+DEN)/DEN*DEN
MVHHI target,(ABCD-M2.SYSNDX)/DEN

I believe this is safe against oveflows, but I haven't proven it formally.

-- gil

[Ngan, Robert]

I was interested in the top half of the fullword, your equates give me the bottom half, which I do not need to do anything special for since HLASM truncates the value correctly when used directly on the MVHHI instruction.
However, I can use your code to strip the low order half off the value before dividing by 65536, which resolves my issue of the value being potentially "off by one" when a negative value is divided.

&M1 SETC '(&IMM-((&IMM)/65536)*65536)'
&M2 SETC '(&M1+65536)-(&M1+65536)/65536*65536'
&M3 SETC '(&IMM-&M2)/65536'
PUSH ACONTROL,PRINT,NOPRINT
PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL
ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages
POP PRINT,NOPRINT Print following instructions
MVHHI &TO+0,&M3 Set first half of fullword
MVHHI &TO+2,&IMM Set second half of fullword
POP ACONTROL,NOPRINT


The example "expression" I was messing with was actually SAVF4SAID_VALUE (i.e. C'F4SA') which when divided by 65536 gives C'F5' instead of C'F4'. However &M3 above generates the expected value.

Robert

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, March 01, 2017 20:40
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Paul Gilmartin]

On 2017-03-02, at 13:04, Ngan, Robert wrote:

> I was interested in the top half of the fullword, your equates give me the bottom half, which I do not need to do anything special for since HLASM truncates the value correctly when used directly on the MVHHI instruction.
>

Ah. I forgot a step. I'm glad you were able to suss out my plan and complete it.
I experimented in Rexx which I know better than HLASM. I wouldn't have thought of
your use of SETC. I wonder if more algebra might make it possible to avoid the
ASMA320W rather than suppressing it?

> However, I can use your code to strip the low order half off the value before dividing by 65536, which resolves my issue of the value being potentially "off by one" when a negative value is divided.
>
> &M1 SETC '(&IMM-((&IMM)/65536)*65536)'
> &M2 SETC '(&M1+65536)-(&M1+65536)/65536*65536'
> &M3 SETC '(&IMM-&M2)/65536'
> PUSH ACONTROL,PRINT,NOPRINT
> PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL
> ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages
> POP PRINT,NOPRINT Print following instructions
> MVHHI &TO+0,&M3 Set first half of fullword
> MVHHI &TO+2,&IMM Set second half of fullword
> POP ACONTROL,NOPRINT
>

The above complexity illustrates a sore need for additional operators in
expressions, such as AND, OR, XOR, and SLL, SLA, SRL, SRA. And even
LT, LE, EQ, NE, GE, GT; evaluating to 0 for false and 1 for true.

And 64-bit expressions. It's difficult to fully exploit a 64-bit architecture
using a 32-bit language.

-- gil

[Tony Harminc]

On 5 March 2017 at 13:03, Paul Gilmartin

<00000014e0e4a59...@listserv.uga.edu> wrote:

> And 64-bit expressions. It's difficult to fully exploit a 64-bit architecture using a 32-bit language.

Do you think 64-bit expressions are really what's needed, or should it
be infinite-precision expressions with the ability to
truncate/round/etc. results explicitly (and implicitly based on
operands)? I don't know the HLASM internals (thanks to OCO after
ASMH), but I imagine implementing infinite precision wouldn't be a
huge amount more work than hardcoding 64-bit. And certainly 128-bit is
coming from behind.

In passing, I'm a little surprised not to have heard from either of
the two commerical vendors of HLASM compatible cross-assemblers.

Tony H.

[Thomas David Rivers]

>
> In passing, I'm a little surprised not to have heard from either of
> the two commerical vendors of HLASM compatible cross-assemblers.
>
> Tony H.
>

Hi Tony,

We try to not get too involved with opinions.

I can say that mimic'ing the rather baroque methods
HLASM uses (likely for historical reasons) has always
been a lot of fun! We strive for absolute compatibility,
even when it is a surprise.

- Dave Rivers -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[Martin Truebner]

Tony,

>> ... to have heard from either of the two commerical vendors of
>> HLASM compatible cross-assemblers.

Now I have seen one. What is the other (is there one?) ?

Martin Trübner; everything around "PoOps of z/arch"

[Paul Gilmartin]

On 2017-03-05, at 14:40, Martin Truebner wrote:
>
>>> ... to have heard from either of the two commerical vendors of
>>> HLASM compatible cross-assemblers.
>
> Now I have seen one. What is the other (is there one?) ?
>

Dignus, Tachyon, (does MicroFocus have one?), and the non-commercial
z390.

A while back, I discovered that:
X EQU X'7FFFFFFF'
USING R2,X
LA R3,-X

Resolves to the equivalent of:
LA R3,2(,R2)

... where I believe it should say:
ASMA307E No active USING for operand 2

I surmise it improperly ignored an overflow as it tried to resolve.
This matters little for AMODE 24 or AMODE 31; much for AMODE 64.
Does this behavior persist? Cross-assemblers?

On 2017-03-05, at 12:31, Tony Harminc wrote:
>
> Do you think 64-bit expressions are really what's needed, or should it
> be infinite-precision expressions with the ability to
> truncate/round/etc. results explicitly (and implicitly based on
> operands)? I don't know the HLASM internals (thanks to OCO after
> ASMH), but I imagine implementing infinite precision wouldn't be a
> huge amount more work than hardcoding 64-bit. And certainly 128-bit is
> coming from behind.
>

Tread carefully to avoid either massive incompatibility with existing
code or serious compromise of current error checking.

The most plausible argument I have heard against 64-bit expressions is
incompatibility with ASMADATA format.

-- gil

[Thomas David Rivers]

Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:
>
> On 2017-03-05, at 14:40, Martin Truebner wrote:
> >
> >>> ... to have heard from either of the two commerical vendors of
> >>> HLASM compatible cross-assemblers.
> >
> > Now I have seen one. What is the other (is there one?) ?
> >
> Dignus, Tachyon, (does MicroFocus have one?), and the non-commercial
> z390.
>
> A while back, I discovered that:
> X EQU X'7FFFFFFF'
> USING R2,X
> LA R3,-X
>
> Resolves to the equivalent of:
> LA R3,2(,R2)
>
> ... where I believe it should say:
> ASMA307E No active USING for operand 2
>
> I surmise it improperly ignored an overflow as it tried to resolve.
> This matters little for AMODE 24 or AMODE 31; much for AMODE 64.
> Does this behavior persist? Cross-assemblers?
>

I fleshed this into an example to assemble:

R2 EQU 2
R3 EQU 3
FOO CSECT

X EQU X'7FFFFFFF'
USING R2,X
LA R3,-X

END

then I ran it thru HLASM v1.6 and got these messages:

7FFFFFFF 4 X EQU X'7FFFFFFF'
5 USING R2,X
** ASMA029E Incorrect register specification - X
** ASMA435I Record 5 in RIVERS.ASM.SOURCE(T) on volume: DAVE
00000000 0000 0000 00000000 6 LA R3,-X
** ASMA028E Invalid displacement
** ASMA435I Record 6 in RIVERS.ASM.SOURCE(T) on volume: DAVE
7 END


and I ran it thru the Dignus assembler and got these messages:

5 USING R2,X
** DASM029E Incorrect register specification
** DASM435I Record 5 in t2.asm
00000000 0000 0000 00000000 6 LA R3,-X
** DASM028E Invalid displacement
** DASM435I Record 6 in t2.asm
7 END


It seems HLASM and Dignus match.

But - I'm not sure that matches your description?

We have a substantial test suite for matching HLASM's USING vagaries;
so we should line-up very well. Just a few months ago we went thru
an audit of that.

[Pieter Wiid]

Your USING should be USING X,R2
Then, you get this with HLASM (z/OS 2.2)

00002 1 R2 EQU 2
00003 2 R3 EQU 3
000000 00000 00004 3 FOO CSECT

FFFFFF 4 X EQU X'7FFFFFFF'

R:2 FFFFFF 5 USING X,R2
000000 4130 2002 00001 6 LA R3,-X
7 END

[Thomas David Rivers]

Pieter Wiid <pw...@MWEB.CO.ZA> wrote:
>
> Your USING should be USING X,R2
> Then, you get this with HLASM (z/OS 2.2)
>
> 00002 1 R2 EQU 2
> 00003 2 R3 EQU 3
> 000000 00000 00004 3 FOO CSECT
> FFFFFF 4 X EQU X'7FFFFFFF'
> R:2 FFFFFF 5 USING X,R2
> 000000 4130 2002 00001 6 LA R3,-X
> 7 END
>

Ugh - yep - you're right.

And, that's a difference from us, we get this:

7FFFFFFF 4 X EQU X'7FFFFFFF'

7FFFFFFF 5 USING X,R2

00000000 0000 0000 00000000 6 LA R3,-X
** DASM028E Invalid displacement
** DASM435I Record 6 in t2.asm

that means, for this bright Monday morning - I'll have to enter a bug.

[Paul Gilmartin]

On 2017-03-06, at 05:43, Thomas David Rivers wrote:

> Pieter Wiid <pw...@MWEB.CO.ZA> wrote:
>>
>> Your USING should be USING X,R2
>>

Didn't I say earlier that I'm not an Assembler programmer?

>> Then, you get this with HLASM (z/OS 2.2)
>>
>> 00002 1 R2 EQU 2
>> 00003 2 R3 EQU 3
>> 000000 00000 00004 3 FOO CSECT
>> FFFFFF 4 X EQU X'7FFFFFFF'
>> R:2 FFFFFF 5 USING X,R2
>> 000000 4130 2002 00001 6 LA R3,-X
>> 7 END
> Ugh - yep - you're right.
> And, that's a difference from us, we get this:
>
> 7FFFFFFF 4 X EQU X'7FFFFFFF'
> 7FFFFFFF 5 USING X,R2
> 00000000 0000 0000 00000000 6 LA R3,-X
> ** DASM028E Invalid displacement
> ** DASM435I Record 6 in t2.asm
>
> that means, for this bright Monday morning - I'll have to enter a bug.
>

But here, I disagree with HLASM's behavior and believe DASM is doing
the right thing.

Which bug will you enter?

-- gil

[Thomas David Rivers]

> >
> > that means, for this bright Monday morning - I'll have to enter a bug.
> >
> But here, I disagree with HLASM's behavior and believe DASM is doing
> the right thing.
>
> Which bug will you enter?
>
> -- gil
>

The bug goes in with as "we aren't the same as HLASM".

It's surprising how far-reaching an incompatibility will be, so
when we strive to be compatible (i.e. as 'the same' as we can be.)

In some cases though, when we think "oh - this isn't right, even
though it's what HLASM does" we will be compatible and then have
an option to "do the reasonable thing" (or, if the incompatibility
is reported by a customer, we'll ask them if they want the option.)

One such option that has made it to the light of the general
public is our -fenhanced_equ option (that, among other things, allows
for further EQU processing during the lookahead phase than HLASM
supports.)

In this case, the default is to be 'the same' as HLASM.

Then, it's what we call a "your gun, your foot" situation. Since
we have given the option, if you enable it and your ASM code
doesn't assemble with HLASM, then it was your own foot you shot
with your own gun :-)

[Paul Gilmartin]

On 2017-03-06, at 07:04, Thomas David Rivers wrote:
>>>
>>> that means, for this bright Monday morning - I'll have to enter a bug.
>>>
>> But here, I disagree with HLASM's behavior and believe DASM is doing
>> the right thing.
>>
>> Which bug will you enter?
>

> The bug goes in with as "we aren't the same as HLASM".
>
> It's surprising how far-reaching an incompatibility will be, so
> when we strive to be compatible (i.e. as 'the same' as we can be.)
>

And if someone else reports the HLASM bug, and it gets fixed, you'll
have to change back.

HLASM is arguably incorrect for AMODE 24 and AMODE 31; unquestionably
wrong when the code is executed in AMODE 64.

Yes, I know HLASM is indifferent to the AMODE at execution.

But this is Calvinball, isn't it?

-- gil

[Jonathan Scott]

Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500

I noticed some time ago that HLASM fails to check properly for
overflow during USING calculations, which in my opinion is a bug
in HLASM. However, it's not just a matter of checking each
calculation for overflow, because intermediate calculations could
overflow (depending on the order in which they are done) even
when the final result is valid, and rejecting that with an
overflow indication could cause problems for existing programs.

By ignoring overflow and just letting calculations wrap round,
the current implementation tolerates all cases where the final
result is valid but fails to detect some cases which should have
been rejected.

I think that conceptually the result should be as if HLASM did
the intermediate calculations using a larger field (for example
using 63-bit signed arithmetic) then checked whether the final
result was in the valid range for a 31-bit signed offset, giving
an overflow indication if not. It may well be possible to
implement that rule without actually using a larger field.

Jonathan Scott
IBM Hursley, UK

> Pieter Wiid <pw...@MWEB.CO.ZA> wrote:
> >
> > Your USING should be USING X,R2

> > Then, you get this with HLASM (z/OS 2.2)
> >
> > 00002 1 R2 EQU 2
> > 00003 2 R3 EQU 3
> > 000000 00000 00004 3 FOO CSECT
> > FFFFFF 4 X EQU X'7FFFFFFF'
> > R:2 FFFFFF 5 USING X,R2
> > 000000 4130 2002 00001 6 LA R3,-X
> >
>

> Ugh - yep - you're right.
>
> And, that's a difference from us, we get this:
>
> 7FFFFFFF 4 X EQU X'7FFFFFFF'
> 7FFFFFFF 5 USING X,R2
> 00000000 0000 0000 00000000 6 LA R3,-X
> ** DASM028E Invalid displacement
> ** DASM435I Record 6 in t2.asm
>

> that means, for this bright Monday morning - I'll have to enter a bug.
>

[Charles Mills]

Hardware address arithmetic has always allowed overflow, right?

I could load X'FFFFFFF0' into R1, do L R2,32(,R1) and get the CVT, right?

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Monday, March 6, 2017 6:24 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Paul Gilmartin]

On 2017-03-06, at 09:18, Charles Mills wrote:

> Hardware address arithmetic has always allowed overflow, right?
>
> I could load X'FFFFFFF0' into R1, do L R2,32(,R1) and get the CVT, right?
>

Not in AMODE 64. The example I gave was (slightly adjusted) to load
X'7FFFFFFF' into R1. Then I might L R2,X'80000011'(,R1) which does get
the CVT in AMODE 24 or AMODE 31, but in AMODE 64 it accesses X'8000 0010,
in the z/OS demilitarized zone. That it works modulo some addressing
modes does not excuse its being algebraically wrong.

I suppose Jonathan (but not Dave) might argue that some user, somewnere
is relying on this behavior and will get a rude shock only when trying
AMODE 64.

I doubt that there is any case where recognizing overflow as an error
would prohibit an algebraically correct result.

[Charles Mills]

A detail, right? In AMODE 64 I could load X'FFFFFFFFFFFFFFF0' into R1, ...

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, March 6, 2017 8:44 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Paul Gilmartin]

On 2017-03-06, at 10:01, Charles Mills wrote:

> A detail, right? In AMODE 64 I could load X'FFFFFFFFFFFFFFF0' into R1, ...
>

You could, but that's not the example I gave. And you can't code
the USING. I'm disputing the operation not of the hardware but of
the USING instruction.

I don't know why a programmer, in AMODE 31, would access the CVT by:
USING X'7FFFFFF0',R1
L R2,X'80000020'

in order to access the CVT, which works in HLASM but not in DASM
(yesterday). Well, I suppose in a bizarre circumstance it saves
a precious base register.

-- gil

[Charles Mills]

My point was just that overflow-ignore is a feature of the hardware,
possibly explaining the origins of assembler overflow-ignore.

As a security guy I can think of a reason a bad guy might code it this way:
to defeat security scanning software that might be looking for load
base-displacements of X'0010'.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, March 6, 2017 9:11 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly

[Paul Gilmartin]

On 2017-03-02, at 13:04, Ngan, Robert wrote:

> However, I can use your code to strip the low order half off the value before dividing by 65536, which resolves my issue of the value being potentially "off by one" when a negative value is divided.

> ...

> The example "expression" I was messing with was actually SAVF4SAID_VALUE (i.e. C'F4SA') which when divided by 65536 gives C'F5' instead of C'F4'. However &M3 above generates the expected value.
>

I embellished your code to obviate the warning suppression:

MACRO
&L MVFI &TO,&IMM
.* Simulate Move Fullword Immediate with two MVHHI.
.* (Add PRINT option to taste. )
LCLC &M1,&M2,&M3
.* 16-bit signed remainder.
&M1 SETC '((&IMM)-(&IMM)/65536*65536)'
.* 16-big unsigned modulus.
&M2 SETC '(&M1+65536-(&M1+65536)/65536*65536)'
.* Top half shifted right arithmetic.
&M3 SETC '((&IMM)-&M2)/65536'
&L MVHHI &TO+0,&M3
.* Bottom half sign-extended.
MVHHI &TO+2,(&M2)-(&M2)/32768*65536
MEND
START
USING A,2
.* Test cases:

L0 MVFI A,C'F4SA'
L1 MVFI A,X'80007FFF'
L2 MVFI A,X'C0004000'
L3 MVFI A,X'4000C000'
L4 MVFI A,X'7FFF8000'

A DSECT
END

-- gil