Re: QPROCT and QPRODT

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>]

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.
>
>
>