Re: Unsigned 64-bit numbers
Whoosh! Complementing 8000 yields 7FFF. Adding 1 yields 8000. 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 [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Sunday, May 1, 2022 3:30 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: 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'8000' 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. --- This email has been checked for viruses by Avast antivirus software. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=05%7C01%7Csmetz3%40gmu.edu%7Ca8062f6c8f6a461173cc08da2b447113%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637869870205403630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=dIe8eYcwXhkRuSm9O2xx9QpETUzPKHvsHa6nQewHO84%3Dreserved=0
Re: Unsigned 64-bit numbers
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Unsigned 64-bit numbers
From: "Martin Ward" 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) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Unsigned 64-bit numbers
- Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: 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'8000' 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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Unsigned 64-bit numbers
From: "Bob Raicer" To: 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). 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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Unsigned 64-bit numbers
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
Re: Unsigned 64-bit numbers
- 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.
Re: Unsigned 64-bit numbers
- 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).
Re: Unsigned 64-bit numbers
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
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. *
Re: Unsigned 64-bit numbers
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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Thursday, April 28, 2022 4:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers 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 On Thu, Apr 28, 2022 at 6:25 PM Charles Mills wrote: > 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 87654321. An LLG > gives you 87654321. 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 > >
Re: Unsigned 64-bit numbers
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 On Thu, Apr 28, 2022 at 6:25 PM Charles Mills wrote: > 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 87654321. An LLG > gives you 87654321. 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 > >
Re: Unsigned 64-bit numbers
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 87654321. An LLG gives you 87654321. 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold Sent: Thursday, April 28, 2022 3:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers 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: weinh...@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. -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Dave Clark > Sent: Tuesday, February 1, 2022 11:39 AM > To:ASSEMBLER-LIST@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.
Re: Unsigned 64-bit numbers
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: weinh...@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. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 11:39 AM To:ASSEMBLER-LIST@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.
Re: Unsigned 64-bit numbers
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) On Thursday, April 28, 2022, 02:20:56 PM PDT, Schmitt, Michael wrote: How did you do it in COBOL? -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 11:39 AM To: ASSEMBLER-LIST@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.
Re: Unsigned 64-bit numbers
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
Re: Unsigned 64-bit numbers
How did you do it in COBOL? -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 11:39 AM To: ASSEMBLER-LIST@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.
Re: Unsigned 64-bit numbers
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+12GET 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'',CWORK+4 ST R1,PWORK8STORE 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 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
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 On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 4:41 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers "IBM Mainframe Assembler List" 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 -- 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.
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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 -- 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
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 On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 4:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers "IBM Mainframe Assembler List" 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+12GET 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'',CWORK+4 STCM R1,B'',PWORK8STORE 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 -- 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.
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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+12GET 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'',CWORK+4 STCM R1,B'',PWORK8STORE 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 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
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 On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 12:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Unsigned 64-bit numbers "IBM Mainframe Assembler List" 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 -- 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.
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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 -- 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
You may want to investigate the STCKCONV macro. HTH Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 11:39 AM To: ASSEMBLER-LIST@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.
Re: Unsigned 64-bit numbers
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
Re: Unsigned 64-bit numbers
"IBM Mainframe Assembler List" 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. 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
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 -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 10:39 To: ASSEMBLER-LIST@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 -- 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. *
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 -- 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. *
