Re: Quadword constant

[Ed Jaffe]

On 4/19/2022 7:13 PM, Bob Raicer wrote:


Having the ability to assemble quadword aligned 128-bit items for
use with these instructions would be helpful.


We define quadword-aligned storage areas all the time. For example:

Field1  DC LQ'0'
Field2  DC LQ'0'

Of course, you need to specify the SECTALGN option.

We align all of our sections on cache-line boundaries, but technically 
you don't need more than quadword alignment to make LQ work.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Unexpected C code

[Thomas David Rivers]

I thought I'd bring an explanation
to what's going on here... 

Let's consider the following short
C example (just to have something
to compile):

foo()
{
   unsigned char ovfl;
   int ccpm, carrybit;

   ccpm = bar(); carrybit=bar2();

   ovfl = (ccpm & carrybit) != 0;

   blah(ovfl);

}

The functions bar(), bar2() and blah() are simply
external to this source (compilation unit in C terms)
and are there so the optimizer doesn't have a clue
about the possible values of the variables.

When I compile this for z/OS (31-bit mode) with 
the Dignus compiler, I get this code:

* ***  ccpm = bar(); carrybit=bar2();
 L 15,@lit_153_0 ; bar
@@gen_label0 DS0H 
 BALR  14,15
@@gen_label1 DS0H 
 L 1,@lit_153_1 ; bar2
 LR2,15
 LR15,1
@@gen_label2 DS0H 
 BALR  14,15
@@gen_label3 DS0H 
* ***   
* ***  ovfl = (ccpm & carrybit) != 0;
 NR2,15
 LPR   2,2
 LCR   2,2
 SRL   2,31(0)
* ***   
* ***  blah(ovfl);
 STC   2,80(0,13)  ; ovfl

which is similar to what's going on with GCC.
(The values happen to be in registers though.)

Now, how does this work?

  1) The two values are AND'd together
 (this is just a bit-wise/logical AND operation).

  2) The absolute value is taken (making the 2's
 complement sign bit a zero) with the LPR instruction.
 So we now have either a zero or non-zero (positive) value
 (or a special case which we'll see below.)

  3) The 2's complement of that is taken.  If the value
 is zero, the result is zero - otherwise the result
 is a negative value (and the sign-bit will be set)
 (or - another special case, which we'll see below.)

  4) The sign-bit is shifted right 31 times to result
 in either a X'' or X'0001' in the
 the final result.

So, what's going on in step #2 and why does that work? 
Especially if we consider that the result of the AND
sets the sign-bit?

Note that the only value from the AND that is interesting
is the situation where the AND results in the sign
bit being set, which presumably is cleared after the LPR.
Hence the confusion.

The "secret" is in the operation of the LPR and LCR
instructions for the 2's complement maximum negative 
value (X'8000'): These notes in the Principles of
Operation give a hint:

 LPR:
   An overflow condition occurs when the maximum negative
   number is complemented; the number remains unchanged.

 LCR:
   Zero and the maximum negative number remain unchanged.
   An overflow condition occurs when the maximum negative number
   is complemented.

So, as it happens, the LPR of the most negative number
(X'8000') produces X'8000' as its result (and
sets overflow, which is ignored.)  And the same thing
happens for the LCR instruction.

Going through the steps, when the result of the AND is
X'800', we get these values:

 LPR   ==>  X'8000'
 LCR   ==>  X'8000'
 SRL   ==>  X'0001'

And, for the X'000' value we have:

 LPR   ==>  X''
 LCR   ==>  X''
 SRL   ==>  X''

