Re: Making Encoded Bits Human Readable
If I think that the code is unclear then I will include an appropriate comment, in some cases across multiple lines. For LA it's likely to be terse, e.g., LAR14,L'TABELENT Increment for BXLE > Now, both of the following *do* (as you said) nearly the same >thing. > LA R5,0(,16) > LHI R5,16 Shirley you're joking. I would never use LA 16(,0), which is what I assume you meant, because I would consider it to be less clear than LA R5,16. Also, I'd probably have a comment explaining why 16 as opposed to some other number. -- 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, February 8, 2022 12:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable "IBM Mainframe Assembler List" wrote on 02/08/2022 11:23:03 AM: > I use instructions for what they do, not for their motivation or > nomenclature. I would never begrudge another programmer their choices in getting their job done. Then again, I love it when I look at someone else's code and I don't have to guess what it does or what was intended -- in particular, my own, after many years since I originally wrote it. So, I like to write my code to be as self-documenting as possible. Now, both of the following *do* (as you said) nearly the same thing. LA R5,0(,16) LHI R5,16 But not only will the first one yield different results depending upon the current addressing mode, but will also *require* you to look elsewhere to determine what is being done with those results. Why do you have to look elsewhere? Because you have to determine if the original writer intended it for addressing, or not. The second one, on the other hand (and without looking anywhere else), leaves no doubt in your mind that the original writer wanted nothing more than a signed-halfword value as the one and only possible result. The same goes for the following two instructions. If I'm dealing with an address, then I'll use the first one. If I'm dealing with a counter, then I'll use the second one. Why? Because, again, the second one has only one result where the results of the first one depend upon addressing mode. BCTR R5,0 SHI R5,1 So, where possible, I *do* use instructions that make my intent more obvious and I'll not apologize for that. 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: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/08/2022 01:05:09 PM: > Should not that be LA R5,0(,RG) ??? > > And... where can I find one of those machines? :-) No. But, yes, it's a typo. LA R5,16 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: Making Encoded Bits Human Readable
Should not that be LA R5,0(,RG) ??? And... where can I find one of those machines? :-) On 2/8/2022 12:58, Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 02/08/2022 11:23:03 AM: I use instructions for what they do, not for their motivation or nomenclature. I would never begrudge another programmer their choices in getting their job done. Then again, I love it when I look at someone else's code and I don't have to guess what it does or what was intended -- in particular, my own, after many years since I originally wrote it. So, I like to write my code to be as self-documenting as possible. Now, both of the following *do* (as you said) nearly the same thing. LA R5,0(,16) LHI R5,16 But not only will the first one yield different results depending upon the current addressing mode, but will also *require* you to look elsewhere to determine what is being done with those results. Why do you have to look elsewhere? Because you have to determine if the original writer intended it for addressing, or not. The second one, on the other hand (and without looking anywhere else), leaves no doubt in your mind that the original writer wanted nothing more than a signed-halfword value as the one and only possible result. The same goes for the following two instructions. If I'm dealing with an address, then I'll use the first one. If I'm dealing with a counter, then I'll use the second one. Why? Because, again, the second one has only one result where the results of the first one depend upon addressing mode. BCTR R5,0 SHI R5,1 So, where possible, I *do* use instructions that make my intent more obvious and I'll not apologize for that. Sincerely, Dave Clark
Re: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/08/2022 11:23:03 AM: > I use instructions for what they do, not for their motivation or > nomenclature. I would never begrudge another programmer their choices in getting their job done. Then again, I love it when I look at someone else's code and I don't have to guess what it does or what was intended -- in particular, my own, after many years since I originally wrote it. So, I like to write my code to be as self-documenting as possible. Now, both of the following *do* (as you said) nearly the same thing. LA R5,0(,16) LHI R5,16 But not only will the first one yield different results depending upon the current addressing mode, but will also *require* you to look elsewhere to determine what is being done with those results. Why do you have to look elsewhere? Because you have to determine if the original writer intended it for addressing, or not. The second one, on the other hand (and without looking anywhere else), leaves no doubt in your mind that the original writer wanted nothing more than a signed-halfword value as the one and only possible result. The same goes for the following two instructions. If I'm dealing with an address, then I'll use the first one. If I'm dealing with a counter, then I'll use the second one. Why? Because, again, the second one has only one result where the results of the first one depend upon addressing mode. BCTR R5,0 SHI R5,1 So, where possible, I *do* use instructions that make my intent more obvious and I'll not apologize for that. 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: Making Encoded Bits Human Readable
"I use instructions for what they do, not for their motivation or nomenclature." +1 OR LA 1,1(,1) if you like. On Tue, 8 Feb 2022 at 11:23, Seymour J Metz wrote: > I have certainly been accused of being a pedant, and I freely use LA as an > add immediate instruction for constants less than 4096. I use instructions > for what they do, not for their motivation or nomenclature. Do you find it > improper to use UNPK for purposes other than decimal arithmetic, e.g., > converting binary to hexadecimal for display? BCTR to decrement a register > without testing it? > > > -- > 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, February 8, 2022 10:44 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Making Encoded Bits Human Readable > > On Feb 7, 2022, at 23:10:49, Bob Raicer wrote: > > > > Just for fun, here is yet one more variation on Peter's scheme, using > > only S/360 instructions. In the comments, YY and ZZ represent the two > > bit pairs of interest, lower case x represents bits or bytes of unknown > > value. Bit strings are enclosed in square brackets. Bytes are separated > > by underscore characters. > > > > XRR14,R14 R14 = 00_00_00_00. > > > Is that the fastest way to clear R14 on S/360? > > > ... > > LAR14,X'F1'(,R14) * Scale x'00' through x'03' > > LAR15,X'F1'(,R15) * to x'F1' through x'F4' > > > Is that more transparent than: > LAR14,C'1'(,R14) > LAR15,C'1'(,R15) > ??? When I'm wearing my Pascal hat I loathe arithmetic operations > on character operands. When I wear my C hat they come naturally. > > A pedant insisted (here? lately?) that LA should be used only with > operands referring to storage addresses. I believe the rationale > is that reckless use of LA in lieu of Immediate instructions, which > have existed only recently, risks unexpected truncation to 24 bits > or 31 bits. > > -- > gil >
Re: Making Encoded Bits Human Readable
I have certainly been accused of being a pedant, and I freely use LA as an add immediate instruction for constants less than 4096. I use instructions for what they do, not for their motivation or nomenclature. Do you find it improper to use UNPK for purposes other than decimal arithmetic, e.g., converting binary to hexadecimal for display? BCTR to decrement a register without testing it? -- 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, February 8, 2022 10:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable On Feb 7, 2022, at 23:10:49, Bob Raicer wrote: > > Just for fun, here is yet one more variation on Peter's scheme, using > only S/360 instructions. In the comments, YY and ZZ represent the two > bit pairs of interest, lower case x represents bits or bytes of unknown > value. Bit strings are enclosed in square brackets. Bytes are separated > by underscore characters. > > XRR14,R14 R14 = 00_00_00_00. > Is that the fastest way to clear R14 on S/360? > ... > LAR14,X'F1'(,R14) * Scale x'00' through x'03' > LAR15,X'F1'(,R15) * to x'F1' through x'F4' > Is that more transparent than: LAR14,C'1'(,R14) LAR15,C'1'(,R15) ??? When I'm wearing my Pascal hat I loathe arithmetic operations on character operands. When I wear my C hat they come naturally. A pedant insisted (here? lately?) that LA should be used only with operands referring to storage addresses. I believe the rationale is that reckless use of LA in lieu of Immediate instructions, which have existed only recently, risks unexpected truncation to 24 bits or 31 bits. -- gil
Re: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/08/2022 10:44:06 AM: > A pedant insisted (here? lately?) that LA should be used only with > operands referring to storage addresses. That is now my motto ever since I was told about the LHI and AHI instructions. I even created an SHI macro to complete the set. 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: Making Encoded Bits Human Readable
On Feb 7, 2022, at 23:10:49, Bob Raicer wrote: > > Just for fun, here is yet one more variation on Peter's scheme, using > only S/360 instructions. In the comments, YY and ZZ represent the two > bit pairs of interest, lower case x represents bits or bytes of unknown > value. Bit strings are enclosed in square brackets. Bytes are separated > by underscore characters. > > XRR14,R14 R14 = 00_00_00_00. > Is that the fastest way to clear R14 on S/360? > ... > LAR14,X'F1'(,R14) * Scale x'00' through x'03' > LAR15,X'F1'(,R15) * to x'F1' through x'F4' > Is that more transparent than: LAR14,C'1'(,R14) LAR15,C'1'(,R15) ??? When I'm wearing my Pascal hat I loathe arithmetic operations on character operands. When I wear my C hat they come naturally. A pedant insisted (here? lately?) that LA should be used only with operands referring to storage addresses. I believe the rationale is that reckless use of LA in lieu of Immediate instructions, which have existed only recently, risks unexpected truncation to 24 bits or 31 bits. -- gil
Re: Making Encoded Bits Human Readable
Just for fun, here is yet one more variation on Peter's scheme, using only S/360 instructions. In the comments, YY and ZZ represent the two bit pairs of interest, lower case x represents bits or bytes of unknown value. Bit strings are enclosed in square brackets. Bytes are separated by underscore characters. XR R14,R14 R14 = 00_00_00_00 IC R14,BYTE R14 = 00_00_00_[YYZZ] SRDL R14,6(0) R14 = 00_00_00_[00YY] * R15 = [ZZxx]_xx_xx_xx SRL R15,30(0) R15 = 00_00_00_[00ZZ] LA R14,X'F1'(,R14) * Scale x'00' through x'03' LA R15,X'F1'(,R15) * to x'F1' through x'F4'
Re: Making Encoded Bits Human Readable
Making Peter's approach even more old school, use R14 and R15 instead of R0 and R1, and do the character conversion stuff with Load Address instead of Add Halfword Immediate. ICM R14,B'1000',BYTE Put the byte into bits 0-7 SRDL R14,30 Move BYTE.0-1 to reg 14.30-31, * zeroing reg 14.0-29 * BYTE.2-3 to reg 15.0-1 SRL R15,30 Move BYTE.2-3 to reg 15.30-31, * zeroing reg 15.0-29 LA R14,X'F1'(,R14) 0-3 => C'1'-C'4' LA R15,X'F1'(,R15) STC R14,TARGET0 STC R15,TARGET1 BYTE DS X
Making encoded bits human readable
(Snip) I don't remember why the OP wanted to make a value range of 0-3 human-readable as 1-4. (End Snip) I think it was the display of the VSAM SHAREOPTION after the extraction of the encoded equivalent from the catalog. Mike Kerford-Byrnes
Re: Making Encoded Bits Human Readable
OK. Let's go through the code one instruction at a time. I1 LLGC R0,BYTE Low order byte of R0 * contains byte of interest. * * Bits 56-59 contain the two * adjacent bit pairs of * interest. * * Bits 60-63 are of no * interest. * * Bits 0-55 are zero. * I2 SRL R0,4(0) Bits 60-63 of R0 contain * the pair of two bits of * interest. Bits 0-59 are * zero. * I3 SRLG R1,R0,2(0) R1 contains the first pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * I4 NILL R0,B'11' R0 contains the second pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * I5 AHI R0,C'1' * Convert the bit pairs to I6 AHI R1,C'1' * Zoned Decimal format, * * origined at 1. In the commentary below I will show the bytes of a register as two hex digits per byte, with bytes separated by underscore characters. When showing the bits of a byte, all eight bits will be shown. The bits of the BYTE data item are laid out as follows: JKYZ Where the leftmost two bits (JK) are the first bit pair of interest, and the next two bits (YZ) are the next pair of bits of interest. The remaining four bits () are of no interest. Instruction I1 At the completion of this instruction the 64-bit GPR 0 contains: 00_00_00_00_00_00_00_JKYZ Instruction I2 This shifts the low order 32-bits of the 64-bit GPR 0 right by four bits. The High order 32-bits of the 64-bit GPR 0 are unchanged. At the completion of this instruction the 64-bit GPR 0 contains: 00_00_00_00_00_00_00_JKYZ Instruction I3 This shifts the CONTENT of the 64-bit GPR 0 (not the register itself) right by two bits and places the 64-bit result of the shift into the 64-bit GPR 1. GPR 0 is UNCHANGED by this operation. At the completion of this instruction, the 64-bit GPRs of interest contain: GPR 0: 00_00_00_00_00_00_00_JKYZ GPR 1: 00_00_00_00_00_00_00_00JK Instruction I4 This performs a bitwise AND of the rightmost 16-bits of the 64-bit GPR 0 with the immediate operand of B'0011'. The leftmost 48-bits of the 64-bit GPR 0 are unchanged by this operation. At the completion of this instruction, the 64-bit GPRs of interest contain: GPR 0: 00_00_00_00_00_00_00_00YZ GPR 1: 00_00_00_00_00_00_00_00JK Instruction I5 This performs a Signed Add of the Signed immediate operand value of x'00F1' to the low order 32-bits of the 64-bit GPR 0. Note that a Fixed-Point Overflow cannot occur. The maximum value which can result from the Addition is 00_00_00_F4. The low order 32-bits of the 64-bit GPR 0 are replaced by the resultant sum. The high order 32-bits of the 64-bit GPR 0 are unchanged by this operation. Instruction I6 This performs the identical operation as instruction I5, except the 64-bit GPR being operated upon is Register 1 instead of Register 0.
Re: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/05/2022 08:25:37 AM: > The lowest-tech approach using only two regs (no 64-bit regs, no z/Arch > instructions, no 6-byte instructions even) that came to mind was this: > > ICM 0,B'1000',BYTE Put the byte into bits 0-7 > SRDL 0,30 Move BYTE.0-1 to reg 0.30-31, > * zeroing reg 0.0-29 > * BYTE.2-3 to reg 1.0-1 > SRL 1,30 Move BYTE.2-3 to reg 1.30-31, > * zeroing reg 1.0-29 > AHI 0,C'1' 0-3 => C'1'-C'4' > AHI 1,C'1' > STC 0,target0 > STC 1,target1 > BYTE DSX > > I.e., taking advantage of needing to do a shift anyway to avoid having to > clear anything. I like that one and it is easy to understand what it is doing. I will keep that one. 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: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/05/2022 08:25:37 AM: > I don't remember why the OP wanted to make a value range of 0-3 > human-readable as 1-4. VSAM ShareOptions are displayed as 1 to 4 but stored in the catalog as 0 to 3. That is why. ;-) 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: Making Encoded Bits Human Readable
On Feb 5, 2022, at 06:25:37, Peter Relson wrote: > ... > I don't remember why the OP wanted to make a value range of 0-3 > human-readable as 1-4. ... > Do you remember why the count field in SS instructions is Similarly biased to a human-readable 1-256? -- gil
Re: Making Encoded Bits Human Readable
The lowest-tech approach using only two regs (no 64-bit regs, no z/Arch instructions, no 6-byte instructions even) that came to mind was this: ICM 0,B'1000',BYTE Put the byte into bits 0-7 SRDL 0,30 Move BYTE.0-1 to reg 0.30-31, * zeroing reg 0.0-29 * BYTE.2-3 to reg 1.0-1 SRL 1,30 Move BYTE.2-3 to reg 1.30-31, * zeroing reg 1.0-29 AHI 0,C'1' 0-3 => C'1'-C'4' AHI 1,C'1' STC 0,target0 STC 1,target1 BYTE DSX I.e., taking advantage of needing to do a shift anyway to avoid having to clear anything. That doesn't make it the fastest (for example, LLC might be faster than ICM) but is a 6-byte instruction. The fastest is going to be some sort of table look-up (as has been discussed, whether TROT or something else) but that takes more storage. I don't remember why the OP wanted to make a value range of 0-3 human-readable as 1-4. If you could settle for displaying as human-readable 0-3, then instead of the AHI one could do an OI xxx,C'0' after the STC. It would quite likely perform worse (an extra storage reference instead of a register update), but then you'd be using nothing even as new as relative-immediate if that were a consideration. Shmuel wrote: >Wouldn't RISBGZ R0,R1,62,63,2 be clearer than XR and SLDL? Not to many of us. I'm impressed that it is to you. It's a great instruction (which is presumably why it was made available to us mere mortals from those previously available only to the millicode folks). But "clearer"? That wouldn't be an adjective I'd use. Peter Relson z/OS Core Technology Design
Re: Making Encoded Bits Human Readable
The instruction SRLG R1,R0,2(0) loads R1 with a shifted copy or R0. It's not a double shift. -- 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: Friday, February 4, 2022 12:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable "IBM Mainframe Assembler List" wrote on 02/04/2022 12:11:53 PM: > Instruction 3 doesn't affect R0, so it still has the 4 leftmost bits > from instruction 2. Instruction 4 removes the left two bits, leaving > only the right two bits. In that case, those are the wrong two bits that would be needed. The right two bits were shifted into R1 so it is the left two bits that are needed. Correct? 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: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/04/2022 12:11:53 PM: > Instruction 3 doesn't affect R0, so it still has the 4 leftmost bits > from instruction 2. Instruction 4 removes the left two bits, leaving > only the right two bits. In that case, those are the wrong two bits that would be needed. The right two bits were shifted into R1 so it is the left two bits that are needed. Correct? 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: Making Encoded Bits Human Readable
Instruction 3 doesn't affect R0, so it still has the 4 leftmost bits from instruction 2. Instruction 4 removes the left two bits, leaving only the right two bits. I sometimes use "ASCII (sic) art" in my comments for such instruction sequences to provide a visual indication of what is where at each stage. Have pity on the poor slob reading your code a year from now; it might be you. BTDT,GTS. -- 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: Friday, February 4, 2022 10:05 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable "IBM Mainframe Assembler List" wrote on 02/03/2022 06:49:33 PM: > Here is another possibility that uses instructions which have been > available since the publication of the original z/Architecture > Principles of Operation in December 2000. It is only one > instruction longer (and four instruction bytes longer) than the > scheme offered by Dan Greiner, although not as nifty! OK, let's examine this. I follow what lines 1 to 3 will do. But it doesn't seem that line 4 will do what I need. The reason I am confused is because the PoPs manual says that line 3, in this case, will not change the content of R0, thus bits 28-31 are the same as they were after line 2. In that case, how does line 4 get R0 bits 28-29 into bit positions 30-31 where they need to be for line 5 to work correctly? 1. LLGC R0,BYTE GET ENCODED BYTE (NEED BITS 24-27) 2. SRL R0,4(0) SHIFT OUT RIGHTMOST 4 BITS 3. SRLG R1,R0,2(0) SHIFT NEXT 2 BITS INTO R1 (R0 UNCHANGED) 4. NILL R0,B'11'(CONFUSED, WHAT DOES THIS ACTUALLY DO?) 5. AHI R0,C'1' ORIG. BITS 24-25 TO ZONED DECIMAL 6. AHI R1,C'1' ORIG. BITS 26-27 TO ZONED DECIMAL 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: Making Encoded Bits Human Readable
Wouldn't RISBGZ R0,R1,62,63,2 be clearer than XR and SLDL? BTW, how do the timings compare on a z15? -- 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: Friday, February 4, 2022 10:51 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable David L Clark/it/crp/WinWholesale wrote on 02/04/2022 10:05:30 AM: > OK, let's examine this. I follow what lines 1 to 3 will do. But > it doesn't seem that line 4 will do what I need. The reason I am > confused is because the PoPs manual says that line 3, in this case, > will not change the content of R0, thus bits 28-31 are the same as > they were after line 2. In that case, how does line 4 get R0 bits > 28-29 into bit positions 30-31 where they need to be for line 5 to > work correctly? > > 1. LLGC R0,BYTE GET ENCODED BYTE (NEED BITS 24-27) > 2. SRL R0,4(0) SHIFT OUT RIGHTMOST 4 BITS > 3. SRLG R1,R0,2(0) SHIFT NEXT 2 BITS INTO R1 (R0 UNCHANGED) > 4. NILL R0,B'11'(CONFUSED, WHAT DOES THIS ACTUALLY DO?) > 5. AHI R0,C'1' ORIG. BITS 24-25 TO ZONED DECIMAL > 6. AHI R1,C'1' ORIG. BITS 26-27 TO ZONED DECIMAL And, yes, sorry, I treated all registers as 32-bit registers. Please adjust my comments accordingly. Thanks. Otherwise, I am currently using the following. LLC R0,RECBUF+108NEED ONLY x'XX..' PART SRDL R0,2+4 SHIFT OUT 6 BITS INTO R1 AHI R0,C'1' YIELD '1' TO '4' VALUE STC R0,CWORK FOR INTRASYSTEM SHROPT XR R0,R0CLEAR REG FOR NEXT 2 BITS SLDL R0,2 SHIFT IN 2 BITS FROM R1 AHI R0,C'1' YIELD '1' TO '4' VALUE STC R0,CWORK+2FOR INTERSYSTEM SHROPT 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: Making Encoded Bits Human Readable
David L Clark/it/crp/WinWholesale wrote on 02/04/2022 10:05:30 AM: > OK, let's examine this. I follow what lines 1 to 3 will do. But > it doesn't seem that line 4 will do what I need. The reason I am > confused is because the PoPs manual says that line 3, in this case, > will not change the content of R0, thus bits 28-31 are the same as > they were after line 2. In that case, how does line 4 get R0 bits > 28-29 into bit positions 30-31 where they need to be for line 5 to > work correctly? > > 1. LLGC R0,BYTE GET ENCODED BYTE (NEED BITS 24-27) > 2. SRL R0,4(0) SHIFT OUT RIGHTMOST 4 BITS > 3. SRLG R1,R0,2(0) SHIFT NEXT 2 BITS INTO R1 (R0 UNCHANGED) > 4. NILL R0,B'11'(CONFUSED, WHAT DOES THIS ACTUALLY DO?) > 5. AHI R0,C'1' ORIG. BITS 24-25 TO ZONED DECIMAL > 6. AHI R1,C'1' ORIG. BITS 26-27 TO ZONED DECIMAL And, yes, sorry, I treated all registers as 32-bit registers. Please adjust my comments accordingly. Thanks. Otherwise, I am currently using the following. LLC R0,RECBUF+108NEED ONLY x'XX..' PART SRDL R0,2+4 SHIFT OUT 6 BITS INTO R1 AHI R0,C'1' YIELD '1' TO '4' VALUE STC R0,CWORK FOR INTRASYSTEM SHROPT XR R0,R0CLEAR REG FOR NEXT 2 BITS SLDL R0,2 SHIFT IN 2 BITS FROM R1 AHI R0,C'1' YIELD '1' TO '4' VALUE STC R0,CWORK+2FOR INTERSYSTEM SHROPT 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: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/03/2022 06:49:33 PM: > Here is another possibility that uses instructions which have been > available since the publication of the original z/Architecture > Principles of Operation in December 2000. It is only one > instruction longer (and four instruction bytes longer) than the > scheme offered by Dan Greiner, although not as nifty! OK, let's examine this. I follow what lines 1 to 3 will do. But it doesn't seem that line 4 will do what I need. The reason I am confused is because the PoPs manual says that line 3, in this case, will not change the content of R0, thus bits 28-31 are the same as they were after line 2. In that case, how does line 4 get R0 bits 28-29 into bit positions 30-31 where they need to be for line 5 to work correctly? 1. LLGC R0,BYTE GET ENCODED BYTE (NEED BITS 24-27) 2. SRL R0,4(0) SHIFT OUT RIGHTMOST 4 BITS 3. SRLG R1,R0,2(0) SHIFT NEXT 2 BITS INTO R1 (R0 UNCHANGED) 4. NILL R0,B'11'(CONFUSED, WHAT DOES THIS ACTUALLY DO?) 5. AHI R0,C'1' ORIG. BITS 24-25 TO ZONED DECIMAL 6. AHI R1,C'1' ORIG. BITS 26-27 TO ZONED DECIMAL 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: Making Encoded Bits Human Readable
Here is another possibility that uses instructions which have been available since the publication of the original z/Architecture Principles of Operation in December 2000. It is only one instruction longer (and four instruction bytes longer) than the scheme offered by Dan Greiner, although not as nifty! Bob LLGC R0,BYTE Low order byte of R0 * contains byte of interest. * * Bits 56-59 contain the two * adjacent bit pairs of * interest. * * Bits 60-63 are of no * interest. * * Bits 0-55 are zero. * SRL R0,4(0) Bits 60-63 of R0 contain * the pair of two bits of * interest. Bits 0-59 are * zero. * SRLG R1,R0,2(0) R1 contains the first pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * NILL R0,B'11' R0 contains the second pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * AHI R0,C'1' * Convert the bit pairs to AHI R1,C'1' * Zoned Decimal format, * * origined at 1.
Re: Making Encoded Bits Human Readable
One other option that generates a few bytes less code: IC 1,BYTE RISBGZ 0,1,54,55,2 RISBGZ 1,1,62,63,-4 OR 0,1 AHI 0,C'11' This puts the results in the rightmost two bytes of general register 0.
Re: Making Encoded Bits Human Readable
No sexy instructions, but this code provides the output characters complete with a space, and uses only one register: LLC 1,BYTE SRL 1,4 MHI 1,3 LA 1,TABLE(1) MVC RESULT,0(1) TABLE DC C'1 11 21 31 42 12 22 32 43 13 23 33 44 14 24 34 4' RESULT DS CL3 On 2/1/2022 09:32, Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 02/01/2022 04:40:19 AM: To be fair we have to consider that Dave stored the results That's correct. but, I wasn't storing the two values next to each other. I left a space in between. So you need two instructions to store the results instead of just one. Sincerely, Dave Clark
Re: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 02/01/2022 04:40:19 AM: > To be fair we have to consider that Dave stored the results That's correct. but, I wasn't storing the two values next to each other. I left a space in between. So you need two instructions to store the results instead of just one. 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: Making Encoded Bits Human Readable
It'd s typo for ALFI, on p. 7-29 of the -12 PoOps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Trübner [mar...@pi-sysprog.de] Sent: Tuesday, February 1, 2022 2:49 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable Seymour, where is ALI documented? or is that a typo and you ment AHI? Martin
Re: Making Encoded Bits Human Readable
AHI takes a signed operand. You could use ALFI, but that's 2 bytes longer. Is a
quote (") valid for framing constants? SC26-4940-06 only lists apostrophes.
What is the URL for the most recent edition?
I've submitted an RCF asking for clarification of the syntax of self-defining
terms.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Martin Trübner [mar...@pi-sysprog.de]
Sent: Tuesday, February 1, 2022 4:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Making Encoded Bits Human Readable
To be fair we have to consider that Dave stored the results
So:
Dave had 38 with storing results
Dan is IMHO 32 with storing results
Mine is 26 with storing results
LLC R0,BYTE
SRDL R0,6
SRL R1,6
SLDL R0,8
AHI R0,C"11"
STH R0,RESULT
But HLASM complains:
** ASMA320W Immediate field operand may have incorrect sign or magnitude
only a sev 4
But it lacks the trick for making the result ASCII 😉 with this:
** ASMA150E Symbol has non-alphanumeric character or invalid delimiter - CA'11'
for this we get a sev 8
Martin
Re: Making Encoded Bits Human Readable
Tony, sorry - I did not read to the end. Yours is the shortest (24 bytes - all should have new machines) But the table is pretty long Martin
Re: Making Encoded Bits Human Readable
Ref: Your note of Tue, 1 Feb 2022 10:40:19 +0100 Martin Truebner writes: > > LLC R0,BYTE > SRDL R0,6 > SRL R1,6 > SLDL R0,8 > AHI R0,C"11" > STH R0,RESULT > > But HLASM complains: > ** ASMA320W Immediate field operand may have incorrect sign or magnitude > > only a sev 4 That's because C'11' is decimal 61937 which is out of the range of a signed halfword. The first 17 bits must be the same to be in the correct range. If you change C'11' to C'11'-X'1' to map it into the valid signed range then the warning should go away. Alternatively, if you have APAR PH38969 from July 2021 you can temporarily use ACONTROL TYPECHECK(NOSIGNED). > But it lacks the trick for making the result ASCII with this: > ** ASMA150E Symbol has non-alphanumeric character or invalid delimiter - > CA'11' > > for this we get a sev 8 ASCII self-defining terms have been supported since APAR PI89365 in November 2017. I'd suggest getting more up to date on maintenance. CA'11' is a valid signed halfword, avoiding the other problem. Jonathan Scott, HLASM IBM Hursley, UK
Re: Making Encoded Bits Human Readable
To be fair we have to consider that Dave stored the results So: Dave had 38 with storing results Dan is IMHO 32 with storing results Mine is 26 with storing results LLC R0,BYTE SRDL R0,6 SRL R1,6 SLDL R0,8 AHI R0,C"11" STH R0,RESULT But HLASM complains: ** ASMA320W Immediate field operand may have incorrect sign or magnitude only a sev 4 But it lacks the trick for making the result ASCII 😉 with this: ** ASMA150E Symbol has non-alphanumeric character or invalid delimiter - CA'11' for this we get a sev 8 Martin
Re: Making Encoded Bits Human Readable
Seymour, where is ALI documented? or is that a typo and you ment AHI? Martin
Re: Making Encoded Bits Human Readable
Tony, Your code only decodes the first two bits Martin
Re: Making Encoded Bits Human Readable
TROO and TROT managed to escape my notice for the last decade. Thanks for sharing! -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Harminc Sent: Monday, January 31, 2022 10:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable Caution! This message was sent from outside your organization. On Mon, 31 Jan 2022 at 15:55, Dave Clark wrote: > Good deal. I replaced the following 104 bytes of machine code... ... > ...with the following 38 bytes of machine code. Thanks. Here's a different approach, though if you are primarily looking to economize on code bytes, it may not be for you. It uses a 256-byte table to contain the possible output values, and just translates the input to output directly. (I'm assuming that the bits to the right of the top four may not be zero.) SRR0,R0 Test char not in table (for older machines) LAR1,TABLE1 -> 256-byte table LAR3,RECBUF+108 -> Input byte LAR6,CWORK-> One output byte LHI R7,1Length of input in bytes TROO TROO R6,R3,B’0001’ Translate with no test BC3,TROO Unlikely, but be safe TABLE1 DS 0D Critical alignment! Input values DC C'' 00-0F DC C'' 10-1F DC C'' 20-2F DC C'' 30-3F DC C'' 40-4F DC C'' 50-5F DC C'' 60-6F DC C'' 70-7F DC C'' 80-8F DC C'' 90-9F DC C'' A0-AF DC C'' B0-BF DC C'' C0-CF DC C'' D0-DF DC C'' E0-EF DC C'' F0-FF The above handles only the first of your two sets of two bits, and a different table is needed to deal with the second. But it can all be done in a single translate with the right table: SRR0,R0Test char not in table (for older machines) LAR1,TABLE2 -> 512-byte table LAR3,RECBUF+108 -> Input byte LAR6,CWORK -> Two output bytes LHI R7,1 Length of input in bytes TROTTROT R6,R3,B’0001’ Translate with no test BC3,TROTUnlikely, but be safe TABLE2 DS0D Critical alignment! Input values DC C'' 00-0F DC C'12121212121212121212121212121212' 10-1F DC C'13131313131313131313131313131313' 20-2F DC C'14141414141414141414141414141414' 30-3F DC C'21212121212121212121212121212121' 40-4F DC C'' 50-5F DC C'23232323232323232323232323232323' 60-6F DC C'24242424242424242424242424242424' 70-7F DC C'31313131313131313131313131313131' 80-8F DC C'32323232323232323232323232323232' 90-9F DC C'' A0-AF DC C'34343434343434343434343434343434' B0-BF DC C'41414141414141414141414141414141' C0-CF DC C'42424242424242424242424242424242' D0-DF DC C'43434343434343434343434343434343' E0-EF DC C'' F0-FF This isn't a complete drop-in for your code because it produces the two output value in adjacent bytes at CWORK, but perhaps you can accept that, or if not, you can copy the second byte to the right place. lease excuse typos; I haven't actually built or tested this. One could write a simple macro to generate the table from the bit field sizes and range, and it could handle any number of bytes with the same bit layout within each byte. Of course I wouldn't seriously recommend this approach for dealing with one byte, but it does show how powerful TROT in particular can be. I've been using it to produce printable hex fields for a few years, and it sure beats an UNPK loop. I'm sure there are other innovative uses for it. Tony H.
Re: Making Encoded Bits Human Readable
On Mon, 31 Jan 2022 at 15:55, Dave Clark wrote: > Good deal. I replaced the following 104 bytes of machine code... ... > ...with the following 38 bytes of machine code. Thanks. Here's a different approach, though if you are primarily looking to economize on code bytes, it may not be for you. It uses a 256-byte table to contain the possible output values, and just translates the input to output directly. (I'm assuming that the bits to the right of the top four may not be zero.) SRR0,R0 Test char not in table (for older machines) LAR1,TABLE1 -> 256-byte table LAR3,RECBUF+108 -> Input byte LAR6,CWORK-> One output byte LHI R7,1Length of input in bytes TROO TROO R6,R3,B’0001’ Translate with no test BC3,TROO Unlikely, but be safe TABLE1 DS 0D Critical alignment! Input values DC C'' 00-0F DC C'' 10-1F DC C'' 20-2F DC C'' 30-3F DC C'' 40-4F DC C'' 50-5F DC C'' 60-6F DC C'' 70-7F DC C'' 80-8F DC C'' 90-9F DC C'' A0-AF DC C'' B0-BF DC C'' C0-CF DC C'' D0-DF DC C'' E0-EF DC C'' F0-FF The above handles only the first of your two sets of two bits, and a different table is needed to deal with the second. But it can all be done in a single translate with the right table: SRR0,R0Test char not in table (for older machines) LAR1,TABLE2 -> 512-byte table LAR3,RECBUF+108 -> Input byte LAR6,CWORK -> Two output bytes LHI R7,1 Length of input in bytes TROTTROT R6,R3,B’0001’ Translate with no test BC3,TROTUnlikely, but be safe TABLE2 DS0D Critical alignment! Input values DC C'' 00-0F DC C'12121212121212121212121212121212' 10-1F DC C'13131313131313131313131313131313' 20-2F DC C'14141414141414141414141414141414' 30-3F DC C'21212121212121212121212121212121' 40-4F DC C'' 50-5F DC C'23232323232323232323232323232323' 60-6F DC C'24242424242424242424242424242424' 70-7F DC C'31313131313131313131313131313131' 80-8F DC C'32323232323232323232323232323232' 90-9F DC C'' A0-AF DC C'34343434343434343434343434343434' B0-BF DC C'41414141414141414141414141414141' C0-CF DC C'42424242424242424242424242424242' D0-DF DC C'43434343434343434343434343434343' E0-EF DC C'' F0-FF This isn't a complete drop-in for your code because it produces the two output value in adjacent bytes at CWORK, but perhaps you can accept that, or if not, you can copy the second byte to the right place. lease excuse typos; I haven't actually built or tested this. One could write a simple macro to generate the table from the bit field sizes and range, and it could handle any number of bytes with the same bit layout within each byte. Of course I wouldn't seriously recommend this approach for dealing with one byte, but it does show how powerful TROT in particular can be. I've been using it to produce printable hex fields for a few years, and it sure beats an UNPK loop. I'm sure there are other innovative uses for it. Tony H.
Re: Making Encoded Bits Human Readable
I believe that they've demolished the station :-(
--
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: Monday, January 31, 2022 7:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Making Encoded Bits Human Readable
Perhaps that train has left the station?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Monday, January 31, 2022 4:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Making Encoded Bits Human Readable
ObStretch This thread is exactly why I was appaled by the "Model T" byte
("any size you want as long as it's 8") byte handling on the S/360, which z
inherited.
Re: Making Encoded Bits Human Readable
I'd probably do IC R1,Flag RISBGZ R0,R1,62,63,-6 RISBGZ R1,R1,62,63,-4 ALIR0,C'1' ALIR1,C'1' rather than using LLC and SRL -- 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: Monday, January 31, 2022 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Making Encoded Bits Human Readable I have two pairs of encoded bits in the high order of a binary byte. These two pairs (values of 0 to 3, each) actually represent the numbers 1 to 4 in each case. Now, I know that I could do this the hard (long?) way by bit-testing these and come up with the human-readable zoned equivalents. In fact, I've already done that. But, not only do I not like how the code looks in my program, I also think there should be a shorter way. For example, I could insert the byte into a register, shift out the unwanted bits, and then add 1 to get the same numbers -- but in binary. I would then have to convert-to-decimal and unpack or edit the numbers into zoned format. That seems like a bit much. So, is that what I am going to have to do? ...or stick with bit-testing? ...or is there a better way to accomplish this? 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: Making Encoded Bits Human Readable
Perhaps that train has left the station?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Monday, January 31, 2022 4:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Making Encoded Bits Human Readable
ObStretch This thread is exactly why I was appaled by the "Model T" byte
("any size you want as long as it's 8") byte handling on the S/360, which z
inherited.
Re: Making Encoded Bits Human Readable
ObStretch This thread is exactly why I was appaled by the "Model T" byte ("any
size you want as long as it's 8") byte handling on the S/360, which z inherited.
Still, you can do a lot with the Rotate Then foo instructions.
--
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: Monday, January 31, 2022 2:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Making Encoded Bits Human Readable
On Jan 31, 2022, at 12:31:15, Dave Clark wrote:
>
>I have two pairs of encoded bits in the high order of a binary
> byte. These two pairs (values of 0 to 3, each) actually represent the
> numbers 1 to 4 in each case. Now, I know that I could do this the hard
> (long?) way by bit-testing these and come up with the human-readable zoned
> equivalents. In fact, I've already done that.
>
I'm thinking:
Isolate a bit-pair with shift-and-mask
then AHI C'1'
--
gil
Re: Making Encoded Bits Human Readable
ROTATE THEN INSERT SELECTED BITS (RISBG) was added as a part of the general-instructions-extension facility coincident with the introduction of the z10 in 2008. As I recall, most operating systems are now level set at or above the z10, so there's a pretty good chance the instruction will be available on most z systems. RISBG is not part of the garbage-collection enhancements. These instructions (LLG, LLGFSG, LGSC, & STGSC) were added to the architecture as part of the guarded-storage facility coincident with the introduction of the z14 in 2017. The guarded-storage facility is a particularly esoteric feature in support of languages such as Java & Python that have a hard time keeping tabs on a users' storage allocation.
Re: Making Encoded Bits Human Readable
Elegant...and now we're down to 24 bytes of machine code! Dan, is RISBGZ one of the instructions added to speed up Java garbage collection? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jan 31, 2022 at 4:08 PM Dan Greiner wrote: > The following code snippet does the trick, leaving the results in general > registers 0 and 1. > > LLC 0,BYTE > RISBGZ 1,0,62,63,-4 > SRL 0,6 > AHI 0,C'1'(or CA'1' for results in ASCII) > AHI 1,C'1' (or CA'1' for results in ASCII) > > (I consider ROTATE THEN INSERT SELECTED BITS to be the sexiest instruction > in the architecture.) >
Re: Making Encoded Bits Human Readable
The following code snippet does the trick, leaving the results in general registers 0 and 1. LLC 0,BYTE RISBGZ 1,0,62,63,-4 SRL 0,6 AHI 0,C'1'(or CA'1' for results in ASCII) AHI 1,C'1' (or CA'1' for results in ASCII) (I consider ROTATE THEN INSERT SELECTED BITS to be the sexiest instruction in the architecture.)
Re: Making Encoded Bits Human Readable
Good deal. I replaced the following 104 bytes of machine code... IF RECBUF+108,(ON,TM),B'1100' MVI CWORK,C'4' ELSE IF RECBUF+108,(ON,TM),B'1000' MVI CWORK,C'3' ELSE IF RECBUF+108,(ON,TM),B'0100' MVI CWORK,C'2' ELSE MVI CWORK,C'1' ENDIF ENDIF ENDIF IF RECBUF+108,(ON,TM),B'0011' MVI CWORK+2,C'4' ELSE IF RECBUF+108,(ON,TM),B'0010' MVI CWORK+2,C'3' ELSE IF RECBUF+108,(ON,TM),B'0001' MVI CWORK+2,C'2' ELSE MVI CWORK+2,C'1' ENDIF ENDIF ENDIF ...with the following 38 bytes of machine code. Thanks. XR R1,R1 CLEAR WORK REGISTER IC R1,RECBUF+108 GET ENCODED BYTE SRL R1,6 SHIFT OUT RIGHTMOST BITS AHI R1,C'1' YIELD '1' TO '4' VALUE STC R1,CWORK STORE THAT IC R1,RECBUF+108 GET ENCODED BYTE, AGAIN SLL R1,24+2 SHIFT OUT LEFTMOST BITS SRL R1,24+6 SHIFT INTO POSITION AHI R1,C'1' YIELD '1' TO '4' VALUE STC R1,CWORK+2STORE THAT 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: Making Encoded Bits Human Readable
Gil, that was a bit too short an answer. I intended it to mean yes, you should surely use IPM to preserve program mask. Having said that, the solution you suggested is far superior. So better forget SPM and IPM altogether ;-) BTW: the closest thing to shift-and-mask is probably RISBG with a zero rotate amount. Which has the advantage of leaving its input register (R2 in PoP parlance) unchanged. So you can easily repeat for the second set of two bits... Abe === Op 31/01/2022 om 21:15 schreef Abe Kornelis: > Gil, > > you surely should! > > Abe > === > > > Op 31/01/2022 om 21:13 schreef Paul Gilmartin: >> On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: >>> Gil, that is clever as all get out. Thanks for the idea, though I don't >>> have any immediate use for it myself. That's one to file in the ASM tools >>> bag, >>> >> You're welcome. Except I forgot there's no shift-and-mask instruction. >> >> >> >> On Jan 31, 2022, at 12:56:33, Abe Kornelis wrote: >>> you might consider to use SPM to set the CC in the PSW from the two bits. >>> Then you can use a series of BC instructions to select the desired >>> subsequent action... >>> >> I'd precede that with IPM to preserve the rest of the Program Mask. >> >> If I diid it that way at all. >>
Re: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 01/31/2022 03:13:25 PM: > On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: > > > > Gil, that is clever as all get out. Thanks for the idea, though I > don't have any immediate use for it myself. That's one to file in > the ASM tools bag, > > > You're welcome. Except I forgot there's no shift-and-mask instruction. OK, but I think I get the idea. I could insert the byte into a register, shift out the unwanted bits, and then instead of adding a binary 1 like I said originally you're suggesting I add a zoned 1 and then store character. I'll try that. 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: Making Encoded Bits Human Readable
Gil, you surely should! Abe === Op 31/01/2022 om 21:13 schreef Paul Gilmartin: > On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: >> Gil, that is clever as all get out. Thanks for the idea, though I don't >> have any immediate use for it myself. That's one to file in the ASM tools >> bag, >> > You're welcome. Except I forgot there's no shift-and-mask instruction. > > > > On Jan 31, 2022, at 12:56:33, Abe Kornelis wrote: >> you might consider to use SPM to set the CC in the PSW from the two bits. >> Then you can use a series of BC instructions to select the desired >> subsequent action... >> > I'd precede that with IPM to preserve the rest of the Program Mask. > > If I diid it that way at all. >
Re: Making Encoded Bits Human Readable
On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: > > Gil, that is clever as all get out. Thanks for the idea, though I don't have > any immediate use for it myself. That's one to file in the ASM tools bag, > You're welcome. Except I forgot there's no shift-and-mask instruction. On Jan 31, 2022, at 12:56:33, Abe Kornelis wrote: > > you might consider to use SPM to set the CC in the PSW from the two bits. > Then you can use a series of BC instructions to select the desired > subsequent action... > I'd precede that with IPM to preserve the rest of the Program Mask. If I diid it that way at all. -- gil
Re: Making Encoded Bits Human Readable
Gil, that is clever as all get out. Thanks for the idea, though I don't have any immediate use for it myself. That's one to file in the ASM tools bag, Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, January 31, 2022 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Making Encoded Bits Human Readable On Jan 31, 2022, at 12:31:15, Dave Clark wrote: > >I have two pairs of encoded bits in the high order of a binary > byte. These two pairs (values of 0 to 3, each) actually represent the > numbers 1 to 4 in each case. Now, I know that I could do this the > hard > (long?) way by bit-testing these and come up with the human-readable > zoned equivalents. In fact, I've already done that. > I'm thinking: Isolate a bit-pair with shift-and-mask then AHI C'1' -- 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: Making Encoded Bits Human Readable
"IBM Mainframe Assembler List" wrote on 01/31/2022 02:52:25 PM: > I'm thinking: > Isolate a bit-pair with shift-and-mask > then AHI C'1' I'm not familiar with shift-and-mask. It is not in my PoPs manual. 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: Making Encoded Bits Human Readable
Dave, you might consider to use SPM to set the CC in the PSW from the two bits. Then you can use a series of BC instructions to select the desired subsequent action... Does that make sense without a coded example ? If not, I'll cobble something together for you ... Abe === Op 31/01/2022 om 20:31 schreef Dave Clark: > I have two pairs of encoded bits in the high order of a binary > byte. These two pairs (values of 0 to 3, each) actually represent the > numbers 1 to 4 in each case. Now, I know that I could do this the hard > (long?) way by bit-testing these and come up with the human-readable zoned > equivalents. In fact, I've already done that. > > But, not only do I not like how the code looks in my program, I > also think there should be a shorter way. For example, I could insert the > byte into a register, shift out the unwanted bits, and then add 1 to get > the same numbers -- but in binary. I would then have to > convert-to-decimal and unpack or edit the numbers into zoned format. > > That seems like a bit much. So, is that what I am going to have > to do? ...or stick with bit-testing? ...or is there a better way to > accomplish this? > > Sincerely, > > Dave Clark
Re: Making Encoded Bits Human Readable
On Jan 31, 2022, at 12:31:15, Dave Clark wrote: > >I have two pairs of encoded bits in the high order of a binary > byte. These two pairs (values of 0 to 3, each) actually represent the > numbers 1 to 4 in each case. Now, I know that I could do this the hard > (long?) way by bit-testing these and come up with the human-readable zoned > equivalents. In fact, I've already done that. > I'm thinking: Isolate a bit-pair with shift-and-mask then AHI C'1' -- gil
Making Encoded Bits Human Readable
I have two pairs of encoded bits in the high order of a binary byte. These two pairs (values of 0 to 3, each) actually represent the numbers 1 to 4 in each case. Now, I know that I could do this the hard (long?) way by bit-testing these and come up with the human-readable zoned equivalents. In fact, I've already done that. But, not only do I not like how the code looks in my program, I also think there should be a shorter way. For example, I could insert the byte into a register, shift out the unwanted bits, and then add 1 to get the same numbers -- but in binary. I would then have to convert-to-decimal and unpack or edit the numbers into zoned format. That seems like a bit much. So, is that what I am going to have to do? ...or stick with bit-testing? ...or is there a better way to accomplish this? 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. *
