Inconsistency with NILL vs. NILF

[Steve Smith]

An issue I raised on IBM-MAIN led to discussing how to round an address to
a 16-byte (quad-word) boundary. The C example included the expression
<code>p &= -16;</code>. I suggested that the NILL & NILF instructions
could handle this, but probably wouldn't. So...

<quote>
Re specification of rounding mask: I do think -16, -8, etc. are an elegant
way to specify these, particularly as they correlate to 16-byte, 8-byte,
etc. boundaries. I sure wish they were usable with NILL and NILF.

Well, I decided to check before complaining... and (surprise!):

0000028C 0000 0000 00000000 481 NILL
R15,-4
** ASMA031E Invalid immediate or mask field

00000290 C0FB FFFF FFF0 00000000 482 NILF
R15,-16
483
*

Sigh.

</quote>

Given what J. Scott has said before, I guess this is yet another
consequence of how HLASM handles numbers.

--
sas

[Charles Mills]

I am going to *guess* that NILF takes a signed 31-bit integer, and thus -16 is valid; whereas NILL takes an unsigned 16-bit integer, and thus -4 is no good.

You could test my hypothesis with NILL R15,X'FFFC' . My guess is that it will be valid.

Charles

[Jonathan Scott]

Just remember that the mapping from numbers to immediate
fields has two steps.

In any numeric context where the assembler would accept an
expression, any value is first evaluated as a 31-bit signed
binary number. A simple number, regardless of whether in hex,
decimal, bit or character form, is just a special case of an
expression, and its representation does not affect the
interpretation of the resulting value.

The expression value is then assigned to the appropriate
instruction field, checking that the value lies within the
appropriate range, except that this check can be suppressed
using TYPECHECK(NOMAGNITUDE) for signed immediate values.

Immediate operands which are less than 4 bytes are either
unsigned or signed, depending on the instruction definition.
For logical operations such as NILL they are unsigned.
For arithmetic operations such as AHI they are signed.

Immediate operands which are 4 bytes are not currently checked
because unsigned 32-bit expressions are not supported so the
value is always expected to be signed 31-bit.

Assigning a negative value to an unsigned immediate operand
of less than 4 bytes is therefore an error. For a signed
immediate operand, it is an error to assign a value which
exceeds the maximum positive value, so for example LHI 0,-1
is valid but LHI 0,X'FFFF' is not because X'FFFF' is 65535.

Jonathan Scott, HLASM
IBM Hursley, UK

[Seymour J Metz]

Don't forget relocatable and complex relocatable expressions.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Jonathan Scott <jonatha...@VNET.IBM.COM>
Sent: Thursday, July 19, 2018 12:41 PM
To: ASSEMBL...@listserv.uga.edu
Subject: Re: Inconsistency with NILL vs. NILF

[Paul Gilmartin]

(Is there any way you can fix your mailer to not hard-wrap listing lines.
Enable Quoted-printable or something? It would be better to see:

> 0000028C 0000 0000 00000000 481 NILL R15,-4
> ** ASMA031E Invalid immediate or mask field
>
> 00000290 C0FB FFFF FFF0 00000000 482 NILF R15,-16

)

On 2018-07-19, at 10:26:00, Steve Smith wrote:
>
> Well, I decided to check before complaining... and (surprise!):
>
> 0000028C 0000 0000 00000000 481 NILL
> R15,-4
> ** ASMA031E Invalid immediate or mask field
>

What's it complaining about here? This catch-all message is
woefully ambiguous. It would be better to supply a message
explicitly stating the range limits being violated.

In days of yore such detail was hardly necessary. The hardware
is more complicated nowadays.

> 00000290 C0FB FFFF FFF0 00000000 482 NILF
> R15,-16
> 483

-- gil

[Paul Gilmartin]

On 2018-07-19, at 11:14:43, Seymour J Metz wrote:

> Don't forget relocatable and complex relocatable expressions.
>

I nope that no programmer would use a relocatable expression as
the operand of NI. Is that even supported?

-- gil

[Seymour J Metz]

That's one of the issues that format=flowed addresses. Of course, that only works if both ends support it, correctly.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Gilmartin <00000014e0e4a59...@listserv.uga.edu>
Sent: Thursday, July 19, 2018 1:25 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Inconsistency with NILL vs. NILF

[Seymour J Metz]

I hope that no programmer would use a non-relocatable expression as the first operand of an NI instruction.

The description I was commenting on seemed to refer to HLASM rules in general, not just to immediate operands.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Gilmartin <00000014e0e4a59...@listserv.uga.edu>
Sent: Thursday, July 19, 2018 1:27 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Inconsistency with NILL vs. NILF

[Steve Smith]

My post wasn't wrapped as it came back to me. I'm just using Gmail on
Firefox.

sas

[Tom Marchant]

On Thu, 19 Jul 2018 14:13:00 -0400, Steve Smith wrote:

>My post wasn't wrapped as it came back to me. I'm just using Gmail on
>Firefox.

That's funny. It is wrapped on the web interface, both for this list and for
IBM-Main, with a line break after both NILL and NILF, and before R15.

--
Tom Marchant

[Paul Gilmartin (BL)]

On Thu, Jul 19, 2018 at 02:13:00PM -0400, Steve Smith wrote:
> My post wasn't wrapped as it came back to me. I'm just using Gmail on
> Firefox.
>

Are you sure "came back to" made the round trip (π) and wasn't merely a
local echo generated by Gmail? Check the Received: headers.

> On Thu, Jul 19, 2018 at 1:25 PM, Paul Gilmartin wrote:
>
> > (Is there any way you can fix your mailer to not hard-wrap listing lines.
> >

... and a long line to see what wraps: Are you using an external editor rather than an editor integrated with your e-mail application? I know that emacs has issues; I don't know about the other common ones.
--
Sent from VirtualBox/BunsenLabs
-- gil

[Robin Vowels]

From: "Steve Smith" <sas...@GMAIL.COM>
Sent: Friday, July 20, 2018 2:26 AM

> An issue I raised on IBM-MAIN led to discussing how to round an address to
> a 16-byte (quad-word) boundary. The C example included the expression
> <code>p &= -16;</code>.

Won't this truncate, not round?
You'd need to add 15 and then "and".

> I suggested that the NILL & NILF instructions
> could handle this, but probably wouldn't. So...

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

[Steve Smith]

Yes, that was dropped from the original. I should have left it, or skipped
the backstory.

sas