ASMA: Bogus "RI2 field value outside of range for 16-bit field" on NIHH instruction

[Fish-Git]

I am currently using:

      Revision: 7565b3e8ac73858f80f55e7068772558e89d70d9       Date: 3/24/2017 11:07:51 AM       Message: Fix font inconsistency in macro doc headings in func.odt and func.pdf

Yes, I know it's old, but I tried your latest and greatest version and it doesn't work for me. I experience too many problems with it. But the subject of this bug report is unrelated to the problems that I experience with your latest and greatest version, and is a bug which I suspect also still exists in your latest and greatest version.

Snippets from .listing file pertaining to bug:

ASMA Ver. 0.2.0         TXFT002  --  TBEGINC w/TXF disabled                                         25 Jan 2020 22:46:56  Page     1

...(snipped)...

00000300  00000000 00000000                         68 CTL0     DC    D'0'               Control Register 0
                              00000080  00000001    69 CR0TXF   EQU   X'0080'            CR0 bit 8: TXF Control

...(snipped)...

00002030  0000 0000                                108          NIHH   R0,X'FFFF'-CR0TXF
          ** [108] RI2 field value outside of range for 16-bit field ( -32768 - 32767 ): 65407

...(snipped)...

** ERRORS FOUND: 1 **

[108] RI2 field value outside of range for 16-bit field ( -32768 - 32767 ): 65407

The reported "outside of range" error is bogus. There is nothing in the Principles of Operation that states the second operand (I2) must be within a certain range.

I have not bothered to check to see whether the same bug exists for other immediate type instructions or not, but depending on how you designed your assembler I suspect it probably does.

[Fish-Git]

Addendum:

The terminology in the error messages itself may be providing a clue as to where your bug is:

... RI2 field ...

Operand-2 for this particular instruction (NIHH) is defined as an ordinary immediate value (I2), not a "relative" immediate value (RI2).

[s390guy]

Instruction formats are controlled by the related MSL file. As you are using an older version of ASMA, you may need to adjust the MSL file itself. I will need to check into this. The instruction field size does dictate how much information can be placed into field. The MSL file that you are using, clearly is treating this field as signed. I suspect you are right about this. But, it may already be fixed in the repository. Of course maybe not.

[s390guy]

What are the issues you are having with the latest and greatest??? If you are experiencing a Python exception, that is a known issue related to some changes to Python handling of the yield instruction. It started with Python 3.6. This I need to fix. If you are having other issues, I need to know what you are experiencing.

[s390guy]

I see what has happened. Instructions of this format sometimes treat the immediate operand as signed and some treat it as unsigned. NIHH treats it as unsigned. Unfortunately I missed this detail so all of these instructions treat the immediate field as signed. I will need to create a new format for the unsigned case and then update the instructions that need it with the new format. Some testing would not hurt either.

[Fish-Git]

What are the issues you are having with the latest and greatest???

If you are having other issues, I need to know what you are experiencing.

I do sincerely apologize to you Harold, but I really don't have time to report them at this time.

Sorry!   :(

I am currently way too busy actively using (relying on) my current ASMA installation to develop TXF (Transactional-Execution Facility) test cases for our current TXF project.

In order to report the problems I would have to "break" my current working installation, try to recreate the problems, report them all, and then put things back to the way they were so that I could then return to working on TXF test cases. That's unfortunately too much to ask at this time.   :(

Maybe later when things slow down a bit?  (*)

---

(*)  Please be sure to remind me about it later so I don't forget!

I fully understand your desire to fix bugs. I get that. I don't like bugs in my products either and would want to get them fixed right away too.

And please understand I'm not trying to blow you off (ignore you) either! That's the last thing I would want to do. I simply don't have the time right now, that's all. It's as simple as that.

So please be sure to remind me about it later in case I forget. Okay? Cool? Are we good?

[s390guy]

I believe that your issue with NIHH has been fixed. The latest commit to the MSL files fixed this issue, at least when I used it. It turns out that a number of similar instructions had a similar problem. For some of these instructions with this format, the immediate field is treated as signed and for some unsigned. I changed those that require unsigned operands is the related MSL files. Please email me directly if you need help integrating the changes into your environment.

[s390guy]

Let me know if the changes work for you.

[Fish-Git]

Let me know if the changes work for you.

Done!

I was pleasantly surprised that ALL (except 2) of my existing Hercules SATK/ASMA projects all built cleanly with no problems whatsoever. So overall I'm very happy with your newest latest and greatest version! Thank you!

The two that are failing are "INTERNAL ERROR" failures, one on the "PTLB" instruction and the other on the "PFPO" instruction, which I'm 100% confident you will quickly be able to find and fix.

[Fish-Git]

Since my original reported problem was with the NIHH instruction and since it appears to now have been fixed, I am closing this issue as resolved.

Thanks for the quick turnaround on this Harold. Much appreciated.