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'8000' 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
Re: Unsigned 64-bit numbers
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. I believe what it intends to say is that the two's complement of the maximum negative number is not its algebraic negation.
Re: Unsigned 64-bit numbers
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
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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. 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. *
Re: Unsigned 64-bit numbers
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 ' = x'7F' = 127 decimal The maximum negative number is: B'1000 ' = x'80' = -128 decimal The two's complement of the maximum negative number: Step 1. Invert all of the bits: B'1 000 ' becomes B'0 111 ' Step 2. Add 1 to the result obtained in Step 1. B'0 111 ' + B'0 000 0001' B'1 000 ' 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).
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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-SHORTTO TS-LASTUPT 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. *
