Re: Shower thought
If you still have a copy of A22-6501, please send a scan to bitsavers. I could
give you a cite for the 7090, but that's a few years later.
I believe that there are machines with both logical and unsigned opcodes.
I know of no trademark issues, just local tradition.
Is it a branch, a jump or a transfer?
Is it an index register, a B-line, a B register or an X register?
Is it an exception, a fault, an interrupt or a trap?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, June 13, 2023 12:17 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Shower thought
On 6/13/23 09:42:56, Seymour J Metz wrote:
> In both cases they are treated numerically as a whole, For logical
> instructions the operands are treated as unsigned numbers. The distinvtion
> goes back to the vacuum tube ("valve" for you Brits) machine, well before
> S/360.
Citation needed.
<https://www.explainxkcd.com/wiki/index.php/285:_Wikipedian_Protester>
But it's jargon, exempt from requirement for explanation.
I would have chosen "Unsigned" but others might argue that
would refer to the magnitude, ignoring the sign bit. Etc.
And there may have been trademark entanglements with opcode
mnemonics.
--
gil
Re: Shower thought
PKB. You are confusing semantics with implementation. What I wrote is true in *all* case, and the text in PoOps is consistent with what I wrote, even for comparison. The description of processing from left to right *PRECISELY* describes an implementation of an unsigned binary comparison. And, no, "unstructured data" does not mean character string. The name is not the territory. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlcl...@winsupplyinc.com] Sent: Tuesday, June 13, 2023 12:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Some people love to argue the smallest point. "IBM Mainframe Assembler List" wrote on 06/13/2023 11:42:56 AM: > In both cases they are treated numerically as a whole, Not true in the majority of cases. The proof is that the logical comparison of unstructured data does not proceed for the full length of the data but ends as soon as an inequality is found. See the manual if you still want to argue the point. > For logical instructions the operands are treated as unsigned numbers. It is true that the manual states that. However, you left off the rest of the manual's answer. It states: Signed-binary-comparison operations are provided which treat the operands as signed binary integers, and logical-comparison operations are provided which treat the operands as unsigned binary integers or as unstructured data. Thus, it depends upon the instruction whether the data is treated, as a whole, as an unsigned binary integer or, in part, as unstructured data -- i.e., as a character string. Logical comparison of two operands is performed byte by byte, in a left-to-right sequence. The operands are equal when all their bytes are equal. When the operands are unequal, the comparison result is determined by a left-to-right comparison of corresponding bit positions in the first unequal pair of bytes: the zero bit in the first unequal pair of bits indicates the low operand, and the one bit the high operand. Since the remaining bit and byte positions do not change the comparison, it is not necessary to continue comparing unequal operands beyond the first unequal bit pair. 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: Shower thought
On 6/13/23 09:42:56, Seymour J Metz wrote:
In both cases they are treated numerically as a whole, For logical instructions the
operands are treated as unsigned numbers. The distinvtion goes back to the vacuum tube
("valve" for you Brits) machine, well before S/360.
Citation needed.
But it's jargon, exempt from requirement for explanation.
I would have chosen "Unsigned" but others might argue that
would refer to the magnitude, ignoring the sign bit. Etc.
And there may have been trademark entanglements with opcode
mnemonics.
--
gil
Re: Shower thought
Some people love to argue the smallest point. "IBM Mainframe Assembler List" wrote on 06/13/2023 11:42:56 AM: > In both cases they are treated numerically as a whole, Not true in the majority of cases. The proof is that the logical comparison of unstructured data does not proceed for the full length of the data but ends as soon as an inequality is found. See the manual if you still want to argue the point. > For logical instructions the operands are treated as unsigned numbers. It is true that the manual states that. However, you left off the rest of the manual's answer. It states: Signed-binary-comparison operations are provided which treat the operands as signed binary integers, and logical-comparison operations are provided which treat the operands as unsigned binary integers or as unstructured data. Thus, it depends upon the instruction whether the data is treated, as a whole, as an unsigned binary integer or, in part, as unstructured data -- i.e., as a character string. Logical comparison of two operands is performed byte by byte, in a left-to-right sequence. The operands are equal when all their bytes are equal. When the operands are unequal, the comparison result is determined by a left-to-right comparison of corresponding bit positions in the first unequal pair of bytes: the zero bit in the first unequal pair of bits indicates the low operand, and the one bit the high operand. Since the remaining bit and byte positions do not change the comparison, it is not necessary to continue comparing unequal operands beyond the first unequal bit pair. 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: Shower thought
In both cases they are treated numerically as a whole, For logical instructions
the operands are treated as unsigned numbers. The distinvtion goes back to the
vacuum tube ("valve" for you Brits) machine, well before S/360.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Dave Clark [dlcl...@winsupplyinc.com]
Sent: Tuesday, June 13, 2023 9:20 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Shower thought
"IBM Mainframe Assembler List" wrote on
06/12/2023 07:07:50 PM:
> -as opposed to what?
The operands are treated logically, bit-by-bit for their length,
as opposed to the full fields treated numerically as a whole.
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: Shower thought
Ok, thanks. That makes more sense! Now I grok.
Re: Shower thought
"IBM Mainframe Assembler List" wrote on 06/12/2023 07:07:50 PM: > -as opposed to what? The operands are treated logically, bit-by-bit for their length, as opposed to the full fields treated numerically as a whole. 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: Shower thought
Or packed decimal or floating point 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. From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: June 12, 2023 19:14 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought As opposed to a signed integer? For C, X'1000' compares greater than x'8000'. For CL, the reverse is true (a bit-for-bit comparison). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Monday, June 12, 2023 4:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Jonathan Scott wrote: >On trying to catch up with this thread I don't think I saw what >I would have considered the most likely reason for the term >"logical". >I assumed the word "logical" refers to Boolean logical values >(true and false, usually represented as 1 and 0) and hence to a >bit string. So logical comparisons simply treat the operand as >a bit string. Well, I thought I covered that with my first thought that it was a yes/no on the comparison. But even beyond that, I don't think that it makes sense to say that it treats it as a bit string-as opposed to what?
Re: Shower thought
As opposed to a signed integer? For C, X'1000' compares greater than x'8000'. For CL, the reverse is true (a bit-for-bit comparison). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Monday, June 12, 2023 4:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Jonathan Scott wrote: >On trying to catch up with this thread I don't think I saw what >I would have considered the most likely reason for the term >"logical". >I assumed the word "logical" refers to Boolean logical values >(true and false, usually represented as 1 and 0) and hence to a >bit string. So logical comparisons simply treat the operand as >a bit string. Well, I thought I covered that with my first thought that it was a yes/no on the comparison. But even beyond that, I don't think that it makes sense to say that it treats it as a bit string-as opposed to what?
Re: Shower thought
Jonathan Scott wrote: >On trying to catch up with this thread I don't think I saw what >I would have considered the most likely reason for the term >"logical". >I assumed the word "logical" refers to Boolean logical values >(true and false, usually represented as 1 and 0) and hence to a >bit string. So logical comparisons simply treat the operand as >a bit string. Well, I thought I covered that with my first thought that it was a yes/no on the comparison. But even beyond that, I don't think that it makes sense to say that it treats it as a bit string-as opposed to what?
Re: Shower thought
> I was thinking about assembler today in the shower, as one does, and the > L in instructions like CLC and CLI started bothering me: what's with the > "Logical"? On trying to catch up with this thread I don't think I saw what I would have considered the most likely reason for the term "logical". I assumed the word "logical" refers to Boolean logical values (true and false, usually represented as 1 and 0) and hence to a bit string. So logical comparisons simply treat the operand as a bit string. Jonathan Scott, HLASM IBM Hursley, UK
Re: Shower thought
I never used CDC or Univac but was taught ones & twos complement. I started at the end of life for S360. I vaguely remember someone explaining 3 state signed numbers but nothing specific. On Thursday, June 8, 2023 at 03:16:31 AM PDT, Seymour J Metz wrote: For those from the 1960s, what signed integers are depends on the machines that we started on: ones' complement suggests that you started with CDC or UNIVAC. To those who started on the S/360 it's rwos' complement and to some, it's sign-magnitude. How about decimal with a three-state sign? Name that machine. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jon Perryman [jperr...@pacbell.net] Sent: Wednesday, June 7, 2023 5:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Phil's question is why they chose the word "logical" for CL over 70 years ago. If you have logical comparisons, then all other comparisons must be illogical. To us, signed integer is ones complement with bit 0 being the sign but I suspect the hardware guys had a very different perspective. Same for packed decimal. Calling them compare illogical would be out of the question. Strange they didn't call them compare numeric. On Wednesday, June 7, 2023 at 10:22:30 AM PDT, Phil Smith III wrote: I was thinking about assembler today in the shower, as one does, and the L in instructions like CLC and CLI started bothering me: what's with the "Logical"? At first I thought "Hmm, I guessh it gives a logical answer-yes/no" but then realized that of course it doesn't: it's a real comparison, so CLI ,1 will give different CCs if is 0 or 2. So where does this "Logical" come from? I'm sure it's something obvious! ...phsiii P.S. The way I got to that is the usual twisted path: I was thinking about something I have to hunt down in Outlook, and that I can't remember all of one of the search terms (it's a model number), but that Outlook search matches what you specify, so if I know the model starts with XYZ, then I can search that and it will match XYZABC. Which led me to thinking about almost exactly 43 years ago, when my then-mentor (dead for about forty of those years, alas) taught me how to use EXecute with CLC to do this in assembler.
Re: Shower thought
For those from the 1960s, what signed integers are depends on the machines that we started on: ones' complement suggests that you started with CDC or UNIVAC. To those who started on the S/360 it's rwos' complement and to some, it's sign-magnitude. How about decimal with a three-state sign? Name that machine. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jon Perryman [jperr...@pacbell.net] Sent: Wednesday, June 7, 2023 5:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Phil's question is why they chose the word "logical" for CL over 70 years ago. If you have logical comparisons, then all other comparisons must be illogical. To us, signed integer is ones complement with bit 0 being the sign but I suspect the hardware guys had a very different perspective. Same for packed decimal. Calling them compare illogical would be out of the question. Strange they didn't call them compare numeric. On Wednesday, June 7, 2023 at 10:22:30 AM PDT, Phil Smith III wrote: I was thinking about assembler today in the shower, as one does, and the L in instructions like CLC and CLI started bothering me: what's with the "Logical"? At first I thought "Hmm, I guessh it gives a logical answer-yes/no" but then realized that of course it doesn't: it's a real comparison, so CLI ,1 will give different CCs if is 0 or 2. So where does this "Logical" come from? I'm sure it's something obvious! ...phsiii P.S. The way I got to that is the usual twisted path: I was thinking about something I have to hunt down in Outlook, and that I can't remember all of one of the search terms (it's a model number), but that Outlook search matches what you specify, so if I know the model starts with XYZ, then I can search that and it will match XYZABC. Which led me to thinking about almost exactly 43 years ago, when my then-mentor (dead for about forty of those years, alas) taught me how to use EXecute with CLC to do this in assembler.
Re: Shower thought
On 6/7/23 15:13:28, Charles Mills wrote: @Gil said it better than I. Thanks for the comple^Himent. I decided to search the Assembler Services Ref., for abuses of "hexadecimal". I got only as far as ABEND when I found the astonishing: ,REASON=reason code Specifies the reason code that the user wants to pass to subsequent recovery exits. The value range for the reason code is a 32-bit hexadecimal number or a 31-bit decimal number. This appears to say that X'87654321', a 32-bit hexadecimal number is supported, but the equivalent F'-2023406815' is not supported because it's a 32-bit, not a 31-bit decimal number. I'll submit an RCF. That begs for clarification. -- gil
Re: Shower thought
Fixed message formatting problem. Sorry, I falsely assumed everyone in this group knew how to convert signed binary.to display. I said ones complement but meant twos complement.B'0001' first bit is 0 (positive number) = + b'001' = +1B'' first bit is 1 (negative number) = - ( 2's complement (b'111') ) = - (b'000' +1) = -1 On Wednesday, June 7, 2023 at 02:29:32 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 6/7/23 15:15:40, Jon Perryman wrote: > ... To us, signed integer is ones complement> with bit 0 being the sign > Who "us"? -- gil
Re: Shower thought
Sorry, I falsely assumed everyone in this group knew how to convert signed binary.to display. I said ones complement but meant twos complement. B'0001' first bit is 0 (positive number) = + b'001' = +1B'' first bit is 1 (negative number) = - ( 2's complement (b'111') ) = - (b'000' +1) = -1 On Wednesday, June 7, 2023 at 02:29:32 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 6/7/23 15:15:40, Jon Perryman wrote: > ... To us, signed integer is ones complement> with bit 0 being the sign > Who "us"? -- gil
Re: Shower thought
If anyone hasn't seen it already, there's an eccentric video on YT by Jan Misali headlined "Every base is base 10". https://youtu.be/7OEF3JD-jYo It makes some good points and it's thought-provoking, as well as amusing :-) Roops On Wed, 7 Jun 2023, 21:44 Phil Smith III, wrote: > Well, that certainly sparked a nice, lively discussion! I knew it would be > something simple. Thanks. > > > > It's amazing how "hexadecimal" is defined differently to different folks. > I've tried to train myself not to use it because of this. With the > non-mainframe programmers I work with, if it means anything, it seems to > mean "binary", which is of course not necessarily what one means. >
Re: Shower thought
On 6/7/23 15:13:29, Seymour J Metz wrote: Given that the word length is a multiple of 4 bits, it is natural to group the data into groups of 4 bits, just as on 36 bit machines it was natural to group bits into groups of 3 and use octal notation. Add in the hexadecimal floating point and hex seems even more natural. The values 10 base 10 and 0A base 16 are the same, as is 1010 base 2, and which you use is purely a matter of convention and convenience. After DEC had for a decade marketed 18-, 36-, and 12-bit machines with instruction fields that divided naturally(?) into multiples of 3 and (mostly) 6-bit characters, octal became the cultural imperative for representing computer data. Then came the 16-bit PDP-11 with 8-bit characters. IIRC, the initial cumbersome accommodation was to represent each octet as 3 octal digits with values from 000 to 377. -- gil
Re: Shower thought
On 6/7/23 15:15:40, Jon Perryman wrote: ... To us, signed integer is ones complement> with bit 0 being the sign Who "us"? -- gil
Re: Shower thought
No, hexadecimal means hexadecimal. BASE64 is a format for represent code points from 0 to 255 using only ASCII characters. It is not a natural way to display data for a human reader. Displayable hexadecimal if a means to communicate with a human reader, just as displayable binary is. When PoOps uses the term hexadecimal values, it is refering to the numeric values represented by the digits, not the encoding used to print those digits. Wehn it say )A, that means 0A, not F0C1. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, June 7, 2023 4:03 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought "Hexadecimal" *means* character. Hexadecimal is a means of representing binary values with the *characters* 0-9 and A-F. The data is not hexadecimal; hexadecimal is convenient *character-based* way of representing it. And no, except for very short inputs, base64 is more compact than hex. Hex is always 2:1 relative to the input data; base64 is 4:3. 100 bytes in hex requires 200 bytes; 100 bytes in base64 requires 134. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, June 7, 2023 11:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought No, a hexadecimal comparison of 11 to AA gives AA higher; 11 and AA are not the same as C'11' and C'AA' BASE64 is almost certainly guarantied to be less compact.
Re: Shower thought
Phil's question is why they chose the word "logical" for CL over 70 years ago. If you have logical comparisons, then all other comparisons must be illogical. To us, signed integer is ones complement with bit 0 being the sign but I suspect the hardware guys had a very different perspective. Same for packed decimal. Calling them compare illogical would be out of the question. Strange they didn't call them compare numeric. On Wednesday, June 7, 2023 at 10:22:30 AM PDT, Phil Smith III wrote: I was thinking about assembler today in the shower, as one does, and the L in instructions like CLC and CLI started bothering me: what's with the "Logical"? At first I thought "Hmm, I guessh it gives a logical answer-yes/no" but then realized that of course it doesn't: it's a real comparison, so CLI ,1 will give different CCs if is 0 or 2. So where does this "Logical" come from? I'm sure it's something obvious! ...phsiii P.S. The way I got to that is the usual twisted path: I was thinking about something I have to hunt down in Outlook, and that I can't remember all of one of the search terms (it's a model number), but that Outlook search matches what you specify, so if I know the model starts with XYZ, then I can search that and it will match XYZABC. Which led me to thinking about almost exactly 43 years ago, when my then-mentor (dead for about forty of those years, alas) taught me how to use EXecute with CLC to do this in assembler.
Re: Shower thought
Given that the word length is a multiple of 4 bits, it is natural to group the data into groups of 4 bits, just as on 36 bit machines it was natural to group bits into groups of 3 and use octal notation. Add in the hexadecimal floating point and hex seems even more natural. The values 10 base 10 and 0A base 16 are the same, as is 1010 base 2, and which you use is purely a matter of convention and convenience. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, June 7, 2023 4:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Dave, no offense was intended. Yes, I totally understood your meaning. The mis-use of the term hexadecimal to mean vaguely "some value, possibly not a printable character" is a personal bugaboo of mine. The IBM doc does it: talking about specifying a word as containing "a hexadecimal value" when what they mean is a binary value. Specifying a hexadecimal value would mean specifying (character) 000A when what you meant was a binary value equal to decimal 10. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Wednesday, June 7, 2023 11:17 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought "IBM Mainframe Assembler List" wrote on 06/07/2023 02:02:58 PM: > No! Not a hexadecimal comparison. If it were, 11 would compare higher than > AA at least in an EBCDIC environment. You're too literal. I didn't say the comparison was on the hexadecimal *value*. What I mean by a hexadecimal comparison (and I've seen it used this way elsewhere) is that it is a bit-by-bit, left-to-right unsigned comparison. Proof that you understood that, but chose to object anyway, is that you *didn't* object to it being called a *character* comparison -- even though I explicitly said that first. After all, it is not truly a *character* comparison, either. It is a bit-by-bit, left-to-right unsigned comparison and I've seen that called both a character comparison and a hexadecimal comparison because it is shorter to say and it is generally understood correctly even if the actual wording is nonsensical. I'll not argue it further.
Re: Shower thought
@Gil said it better than I. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, June 7, 2023 1:34 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought In IBM doc, how many RCFs would it take do remove the superfluous and misleadingly apparently restrictive occurrences of hexadecimal from "any hexadecimal"? I suspect the intent was "any value that can be represented in Assembler as a hexadecimal constant", but "any" suffices.
Re: Shower thought
Well, that certainly sparked a nice, lively discussion! I knew it would be something simple. Thanks. It's amazing how "hexadecimal" is defined differently to different folks. I've tried to train myself not to use it because of this. With the non-mainframe programmers I work with, if it means anything, it seems to mean "binary", which is of course not necessarily what one means.
Re: Shower thought
On 6/7/23 13:59:39, Charles Mills wrote: Generally speaking, for most instructions and architectures, comparisons end at inequality, to unequal operands may compare faster than equal ones. An exception may be in DB operations where equi-joins can be faster than non-equi-joins. OK. Joins are not really comparisons. -- gil
Re: Shower thought
On 6/7/23 14:08:16, Charles Mills wrote: Dave, no offense was intended. Yes, I totally understood your meaning. The mis-use of the term hexadecimal to mean vaguely "some value, possibly not a printable character" is a personal bugaboo of mine. The IBM doc does it: talking about specifying a word as containing "a hexadecimal value" when what they mean is a binary value. Specifying a hexadecimal value would mean specifying (character) 000A when what you meant was a binary value equal to decimal 10. +1 In IBM doc, how many RCFs would it take do remove the superfluous and misleadingly apparently restrictive occurrences of hexadecimal from "any hexadecimal"? I suspect the intent was "any value that can be represented in Assembler as a hexadecimal constant", but "any" suffices. -- gil
Re: Shower thought
Dave, no offense was intended. Yes, I totally understood your meaning. The mis-use of the term hexadecimal to mean vaguely "some value, possibly not a printable character" is a personal bugaboo of mine. The IBM doc does it: talking about specifying a word as containing "a hexadecimal value" when what they mean is a binary value. Specifying a hexadecimal value would mean specifying (character) 000A when what you meant was a binary value equal to decimal 10. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Wednesday, June 7, 2023 11:17 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought "IBM Mainframe Assembler List" wrote on 06/07/2023 02:02:58 PM: > No! Not a hexadecimal comparison. If it were, 11 would compare higher than > AA at least in an EBCDIC environment. You're too literal. I didn't say the comparison was on the hexadecimal *value*. What I mean by a hexadecimal comparison (and I've seen it used this way elsewhere) is that it is a bit-by-bit, left-to-right unsigned comparison. Proof that you understood that, but chose to object anyway, is that you *didn't* object to it being called a *character* comparison -- even though I explicitly said that first. After all, it is not truly a *character* comparison, either. It is a bit-by-bit, left-to-right unsigned comparison and I've seen that called both a character comparison and a hexadecimal comparison because it is shorter to say and it is generally understood correctly even if the actual wording is nonsensical. I'll not argue it further.
Re: Shower thought
"Hexadecimal" *means* character. Hexadecimal is a means of representing binary values with the *characters* 0-9 and A-F. The data is not hexadecimal; hexadecimal is convenient *character-based* way of representing it. And no, except for very short inputs, base64 is more compact than hex. Hex is always 2:1 relative to the input data; base64 is 4:3. 100 bytes in hex requires 200 bytes; 100 bytes in base64 requires 134. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, June 7, 2023 11:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought No, a hexadecimal comparison of 11 to AA gives AA higher; 11 and AA are not the same as C'11' and C'AA' BASE64 is almost certainly guarantied to be less compact.
Re: Shower thought
Generally speaking, for most instructions and architectures, comparisons end at inequality, to unequal operands may compare faster than equal ones. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bob Flanders Sent: Wednesday, June 7, 2023 11:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought So does that mean if I compare two long byte vectors where the first byte is x'80' in the first operand, and the second is x'00' in the second operand, the operation is the fastest it can be? (It would take much longer if the two strings are completely equal?) -- Bob Flanders I Cor 15:1-4 >
Re: Shower thought
No, a hexadecimal comparison of 11 to AA gives AA higher; 11 and AA are not the same as C'11' and C'AA' BASE64 is almost certainly guarantied to be less compact. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, June 7, 2023 2:02 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought No! Not a hexadecimal comparison. If it were, 11 would compare higher than AA at least in an EBCDIC environment. Hexadecimal is not a format or type of data. It is a way of representing data that works well for communication among humans. What does some particular word in memory contain? One way of expressing the answer is 'ABCD'. Another way of expressing the answer is -1044200508. Inside the computer memory it is something more like 1101111011000100 but that is very clumsy for human communication. Probably the clearest way of expressing it to humans is in hex, C1C2C3C4. FWIW, an equally unambiguous and potentially more compact way is Base64, wcLDxA== Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Wednesday, June 7, 2023 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought "IBM Mainframe Assembler List" wrote on 06/07/2023 01:22:23 PM: > So where does this "Logical" come from? I'm sure it's something obvious! It is a character (hexadecimal) comparison vs. a numeric (binary/packed) comparison.
Re: Shower thought
"IBM Mainframe Assembler List" wrote on 06/07/2023 02:02:58 PM: > No! Not a hexadecimal comparison. If it were, 11 would compare higher than > AA at least in an EBCDIC environment. You're too literal. I didn't say the comparison was on the hexadecimal *value*. What I mean by a hexadecimal comparison (and I've seen it used this way elsewhere) is that it is a bit-by-bit, left-to-right unsigned comparison. Proof that you understood that, but chose to object anyway, is that you *didn't* object to it being called a *character* comparison -- even though I explicitly said that first. After all, it is not truly a *character* comparison, either. It is a bit-by-bit, left-to-right unsigned comparison and I've seen that called both a character comparison and a hexadecimal comparison because it is shorter to say and it is generally understood correctly even if the actual wording is nonsensical. I'll not argue it further. 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: Shower thought
C'11' is higher than C'AA' in EBCDIC. X'11' and X'AA' have nothing to do with EBCDIC. -- Tom Marchant On Wed, 7 Jun 2023 11:02:58 -0700, Charles Mills wrote: >No! Not a hexadecimal comparison. If it were, 11 would compare higher than >AA at least in an EBCDIC environment.
Re: Shower thought
No! Not a hexadecimal comparison. If it were, 11 would compare higher than AA at least in an EBCDIC environment. Hexadecimal is not a format or type of data. It is a way of representing data that works well for communication among humans. What does some particular word in memory contain? One way of expressing the answer is 'ABCD'. Another way of expressing the answer is -1044200508. Inside the computer memory it is something more like 1101111011000100 but that is very clumsy for human communication. Probably the clearest way of expressing it to humans is in hex, C1C2C3C4. FWIW, an equally unambiguous and potentially more compact way is Base64, wcLDxA== Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Wednesday, June 7, 2023 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought "IBM Mainframe Assembler List" wrote on 06/07/2023 01:22:23 PM: > So where does this "Logical" come from? I'm sure it's something obvious! It is a character (hexadecimal) comparison vs. a numeric (binary/packed) comparison.
Re: Shower thought
CL instructions compare bit-by-bit from left to right until there's a mismatch. C instructions compare signed numbers. That's it. The rest is merely implications. sas On Wed, Jun 7, 2023 at 12:29 PM Dave Clark wrote: > "IBM Mainframe Assembler List" wrote on > 06/07/2023 01:22:23 PM: > > So where does this "Logical" come from? I'm sure it's something obvious! > > > Or to extend that a little further... It is a character > (hexadecimal/unsigned) comparison vs. a numeric > (signed binary/packed) comparison. > > > 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: Shower thought
I believe that in the 360+ architecture universe, "logical" means "unsigned." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Wednesday, June 7, 2023 10:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Shower thought I was thinking about assembler today in the shower, as one does, and the L in instructions like CLC and CLI started bothering me: what's with the "Logical"? At first I thought "Hmm, I guessh it gives a logical answer-yes/no" but then realized that of course it doesn't: it's a real comparison, so CLI ,1 will give different CCs if is 0 or 2. So where does this "Logical" come from? I'm sure it's something obvious! ...phsiii P.S. The way I got to that is the usual twisted path: I was thinking about something I have to hunt down in Outlook, and that I can't remember all of one of the search terms (it's a model number), but that Outlook search matches what you specify, so if I know the model starts with XYZ, then I can search that and it will match XYZABC. Which led me to thinking about almost exactly 43 years ago, when my then-mentor (dead for about forty of those years, alas) taught me how to use EXecute with CLC to do this in assembler.
Re: Shower thought
On 6/7/2023 10:22 AM, Phil Smith III wrote: So where does this "Logical" come from? I'm sure it's something obvious! In this context "logical" simply means it's an unsigned comparison. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Shower thought
"IBM Mainframe Assembler List" wrote on 06/07/2023 01:22:23 PM: > So where does this "Logical" come from? I'm sure it's something obvious! Or to extend that a little further... It is a character (hexadecimal/unsigned) comparison vs. a numeric (signed binary/packed) comparison. 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: Shower thought
"IBM Mainframe Assembler List" wrote on 06/07/2023 01:22:23 PM: > So where does this "Logical" come from? I'm sure it's something obvious! It is a character (hexadecimal) comparison vs. a numeric (binary/packed) comparison. 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. *
Shower thought
I was thinking about assembler today in the shower, as one does, and the L in instructions like CLC and CLI started bothering me: what's with the "Logical"? At first I thought "Hmm, I guessh it gives a logical answer-yes/no" but then realized that of course it doesn't: it's a real comparison, so CLI ,1 will give different CCs if is 0 or 2. So where does this "Logical" come from? I'm sure it's something obvious! ...phsiii P.S. The way I got to that is the usual twisted path: I was thinking about something I have to hunt down in Outlook, and that I can't remember all of one of the search terms (it's a model number), but that Outlook search matches what you specify, so if I know the model starts with XYZ, then I can search that and it will match XYZABC. Which led me to thinking about almost exactly 43 years ago, when my then-mentor (dead for about forty of those years, alas) taught me how to use EXecute with CLC to do this in assembler.