For any other situation where the AND operation
produces a negative value (the sign bit is set)
you'll have a value which isn't the most negative.
Thus some of the  lower-order bits (the non-sign-bit)
will be set.  If we have, for example, X'8xxx' then

 LPR   ==>  X'0xxx'
 LCR   ==>  X'8...'  (whatever the 2's complement of 0xxx is)
 SRL   ==>  X'0001'


Then we only need to consider the situation where
the result of the AND is non-zero but positive,
which is just an innocuous execution of the LPR
instruction, which does "nothing" and proceeds
as above.

It's a clever sequence of instructions to produce
a zero or non-zero value based on an input without
a branch.

- Dave Rivers -

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

Re: Quadword constant

[Bob Raicer]

A couple of more general instructions which require quadword aligned
storage operands and 128-bit values in even-odd pairs of 64-bit
GPRs:

Compare Double and Swap (CDSG)
Compare and Swap and Store (CSST)

Having the ability to assemble quadword aligned 128-bit items for
use with these instructions would be helpful.

Re: Unexpected C code

[Paul Gilmartin]

On Apr 19, 2022, at 17:57:23, Bernd Oppolzer wrote:
> 
> LPR: if the register contains 0x8000, IMO the result will be zero (and 
> overflow),
>  
I'd expect 0x8000, with overflow.

> so you're right ... this will lead to a zero result. IMO, the overflow will 
> be ignored.
>  
C programmers don't give a damn about overflows.  An unfortunate consequence,
probably, of hardware architectures which, unlike 360, lack unsigned
instructions, forcing compilers to generate signed instructions for
unsigned operations.

> N result zero: LPR ... LCR ... SRL puts x'00' in R1
> N result X'8000': LPR overflow (zero) ... LCR ... SRL puts x'00' in R1
> N result otherwise non-zero: LPR non-zero positive ... LCR negative ... SRL 
> puts x'01' in R1
>  
Oops!  I forgot that one non-negate value with a complement.

> Is bitwise AND defined for signed ints, which are negative?
>  
AND doesn't care -- the sign is just one of 32 bits.

> IMO, this is difficult; the result depends on the number format (2s or 1s 
> complement).
> So, maybe, this is not defined in the C language; bit operations are for 
> unsigned ints, normally.
>  
Does the C standard require that shifts are equivalent to
multiply/divide by powers of 2? That pretty much implies
2/s complement.  Hmmm.  Sift right truncates toward -∞,
not toward zero.

-- 
gil

Re: Unexpected C code

[Bernd Oppolzer]

Ok, I had to read the manual (PoOp), to see how LPR and LCR actually work
and the OP probably should post the definitions of ccpm and carrybit.

LPR: if the register contains 0x8000, IMO the result will be zero 
(and overflow),


so you're right ... this will lead to a zero result. IMO, the overflow 
will be ignored.


That is:

N result zero: LPR ... LCR ... SRL puts x'00' in R1
N result X'8000': LPR overflow (zero) ... LCR ... SRL puts x'00' in R1
N result otherwise non-zero: LPR non-zero positive ... LCR negative ... 
SRL puts x'01' in R1


For further analysis, we need the definitions of ccpm and carrybit.
Maybe the coding is indeed wrong, and maybe we can find some values for
ccpm and carrybit, where the N result is X'8000' ... if ccpm and 
carrybit

are signed ints, they must both be negative.

Is bitwise AND defined for signed ints, which are negative?
IMO, this is difficult; the result depends on the number format (2s or 
1s complement).
So, maybe, this is not defined in the C language; bit operations are for 
unsigned ints, normally.


Anyway:

unsigned int ccpm, carrybit;

ccpm = 0x8001u;
carrybit = 0x8002u;
bool overflow = (ccpm & carrybit) != 0;

this would fail, IMO, given the machine instructions below.

Kind regards

Bernd



Am 20.04.2022 um 01:24 schrieb Paul Gilmartin:

On Apr 19, 2022, at 16:59:54, Bernd Oppolzer  wrote:

The solution LPR ... LCR ... SRL looks OK for me.
LPR keeps a nonzero result, but with a positive sign,
  

What does this do for an operand of 0x8000?


LCR does the same, but enforces a negative sign,
  

So the sigh bit unconditionally 1.


and SRL moves the sign to the rightmost bit position.
  

Unconditionally 1

What am I miissing?


Am 19.04.2022 um 15:06 schrieb Ian Worthington:

Noticed today that the GCC C compiler generated an unexpected sequence of 
instructions for an AND and TEST:

 bool overflow = (ccpm & carrybit) != 0;// check if carry bit set
  109  .loc 1 189 0
  110 0078 5810B25C l%r1,604(%r11)# D.7949, ccpm
  111 007c 5410B26C n%r1,620(%r11)# D.7949, carrybit
  112 0080 1011 lpr%r1,%r1# tmp54, D.7949
  113 0082 1311 lcr%r1,%r1# tmp55, tmp54
  114 0084 8810001F srl%r1,31# tmp56,
  115 0088 4210B25B stc%r1,603(%r11)# tmp56, overflow

Re: Unexpected C code

[Paul Gilmartin]

On Apr 19, 2022, at 16:59:54, Bernd Oppolzer  wrote:
> 
> The solution LPR ... LCR ... SRL looks OK for me.
> LPR keeps a nonzero result, but with a positive sign,
>  
What does this do for an operand of 0x8000?

> LCR does the same, but enforces a negative sign,
>  
So the sigh bit unconditionally 1.

> and SRL moves the sign to the rightmost bit position.
>  
Unconditionally 1

What am I miissing?

> Am 19.04.2022 um 15:06 schrieb Ian Worthington:
>> Noticed today that the GCC C compiler generated an unexpected sequence of 
>> instructions for an AND and TEST:
>> 
>>  bool overflow = (ccpm & carrybit) != 0;// check if carry bit set
>>  109  .loc 1 189 0
>>  110 0078 5810B25C l%r1,604(%r11)# D.7949, ccpm
>>  111 007c 5410B26C n%r1,620(%r11)# D.7949, carrybit
>>  112 0080 1011 lpr%r1,%r1# tmp54, D.7949
>>  113 0082 1311 lcr%r1,%r1# tmp55, tmp54
>>  114 0084 8810001F srl%r1,31# tmp56,
>>  115 0088 4210B25B stc%r1,603(%r11)# tmp56, overflow

-- 
gil

Re: Unexpected C code

[Bernd Oppolzer]

Shorter:

you need a transformation:

every non zero 32 bit value -> x'01'
zero (32 bit) -> x'00'

LPR x,x ... LCR x,x ... SRL x,31

does it.

Kind regards

Bernd


Am 20.04.2022 um 00:59 schrieb Bernd Oppolzer:

ccpm and carrybit are probably ints or unsigned ints,
because of the L and N instructions, which read them.

so, the & (bitwise AND) operation yields a nonzero result, if there is 
a one bit
in the same bit position in both operands. This nonzero result must be 
transferred

to a one byte value X'01', using some clever register operations.

And: yes, IMO the coding here tries to avoid branches and compares.

The solution LPR ... LCR ... SRL looks OK for me.
LPR keeps a nonzero result, but with a positive sign,
LCR does the same, but enforces a negative sign,
and SRL moves the sign to the rightmost bit position.

In contrast, a zero result of the N operation would stay zero
throughout the LPR / LCR sequence, and the SRL would move
a zero bit in the rightmost bit position.

The final STC moves the rightmost 8 bits to the bool variable;
bool (no C standard type) is probably a typedef which means char.

I hope, I understood the coding correctly.

Kind regards

Bernd



Am 19.04.2022 um 15:06 schrieb Ian Worthington:
Noticed today that the GCC C compiler generated an unexpected 
sequence of instructions for an AND and TEST:


     bool overflow = (ccpm & carrybit) != 0;    // check if carry 
bit set

  109          .loc 1 189 0
  110 0078 5810B25C         l    %r1,604(%r11)    # D.7949, ccpm
  111 007c 5410B26C         n    %r1,620(%r11)    # D.7949, carrybit
  112 0080 1011             lpr    %r1,%r1    # tmp54, D.7949
  113 0082 1311             lcr    %r1,%r1    # tmp55, tmp54
  114 0084 8810001F         srl    %r1,31    # tmp56,
  115 0088 4210B25B         stc    %r1,603(%r11)    # tmp56, overflow

I can only guess this is to avoid the cost of a branch?  Or is there 
some other advantage in this?



Best wishes / Mejores deseos /  Meilleurs vœux

Ian ...

Re: Unexpected C code

[Bernd Oppolzer]

ccpm and carrybit are probably ints or unsigned ints,
because of the L and N instructions, which read them.

so, the & (bitwise AND) operation yields a nonzero result, if there is a 
one bit
in the same bit position in both operands. This nonzero result must be 
transferred

to a one byte value X'01', using some clever register operations.

And: yes, IMO the coding here tries to avoid branches and compares.

The solution LPR ... LCR ... SRL looks OK for me.
LPR keeps a nonzero result, but with a positive sign,
LCR does the same, but enforces a negative sign,
and SRL moves the sign to the rightmost bit position.

In contrast, a zero result of the N operation would stay zero
throughout the LPR / LCR sequence, and the SRL would move
a zero bit in the rightmost bit position.

The final STC moves the rightmost 8 bits to the bool variable;
bool (no C standard type) is probably a typedef which means char.

I hope, I understood the coding correctly.

Kind regards

Bernd



Am 19.04.2022 um 15:06 schrieb Ian Worthington:

Noticed today that the GCC C compiler generated an unexpected sequence of 
instructions for an AND and TEST:

     bool overflow = (ccpm & carrybit) != 0;    // check if carry bit set
  109          .loc 1 189 0
  110 0078 5810B25C         l    %r1,604(%r11)    # D.7949, ccpm
  111 007c 5410B26C         n    %r1,620(%r11)    # D.7949, carrybit
  112 0080 1011             lpr    %r1,%r1    # tmp54, D.7949
  113 0082 1311             lcr    %r1,%r1    # tmp55, tmp54
  114 0084 8810001F         srl    %r1,31    # tmp56,
  115 0088 4210B25B         stc    %r1,603(%r11)    # tmp56, overflow

I can only guess this is to avoid the cost of a branch?  Or is there some other 
advantage in this?


Best wishes / Mejores deseos /  Meilleurs vœux

Ian ...

ASM500Ws after Applying Z16 PTF to HLASM

[David Cole]

Has anyone else seen this?

Yesterday, I applied APAR PH39324 to my HLASM to bring in support for 
Z16 machine instructions. I then did a full reassembly of z/XDC (200+ 
assemblies), and suddenly, out of the blue, 14 of them reported 
ASMA500W errors on a DXD instruction that appears in ALL assemblies!


ASMA500W warns that the flagged statement requires a more restrictive 
boundary alignment that the csect in which it occurs.


In our assemblies, that is nonsense...
  - All my csects are assembled with the default doubleword alignment.
  - The default alignment for external dummy sections also is doubleword.
  - The DXD statement in question is defined as a 
"(length)X''" field which, of course, is only byte aligned.


Further, the DXD is emitted from a macro of mine, which generates the 
same way every time. That macro occurs in every one of my assemblies. 
So if the error happened once, it should have happened in EVERY 
assembly, not this "odd" selection of fourteen assemblies. They're 
structured no differently from all the other assemblies. They have no 
commonality that distinguishes then from the other 186. It's baffling.




We did some research and found APAR PH40885 which fixes "multiple 
problems" with ASMA500W messaging. That raised our hopes until we saw 
that it was already applied...


If you're using DXDs, have you seen this problem?

Dave Cole
President, ColeSoft
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)


