Unsigned 64-bit numbers

[Dave Clark]

I previously asked about 32-bit unsigned numbers and that opened
up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading
unsigned numbers into registers. But now I have need to load a 64-bit
unsigned value into a register and I don't see an LLGD instruction for
that.

In case it makes a difference, this value is a timestamp
(presumably from the store-clock instruction) but it is stored in an
8-byte file field. Now I need to take the file field and turn it into a
date and a time value. I have done this in REXX and COBOL but now I need
to do it in assembler. Actually, I have done something similar in
assembler but it was for the CICS ABSTIME value -- which is a 15-digit
packed number, not binary.

So, any hints? Thanks.

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331



*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Ngan, Robert (DXC Luxoft)]

This is just a LG, just like L for 32-bits. It doesn't matter whether it's signed or unsigned. There's nowhere for a sign to be extended.

Robert Ngan
DXC Luxoft

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/01/2022 11:42:56 AM:

> This is just a LG, just like L for 32-bits. It doesn't matter
> whether it's signed or unsigned. There's nowhere for a sign to be
extended.

Ah, I see. Got it. Thanks.

[Paul Gilmartin]

On Feb 1, 2022, at 09:38:58, Dave Clark wrote:
>
> I previously asked about 32-bit unsigned numbers and that opened
> up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading
> unsigned numbers into registers. But now I have need to load a 64-bit
> unsigned value into a register and I don't see an LLGD instruction for
> that.
>
> In case it makes a difference, this value is a timestamp
> (presumably from the store-clock instruction) but it is stored in an
> 8-byte file field. Now I need to take the file field and turn it into a
> date and a time value. I have done this in REXX and COBOL but now I need
> to do it in assembler. Actually, I have done something similar in
> assembler but it was for the CICS ABSTIME value -- which is a 15-digit
> packed number, not binary.
>
> So, any hints? Thanks.
>

You can do it wrong with STCKCONV. IBM has documented the flaw and
institutionalized it as a feature.

--
gil

[Farley, Peter x23353]

You may want to investigate the STCKCONV macro.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Tuesday, February 1, 2022 11:39 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Unsigned 64-bit numbers

I previously asked about 32-bit unsigned numbers and that opened up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading unsigned numbers into registers. But now I have need to load a 64-bit unsigned value into a register and I don't see an LLGD instruction for that.

In case it makes a difference, this value is a timestamp (presumably from the store-clock instruction) but it is stored in an 8-byte file field. Now I need to take the file field and turn it into a date and a time value. I have done this in REXX and COBOL but now I need to do it in assembler. Actually, I have done something similar in assembler but it was for the CICS ABSTIME value -- which is a 15-digit packed number, not binary.

So, any hints? Thanks.

Sincerely,

Dave Clark
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/01/2022 11:50:07 AM:

> You may want to investigate the STCKCONV macro.

Not available on z/VSE. Thanks.


Sincerely,

Dave Clark
--

[Farley, Peter x23353]

Perhaps the following helps?

LM 14,15,64-bit-time-storage-area
GETIME STANDARD,LOCAL,CLOCK=YES

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark

Sent: Tuesday, February 1, 2022 12:14 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit numbers

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/01/2022 11:50:07 AM:
> You may want to investigate the STCKCONV macro.

Not available on z/VSE. Thanks.

Sincerely,

Dave Clark
--

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

02/01/2022 12:29:45 PM:

> Perhaps the following helps?
>
> LM 14,15,64-bit-time-storage-area
> GETIME STANDARD,LOCAL,CLOCK=YES

Yes, that helped big time. Thank you very much. Your LM should
be for R0 and R1, though. I used the following code.

LM R0,R1,SHOWAREA+12 GET TIMESTAMP VALUE
GETIME STANDARD,LOCAL,CLOCK=YES CONVERT TO DATE/TIME
STCM R15,B'0011',CWORK+0 STORE DATE IN WORK AREA
STCM R15,B'1100',CWORK+2 USING CCYYMMDD FORMAT
STCM R14,B'1111',CWORK+4
STCM R1,B'1111',PWORK8 STORE TIME IN WORK AREA
UNPK CWORK+8(7),PWORK8(4) AND UNPACK IT
OI CWORK+14,X'F0' AND SET AS UNSIGNED
MVI CWORK+8,X'40' SEPARATE DATE AND TIME

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

