Shower thought

[Phil Smith III]

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 <value>,1 will give different CCs if <value> 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.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> 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.
*********************************************************************************************

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> 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.

[Ed Jaffe]

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.

[Charles Mills]

I believe that in the 360+ architecture universe, "logical" means
"unsigned."

Charles

[Steve Smith]

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

[Charles Mills]

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
11000001110000101100001111000100 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:ASSEMBL...@LISTSERV.UGA.EDU]

[Tom Marchant]

C'11' is higher than C'AA' in EBCDIC.

X'11' and X'AA' have nothing to do with EBCDIC.

--
Tom Marchant

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> 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.

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Charles Mills [char...@MCN.ORG]
Sent: Wednesday, June 7, 2023 2:02 PM

[Bob Flanders]

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


> <Kersnip />

[Seymour J Metz]

I don't know how Hercules does it, but all IBM z processors are highly parallel; the results are the same as a bit by bit comparison, but much faster.

As for your specific question, it depends on what is in the first two bytes of each operand. If the first byte of on is 00 and the first byte of the second is 80 then a serial (by bit (byte) implementation would end on the first bit (byte), and that would be as fast as possible.

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

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Bob Flanders [bob.fl...@GMAIL.COM]
Sent: Wednesday, June 7, 2023 2:27 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Charles Mills]

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:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Bob Flanders
Sent: Wednesday, June 7, 2023 11:28 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Charles Mills]

"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 Mills]

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:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Wednesday, June 7, 2023 11:17 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Paul Gilmartin]

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

[Paul Gilmartin]

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

[Phil Smith III]

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.

[Charles Mills]

@Gil said it better than I.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, June 7, 2023 1:34 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Charles Mills [char...@MCN.ORG]

Sent: Wednesday, June 7, 2023 4:08 PM

[Jon Perryman]

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.

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Charles Mills [char...@MCN.ORG]

Sent: Wednesday, June 7, 2023 4:03 PM

[Paul Gilmartin]

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

[Paul Gilmartin]

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

[Jon Perryman]

As a rule with 1 exception, comparing 2 equal strings will take longer than comparing 2 unequal strings but realize that the time saved may be insignificant. Since CPU cycles are wasted in a bit by bit comparison, most if not all CPU's compare bits in parallel. For most non-IBM CPU's, it's usually between 1 & 4 bytes. I don't know about Z machines but at that price, I wouldn't be surprised if it's 256 bytes.

[Rupert Reynolds]

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

[Jon Perryman]

Sorry, I falsely assumed everyone in this group knew how to convert signed binary.to display.  I said ones complement but meant twos complement.

[Jon Perryman]

[Paul Gilmartin]

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

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jon Perryman [jper...@PACBELL.NET]
Sent: Wednesday, June 7, 2023 5:15 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Jon Perryman]

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.

[Jonathan Scott]

> 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

[Phil Smith III]

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?

[Charles Mills]

As opposed to a signed integer?

For C, X'10000000' compares greater than x'80000000'.

For CL, the reverse is true (a bit-for-bit comparison).

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]

On Behalf Of Phil Smith III
Sent: Monday, June 12, 2023 4:08 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Gary Weinhold]

Or packed decimal or floating point....

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


________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Charles Mills <char...@MCN.ORG>
Sent: June 12, 2023 19:14
To: ASSEMBL...@LISTSERV.UGA.EDU <ASSEMBL...@LISTSERV.UGA.EDU>

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> 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.
*********************************************************************************************

[Phil Smith III]

Ok, thanks. That makes more sense! Now I grok.

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlc...@WINSUPPLYINC.COM]
Sent: Tuesday, June 13, 2023 9:20 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Dave Clark]

Some people love to argue the smallest point.

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> 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.

[Paul Gilmartin]

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

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlc...@WINSUPPLYINC.COM]

Sent: Tuesday, June 13, 2023 12:04 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [00000014e0e4a59...@LISTSERV.UGA.EDU]
Sent: Tuesday, June 13, 2023 12:17 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Shower thought