PS: Here are the links to these APARs:
PH39324: 
https://www.ibm.com/support/pages/apar/PH39324 

PH40885: 
https://www.ibm.com/support/pages/apar/PH40885

Re: Where are the HLASM PDFs?

[David Cole]

Thanks John. I appreciate the tips.

Best, Dave






At 4/19/2022 05:53 AM, Jonathan Scott wrote:

Ref:  Your note of Tue, 19 Apr 2022 05:48:37 -0400
HLASM now has its own IBM Docs site:
  https://www.ibm.com/docs/en/hla-and-tf/1.6
There are links to current PDF documents from that site.
Note that documentation updates mentioned in APAR text may take
some days or weeks to appear in the IBM Docs online and PDF
formats.
Jonathan Scott, HLASM
IBM Hursley, UK

Re: Quadword constant

[Seymour J Metz]

VA takes three vector-register operands; it's VL that takes a storage operand. 

I never claimed that HLASM supported quadword integers, just that there were 
more than two instructions for quadword binary integer arithmetic.


From: IBM Mainframe Assembler List  on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Monday, April 18, 2022 8:48 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quadword constant

On Apr 18, 2022, at 16:48:23, Seymour J Metz wrote:
>
> VA foo,bar,baz,4
>
Please show how to define foo, bar, and baz with HLASM to specify
A dividend of fixed point 1E15.