[Farley, Peter x23353]

You're welcome. I'm lucky I even remembered the macro name, as I haven't worked on any VSE system since 1994. I did google current IBM VSE GETIME doc but misremembered input regs vs output regs between lookup and email writing. PEBKAC.

Not that they don't work as is, but I wonder if those STCM's and UNPK could be replaced by Vector Packed Decimal instructions (assuming you have hardware that supports them) and whether or not that approach would be more efficient in CPU time, but ATM I haven't any round tuits to cruise the PoOP for how.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Tuesday, February 1, 2022 4:12 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit numbers

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/01/2022 12:29:45 PM:
> Perhaps the following helps?
>
> LM 14,15,64-bit-time-storage-area
> GETIME STANDARD,LOCAL,CLOCK=YES

Yes, that helped big time. Thank you very much. Your LM should be for R0 and R1, though. I used the following code.

LM R0,R1,SHOWAREA+12 GET TIMESTAMP VALUE
GETIME STANDARD,LOCAL,CLOCK=YES CONVERT TO DATE/TIME
STCM R15,B'0011',CWORK+0 STORE DATE IN WORK AREA
STCM R15,B'1100',CWORK+2 USING CCYYMMDD FORMAT
STCM R14,B'1111',CWORK+4
STCM R1,B'1111',PWORK8 STORE TIME IN WORK AREA
UNPK CWORK+8(7),PWORK8(4) AND UNPACK IT
OI CWORK+14,X'F0' AND SET AS UNSIGNED
MVI CWORK+8,X'40' SEPARATE DATE AND TIME


Sincerely,

Dave Clark
--

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

02/01/2022 04:33:56 PM:

> Not that they don't work as is, but I wonder if those STCM's and
> UNPK could be replaced by Vector Packed Decimal instructions
> (assuming you have hardware that supports them)

Yes, GETIME returns the date in what I would call a strange format
-- but I understand it from a VSE point of view. The format is MMDDYYCC
-- if you can imagine it. ;-) When I coded that string of STCM
instructions I was certainly wishing for a better way. ;-) Our hosting
provider has us on an IBM 2818. I presume it supports those vector
instructions but I don't think they are in my PoPs manual (I'm currently
on a back-level, unsupported version of the operating system) for me to
figure out how to use them or if they will do what I need.

[Farley, Peter x23353]

Not on a 2818 (that is a z114 box if my google-fu is correct). Vector Packed Decimal is much more recent, z14 and up I think. The Vector Packed Decimal instructions were introduced in the 2017 PoOP, edition "-11" (12th edition).

There are Vector instructions available on a z114, just not the packed decimal variety.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Tuesday, February 1, 2022 4:41 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit numbers

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/01/2022 04:33:56 PM:
> Not that they don't work as is, but I wonder if those STCM's and UNPK
> could be replaced by Vector Packed Decimal instructions (assuming you
> have hardware that supports them)


Yes, GETIME returns the date in what I would call a strange format
-- but I understand it from a VSE point of view. The format is MMDDYYCC
-- if you can imagine it. ;-) When I coded that string of STCM
instructions I was certainly wishing for a better way. ;-) Our hosting
provider has us on an IBM 2818. I presume it supports those vector instructions but I don't think they are in my PoPs manual (I'm currently on a back-level, unsupported version of the operating system) for me to figure out how to use them or if they will do what I need.


Sincerely,

Dave Clark
--

[Dave Clark]

I realized I didn't need the fourth STCM so now the code is as
follows. It may be strange, but keep in mind that the output date content
of R14 and R15 is already in character format (MMDD YYCC) and the output
time content of R1 is already in packed format (0hhmmssC). I know
everything is just a string of bits, but I have it in my head that the
content of registers should always be a traditional binary number --
though I guess that isn't actually a rule. ;-)

