× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Mark,

Many thanks for your detailed explanation. I must confess that I'd already
spotted that the generated code for each of the example ADDN(IS) operations
is identical - and I understand the reasons for this.

My question is: Given that QPRCRTPG is responsible for converting "the
symbolic representation of a machine interface (MI) program into an OPM
program object." - (i.e. from the IRP) - then surely its IRP syntax-checker
should flag /MXD as an invalid indicator/branch form for the ADDN op-code?

The fact that the program object contains identical code whether you specify
/POS, /HI, /MXD etc. is not what I find curious. IRP-wise, /MXD is not a
valid indicator/branch form for the ADDN op-code and I would have expected
QPRCRTPG to flag it as such - that's all.

Best wishes,

Richard

-----Original Message-----
From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx] On
Behalf Of Mark S. Waterbury
Sent: 30 April 2010 18:18
To: MI Programming on the AS400 / iSeries
Subject: Re: [MI400] QPROCT and QPRODT

Hi, Dennis and Richard:

Look at the binary (hex) instruction stream generated (on the left-hand
side of the assembly listing) and you will see something like this:

SEQ INST Offset Generated Code *... ... 1 ... ... 2 ... ... 3
... ... 4 ... ...
00001 DCL DD MYVAR PKD(1,0)
INIT(P'0');
00002 DCL DD INDICATOR CHAR(1);
00003 0001 000004 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/POS(INDICATOR);
0002
00004 0002 00000E 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/HI(INDICATOR);
0002
00005 0003 000018 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/MXD(INDICATOR);
0002
00006 0004 000022 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/NOR(INDICATOR);
0002
00007 0005 00002C 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/TR(INDICATOR);
0002
00008 0006 000036 1943 1000 0001 2001 ADDN(IS) MYVAR,1
/ZC(INDICATOR);
0002
00009 0007 000040 0260 PEND;

Note that these all generate exactly the same binary instructions ...
(which is why James alluded to these mnemonics as being "synonyms".)

It does not really matter which "mnemonic" you use, so long as the same
binary (hexadecimal) values are generated in the binary instruction
stream in the OPM creation template.

This is very much like IBM's mainframe assembler language, where you can
code:

BC mask,label

where "mask" is a 4-bit binary mask containing hex values 0 to F ... the
bits represent various conditions, e.g.

8 1000 = Equal to zero
4 0100 = Less than zero
2 0010 = Greater than zero
1 0001 = Overflow / Carry

CONDITION CODE SETTINGS:
0 00 = Equal (to zero)
1 01 = Low (< zero)
2 10 = High (> zero)
3 11 = Overflow / Carry / etc.

The bits in the "mask" correspond, left to right, to the four possible
values of the (two-bit binary) condition code.

The BRANCH ON CONDITION Instruction:

BC mask,label

The branch is successful whenever the condition code has a corresponding
mask bit of one. (The condition code remains unchanged.)

IBM mainframe assembler also supports the following "extended mnemonics":

B label Branch (always) == BC 15,label
NOP label Branch Never (No-op) == BC 0,label

After compare:

BH label Branch on High == BC 2,label
BL label Branch on Low == BC 4,label
BE label Branch on Equal == BC 8,label

After arithmetic:

BO label Branch on Overflow == BC 1,label
BP label Branch on Plus == BC 2,label
BM label Branch on Minus == BC 4,label
BZ label Branch on Zero == BC 8,label
BNP label Branch on Not Plus == BC 13,label
BNM label Branch on Not Minus == BC 11,label
BNE label Branch on Not Equal == BC 7,label

After "Test under mask":

BO label Branch if Ones == BC 1,label
BM label Branch if Mixed == BC 4,label
BZ label Branch if Zeroes == BC 8,label
BNO label Branch if Not Ones == BC 14,label

So, different mnemonics can all generate the same binary machine code.

In much the same way, QPRCRTPG assembles the MI source into a binary
instruction stream that is part of the OPM program creation template.
This is then used by the CRTPG MI instruction (within the QPRCRTPG API)
to create a program object from this "template." The OPM MI binary
instruction template is thus translated into the "real" hardware machine
instruction set for the hardware on which it is actually running
(originally IMPI CISC, now PowerPC RISC).

I hope this explanation helps?

All the best,

Mark S. Waterbury

Dennis Lovelady wrote:
You're probably missing nothing at all! I was just surprised that the
QPRCRTPG API doesn't flag /MXD, /HI, /NOR, /TR or /ZC as an invalid
branch/indicator keyword for the ADDN(IS) statement - that's all. I was
expecting a more rigorous syntax check from QPRCRTPG.

Based on the documentation provided by IBM, the valid branch/indicator
tests
for ADDN are POS, NEG, ZER and UNOR - correct?


Ah, I see where you're coming from now. I did not check the docs AFA what
indics are available from ADDN, or might have followed. I am inclined to
agree with you, but now I wonder: is the documentation faulty or is the
fault with QPRCRTPG? Or maybe neither: does the doc say that those are
the
valid flags after ADDN, or does it say that those are the ones that may be
affected? (See the subtle difference?)

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
I bought some powdered water, but I don't know what to add to it.





_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.



_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.