Did you use a calculator?

> 
> From: Steve Smith
> Sent: Monday, April 18, 2022 11:41 AM
>
> HLASM has fixed BINARY constant type specifiers for H, F, FD.  The
> architecture has no support that I know of for 16-byte fixed binary, so why
> should the assembler?
>
The dividend for a Grande divide.

--
gil

Unexpected C code

[Ian Worthington]

Noticed today that the GCC C compiler generated an unexpected sequence of 
instructions for an AND and TEST:

     bool overflow = (ccpm & carrybit) != 0;    // check if carry bit set
 109          .loc 1 189 0
 110 0078 5810B25C         l    %r1,604(%r11)    # D.7949, ccpm
 111 007c 5410B26C         n    %r1,620(%r11)    # D.7949, carrybit
 112 0080 1011             lpr    %r1,%r1    # tmp54, D.7949
 113 0082 1311             lcr    %r1,%r1    # tmp55, tmp54
 114 0084 8810001F         srl    %r1,31    # tmp56,
 115 0088 4210B25B         stc    %r1,603(%r11)    # tmp56, overflow 

I can only guess this is to avoid the cost of a branch?  Or is there some other 
advantage in this?


Best wishes / Mejores deseos /  Meilleurs vœux

Ian ...

Re: Where are the HLASM PDFs?