LM R0,R1,SHOWAREA+12 GET TIMESTAMP VALUE
GETIME STANDARD,LOCAL,CLOCK=YES CONVERT TO DATE/TIME
STCM R15,B'0011',CWORK+0 STORE DATE IN WORK AREA
STCM R15,B'1100',CWORK+2 USING CCYYMMDD FORMAT
STCM R14,B'1111',CWORK+4

ST R1,PWORK8 STORE TIME IN WORK AREA

[Schmitt, Michael]

How did you do it in COBOL?

[Paul Gilmartin]

On Apr 28, 2022, at 15:20:16, Schmitt, Michael wrote:
> ...

> In case it makes a difference, this value is a timestamp (presumably from the store-clock instruction) but it is stored in an 8-byte file field. Now I need to take the file field and turn it into a date and a time value. I have done this in REXX and COBOL but now I need to do it in assembler. Actually, I have done something similar in assembler but it was for the CICS ABSTIME value -- which is a 15-digit packed number, not binary.
>

Do you know the values of CVTLDTO and CVTLSO at the time the timestamp was obtained?

--
gil

[Keith Moe]

No need for logical loading of an 8 byte number. There is no sign propagation, so a simple LG will do. The, the arithmetic would use ALG, SLG, etc.

Keith Moe
BMC Software (retired in 33 days)

[Gary Weinhold]

When loading 8 bytes into an 64-bit register, you needn't worry about
logical vs. arithmetic.  The sign only makes a difference if it's less
than a doubleword being loaded.  An LG will load it..

On 2022-04-28 5:20 p.m., Schmitt, Michael wrote:
> How did you do it in COBOL?
>
>

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: wein...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

[Charles Mills]

64 bits is 64 bits whether the high bit is a sign or part of the number. Loading 64 bits into a register loads 64 bits unaltered. The high bit becomes the high bit, 0 or 1.

As @Gary says, it only matters when the sending field is smaller than the receiving register. (And then only when the sign bit is 1; a negative number IOW.)

An LG of X'87654321' into a register gives you FFFFFFFF87654321. An LLG gives you 0000000087654321. If the source is X'01234567' then either instruction gives you the same result.

LH and LB also do sign extension. ICM and IC do not.

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold
Sent: Thursday, April 28, 2022 3:00 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit numbers

[Steve Smith]

Your mind is in the right place, but your text is not. You can LGF or LLGF
a fullword into a full register. LG loads a doubleword, whether you point
it at one or not. i.e. an LG Rx,=X'87654321' results in x'87654321garbage'.

There now exist LGH, LH, LLGH, LLH, LGB, LB, LLGC, and LLC for all
varieties and sizes you need, not to mention the corresponding immediate
versions.

sas

[Charles Mills]