[David Cole]

Thanks John. That's helpful.

Dave






At 4/19/2022 05:53 AM, Jonathan Scott wrote:

Ref:  Your note of Tue, 19 Apr 2022 05:48:37 -0400
HLASM now has its own IBM Docs site:
  https://www.ibm.com/docs/en/hla-and-tf/1.6
There are links to current PDF documents from that site.
Note that documentation updates mentioned in APAR text may take
some days or weeks to appear in the IBM Docs online and PDF
formats.
Jonathan Scott, HLASM
IBM Hursley, UK

Re: Where are the HLASM PDFs?

[Jonathan Scott]

Ref:  Your note of Tue, 19 Apr 2022 05:48:37 -0400

HLASM now has its own IBM Docs site:

  https://www.ibm.com/docs/en/hla-and-tf/1.6

There are links to current PDF documents from that site.

Note that documentation updates mentioned in APAR text may take
some days or weeks to appear in the IBM Docs online and PDF
formats.

Jonathan Scott, HLASM
IBM Hursley, UK

Where are the HLASM PDFs?

[David Cole]

I went looking for the PDFs for the High Level Assembler and was 
surprised at how hard they were to find...


I started at "z/OS Internet Library" 
(https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary?OpenDocument).


From there I selected "V2R3" from "Download books in PDF format". 
That took me to: 
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3Library?OpenDocument.


Then under "Elements and Features" there is a nice, pretty drop down 
for "+ HLASM" which lists the "-08" editions of the Reference and 
Programmer's Guide".


So far, so good.



BUT I'm looking for the new "-09" editions mentioned in APAR PH39324 
(https://www.ibm.com/support/pages/apar/PH39324).


So, I tried following the same process for z/OS "V2R4" and for "V2R5",
only to discover that there is no dropdown for "+ HLASM"! WTH?

So I have two questions:

1) Why are HLASM manuals available only if you know the secret of 
looking under z/OS V2R3?

2) Where are the latest and greatest -09 editions?

I'm asking for a friend.



David Cole
President, ColeSoft

dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)