Type first; read manual second :-(

At least my mind is in the right place. I must be getting old. It used to be in the gutter.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
Sent: Thursday, April 28, 2022 4:12 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit numbers

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
04/28/2022 05:20:16 PM:

> How did you do it in COBOL?

I guess my statement could be a bit misleading. What I meant was
that, in COBOL, I had taken this 8-byte file field (a binary timestamp)
and turned it into a date/time for display purposes. I did NOT mean that
I was able to treat this 8-byte field as a 64-bit unsigned binary number
in COBOL.

So, the way I did it in COBOL (and similarly in REXX) was to take
only the first 7 bytes and move them right-justified into an 8-byte binary
field (essentially, a divide by 256) for subsequent deconstruction into a
date/time display value. But I didn't want to do the same thing in
Assembler as I thought there was probably a better way. In Assembler, the
use of the GETIME macro was perfect for my needs.


MOVE LOW-VALUES TO EIGHT-BYTES
MOVE AMDSB-STMST(1:7) TO EIGHT-BYTES(2:7)
PERFORM P60-DECODE-TIMESTAMP THRU P65-EXIT-DECODE
MOVE NBR-DATE TO TS-LASTUPD
MOVE NBR-SHORT TO TS-LASTUPT

[Bob Raicer]

There has been a lot of discussion about the representation of
signed binary integers and the common operations of signed addition
and subtraction on these items.

Since the introduction of the S/360 and continuing on through all of
its largely compatible successors, the representation of signed
binary integers has remained the same.

For the sake of clarity I am going to paraphrase some of the text
found in the original S/360 Principles of Operation and the
z/Architecture Principles of Operation.

A negative number is represented by the two's complement of the
positive number of the same absolute value.  The two's complement of
a number is obtained by forming the one's complement of the number
(i.e., inverting all of the bits), adding a value of one in the
rightmost bit position, allowing a carry into the sign position, and
ignoring any carry out of the sign position.

The notation for signed binary integers has a number range in which,
for a given length (number of bits), the set of negative nonzero
numbers is one larger than the set of positive nonzero numbers. The
number "zero" is represented by all zero bits.  The two's complement
of zero is zero; there is no "negative zero".  The maximum positive
number consists of a sign bit of zero followed by all ones; the
maximum negative number (the negative number with the greatest
absolute value) consists of a sign bit of one followed by all zeros.

The two's complement of the maximum negative number cannot be
represented in the same number of bits.  When an operation, such as
Load Complement, attempts to produce the two's complement of the
maximum negative number, the result is the maximum negative number,
and a fixed-point overflow exception is recognized.  An overflow
does not result, however, when the maximum negative number is
complemented as an intermediate result but the final result is
within the representable range.  An example of this case is a
subtraction of the maximum negative number from -1.

A fixed-point overflow condition exists for signed binary addition
or subtraction when the carry out of the sign-bit position and the
carry out of the leftmost numeric bit position disagree. Detection
of an overflow does not affect the result produced by the operation.
In other words, signed addition and subtraction produce a
fixed-point overflow when the result is outside the range of
representation for signed binary integers.  Considering the various
Add and Subtract instructions which operate on 32-bit signed binary
integers, there is an overflow when the proper result would be
greater than or equal to +2**31 or less than -2**31.  The actual
result stored after an overflow differs from the proper result by
2**32.

The various Add and Subtract instructions which operate on Unsigned
binary integers of the same length (for example Add Logical)
produce the same results as the corresponding Signed instructions.
The instructions differ only in the interpretation of the result.
Add interprets the result as a signed binary integer and inspects
it for sign, magnitude, and overflow to set the condition code
accordingly and, for an overflow condition, potentially cause a
Fixed-Point Overflow Program Check interruption.  Add Logical
interprets the result as an unsigned binary integer and sets the
condition code according to whether the result is zero and whether
there was a carry out of the high order bit.  Such a carry is not
considered an overflow, and no program check interruption for
overflow can occur.

To illustrate the behavior of two's complement operations let's
use 8-bit values (the operations behave exactly the same way
for fixed point binary integers with a larger number of bits).

The maximum positive number is:
B'0111 1111' = x'7F' = 127 decimal

The maximum negative number is:
B'1000 0000' = x'80' = -128 decimal

The two's complement of the maximum negative number:

Step 1.  Invert all of the bits:
         B'1 000 0000' becomes B'0 111 1111'

Step 2.  Add 1 to the result obtained in Step 1.
            B'0 111 1111'
         +  B'0 000 0001'
            ------------
            B'1 000 0000'

         An overflow condition is recognized because a carry out of
         the leftmost numeric bit (the carry out of bit 1 into the
         sign bit is a 1) and the carry out of the sign bit (this
         carry out is a zero) are different.  In other words, the
         overflow condition is recognized because the proper result
         would be greater than or equal to +2**7 (decimal 128).
         The resultant number remains unchanged.  The resultant
         number differs from the proper result by 2**8 (2**8 =
         decimal 256; 256-128=128).

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

04/29/2022 02:08:22 PM:

> There has been a lot of discussion about the representation of
> signed binary integers and the common operations of signed addition
> and subtraction on these items.
>
> Since the introduction of the S/360 and continuing on through all of
> its largely compatible successors, the representation of signed
> binary integers has remained the same.
>
> For the sake of clarity I am going to paraphrase some of the text
> found in the original S/360 Principles of Operation and the
> z/Architecture Principles of Operation.

That's all well and good, but not germain to the issues being
discussed in this thread. Thanks.

[Paul Gilmartin]

On Apr 29, 2022, at 12:08:22, Bob Raicer wrote:
>
> For the sake of clarity I am going to paraphrase some of the text
> found in the original S/360 Principles of Operation and the
> z/Architecture Principles of Operation.
>

> ... The two's complement of

> a number is obtained by forming the one's complement of the number
> (i.e., inverting all of the bits), adding a value of one in the
> rightmost bit position, allowing a carry into the sign position, and
> ignoring any carry out of the sign position.

> ...

> The two's complement of the maximum negative number cannot be

> represented in the same number of bits. ...
>
Those two paragraphs contradict each other. Surely it is possible
to invert all the bits of the maximum negative number, add a value
of one in the rightmost bit position, and *ignore*any*carry* out
of the sign position; the definition of "two's complement" above.
That's exactly what the LCR instruction does.

I believe what it intends to say is that the two's complement of
the maximum negative number is not its algebraic negation.

--
gil

[Robin Vowels]

On 2022-04-30 05:10, Paul Gilmartin wrote:
> On Apr 29, 2022, at 12:08:22, Bob Raicer wrote:
>>
>> For the sake of clarity I am going to paraphrase some of the text
>> found in the original S/360 Principles of Operation and the
>> z/Architecture Principles of Operation.
>>
>> ... The two's complement of
>> a number is obtained by forming the one's complement of the number
>> (i.e., inverting all of the bits), adding a value of one in the
>> rightmost bit position, allowing a carry into the sign position, and
>> ignoring any carry out of the sign position.
>> ...
>> The two's complement of the maximum negative number cannot be
>> represented in the same number of bits. ...
>>
> Those two paragraphs contradict each other. Surely it is possible
> to invert all the bits of the maximum negative number, add a value
> of one in the rightmost bit position, and *ignore*any*carry* out
> of the sign position; the definition of "two's complement" above.
> That's exactly what the LCR instruction does.

No it doesn't. RTM. The value in the register is unchanged
in this case.

[Paul Gilmartin]

On Apr 29, 2022, at 14:07:58, Robin Vowels wrote:
>
> On 2022-04-30 05:10, Paul Gilmartin wrote:

>> ...

>> That's exactly what the LCR instruction does.
>
> No it doesn't. RTM. The value in the register is unchanged
> in this case.
>

"RTM" doesn't tell me. The hardware could do any of:
o Complement every bit and add 1.
o Detect x'80000000' and do nothing.
o Subtract from a hardwired 0.
o ...
The result is thee same in each case. The first is
probably the simplest and cheapest since the hardware
exists to handle the general case. It may be the
fastest unless it causes pipelining to reserve a
register. The PoOps specifies only the result of
each instruction; the implementation detail is moot.

Unless you have privileged knowledge of the hardware
implementation you are not entitled to advocate for
or against any of the possibilities with equivalent
outcomes.

--
gil

[Martin Ward]

On Apr 29, 2022, at 12:08:22, Bob Raicer wrote:
> The two's complement of the maximum negative number cannot be
> represented in the same number of bits. ...

I think you mean "the absolute value (or the positive value)

of the maximum negative number cannot be represented in

the same number of bits." The two's complement of
the maximum negative number is just the maximum negative number:
which can, of course, be represented.

On 2022-04-30 05:10, Paul Gilmartin wrote:

>> Surely it is possible
>> to invert all the bits of the maximum negative number, add a value
>> of one in the rightmost bit position, and *ignore*any*carry* out
>> of the sign position; the definition of "two's complement" above.

>> That's exactly what the LCR instruction does.
>
> No it doesn't. RTM. The value in the register is unchanged
> in this case.

If you do the calculation you will find that inverting all the bits
and adding one will leave the value in the register unchanged
when the value is the maximum negative number.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

[Bob Raicer]

--------- begin snippet (from Dave Clark)

That's all well and good, but not germain to the issues being
discussed in this thread.

--------- end snippet

No worries, Dave. My post was not intended to be a direct response
to you.

I'm also guessing you meant to use the word "germane" (but that's
not particularly relevant to "the issues being discussed in this
thread" either).

[Bob Raicer]

---------  begin snippet (from Paul Gilmartin)
I believe what it intends to say is that the two's complement of
the maximum negative number is not its algebraic negation.
---------  end snippet

I agree with you, Paul, about the "algebraic negation" part of your
reply.  However, as perceived by the programmer, the LCR instruction
does not ignore the carry out of the sign position.

I also agree with your point about "knowledge of the hardware
implementation".  What matters is the behavior of the implementation
as it relates to the outcome of the operation as stated in
Principles of Operation.

In general, there are many variations of machine implementations
(think of out of order execution as an example) but which ultimately
conform to the model as described in Principles of Operation.

Bottom line:  I agree with you.

[Paul Gilmartin]

On Apr 30, 2022, at 08:50:04, Bob Raicer wrote:
>
> --------- begin snippet (from Paul Gilmartin)
> I believe what it intends to say is that the two's complement of
> the maximum negative number is not its algebraic negation.
> --------- end snippet
>
> I agree with you, Paul, about the "algebraic negation" part of your
> reply. However, as perceived by the programmer, the LCR instruction
> does not ignore the carry out of the sign position.
>

Yes. The carry is heeded, but only in the setting of the CC.

The error persists in:
In: IBM z/Architecture
Principles of Operation
SA22-7832-12 Thirteenth Edition (September, 2019)
Page 7-4

I'm working on an RCF. Should I expect pushback?

--
gil

[Robin Vowels]

From: "Bob Raicer" <R...@RAICER.COM>
To: <ASSEMBL...@LISTSERV.UGA.EDU>
Sent: Saturday, April 30, 2022 4:08 AM

> There has been a lot of discussion about the representation of
> signed binary integers and the common operations of signed addition
> and subtraction on these items.

> Since the introduction of the S/360 and continuing on through all of
> its largely compatible successors, the representation of signed
> binary integers has remained the same.

That is because of the adoption of the convention that a negative
number is held in two's complement form.

In fact, the S/360 form of two's complement representation for negative
numbers has been in use since 1950 (and probably before).

> For the sake of clarity I am going to paraphrase some of the text
> found in the original S/360 Principles of Operation and the
z/Architecture Principles of Operation.

> A negative number is represented by the two's complement of the
> positive number of the same absolute value. The two's complement of
> a number is obtained by forming the one's complement of the number
> (i.e., inverting all of the bits), adding a value of one in the
> rightmost bit position, allowing a carry into the sign position, and
> ignoring any carry out of the sign position.

> The notation for signed binary integers has a number range in which,
> for a given length (number of bits), the set of negative nonzero
> numbers is one larger than the set of positive nonzero numbers. The
> number "zero" is represented by all zero bits. The two's complement
> of zero is zero; there is no "negative zero". The maximum positive
> number consists of a sign bit of zero followed by all ones; the
> maximum negative number (the negative number with the greatest
> absolute value) consists of a sign bit of one followed by all zeros.

> The two's complement of the maximum negative number cannot be
> represented in the same number of bits. When an operation, such as
> Load Complement, attempts to produce the two's complement of the
> maximum negative number, the result is the maximum negative number,
> and a fixed-point overflow exception is recognized. An overflow
> does not result,

An overflow does occur, because the result is too large to be stored
in a word. The CC is set to 3 (overflow) and the interrupt is taken
(if the relevant mask bit is set).

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

[Robin Vowels]

----- Original Message -----
From: "Paul Gilmartin" <00000014e0e4a59...@LISTSERV.UGA.EDU>
To: <ASSEMBL...@LISTSERV.UGA.EDU>

Sent: Saturday, April 30, 2022 6:34 AM
Subject: Re: Unsigned 64-bit numbers

> On Apr 29, 2022, at 14:07:58, Robin Vowels wrote:
>>
>> On 2022-04-30 05:10, Paul Gilmartin wrote:
>>> ...
>>> That's exactly what the LCR instruction does.
>>
>> No it doesn't. RTM. The value in the register is unchanged
>> in this case.
>>
> "RTM" doesn't tell me. The hardware could do any of:
> o Complement every bit and add 1.
> o Detect x'80000000' and do nothing.

RTM. The POP manual says:
"An overflow condition occurs when the maximum negative
"number is complemented; the number remains unchanged."

> o Subtract from a hardwired 0.

Did you know that to subtract from zero, the hardware complements the second
operand and adds 1, and then adds to zero?

RTM. LCR certainly does not do that.

> o ...
> The result is thee same in each case. The first is
> probably the simplest and cheapest since the hardware
> exists to handle the general case. It may be the
> fastest unless it causes pipelining to reserve a
> register. The PoOps specifies only the result of
> each instruction;

RTM. The POP specifies what the instruction does.
Carefully read, for example, what EDMK does.

> the implementation detail is moot.
>
> Unless you have privileged knowledge of the hardware
> implementation you are not entitled to advocate for
> or against any of the possibilities with equivalent
> outcomes.

RTM. It is clear what the instruction does.

Incidentally, I have been familiar with hardware implentations
of complementing for several decades.

[Robin Vowels]

From: "Martin Ward" <mar...@GKC.ORG.UK>
Sent: Saturday, April 30, 2022 7:27 PM

> On Apr 29, 2022, at 12:08:22, Bob Raicer wrote:
>> The two's complement of the maximum negative number cannot be
>> represented in the same number of bits. ...
>
> I think you mean "the absolute value (or the positive value)
> of the maximum negative number cannot be represented in
> the same number of bits." The two's complement of
> the maximum negative number is just the maximum negative number:
> which can, of course, be represented.

Um, the two's complement is not the correct representation of
the complement. RTM, which says that overflow occurs.

> On 2022-04-30 05:10, Paul Gilmartin wrote:
>>> Surely it is possible
>>> to invert all the bits of the maximum negative number, add a value
>>> of one in the rightmost bit position, and *ignore*any*carry* out
>>> of the sign position; the definition of "two's complement" above.
>>> That's exactly what the LCR instruction does.
>>
>> No it doesn't. RTM. The value in the register is unchanged
>> in this case.
>
> If you do the calculation you will find that inverting all the bits
> and adding one will leave the value in the register unchanged
> when the value is the maximum negative number.

I have been complementing values for several decades.

But you need to RTM. It says different.

"LNR
"The two's complement of the absolute value of the second operand
"is placed in the first operand location.
"The operation complements positive numbers;
"negative numbers REMAIN UNCHANGED. The
"number zero REMAINS UNCHANGED with positive sign." (emphasis added)

"LCR
"An overflow condition occurs when the maximum negative
"number is complemented; the number REMAINS UNCHANGED." (emphasis added)

[Robin Vowels]

From: "Paul Gilmartin" <00000014e0e4a59...@LISTSERV.UGA.EDU>
Sent: Sunday, May 01, 2022 1:11 AM

> On Apr 30, 2022, at 08:50:04, Bob Raicer wrote:
>>
>> --------- begin snippet (from Paul Gilmartin)
>> I believe what it intends to say is that the two's complement of
>> the maximum negative number is not its algebraic negation.
>> --------- end snippet
>>
>> I agree with you, Paul, about the "algebraic negation" part of your
>> reply. However, as perceived by the programmer, the LCR instruction
>> does not ignore the carry out of the sign position.
>>
> Yes. The carry is heeded, but only in the setting of the CC.

Incorrect. RTM. The carry is (also) heeded for raising the overflow condition.
"The overflow causes a program interruption when the fixed-point overflow mask
"is one."

>
> The error persists in:
> In: IBM z/Architecture
> Principles of Operation
> SA22-7832-12 Thirteenth Edition (September, 2019)
> Page 7-4
>
> I'm working on an RCF. Should I expect pushback?
>
> --
> gil

[Seymour J Metz]

Whoosh!

Complementing 80000000 yields 7FFFFFFF.

Adding 1 yields 80000000.

So leaving the register unchanged matches both what Paul claimed and what PoOps describes.




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

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Robin Vowels [rob...@DODO.COM.AU]
Sent: Sunday, May 1, 2022 3:30 AM
To: ASSEMBL...@LISTSERV.UGA.EDU

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirus&amp;data=05%7C01%7Csmetz3%40gmu.edu%7Ca8062f6c8f6a461173cc08da2b447113%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637869870205403630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=dIe8eYcwXhkRuSm9O2xx9QpETUzPKHvsHa6nQewHO84%3D&amp;reserved=0