Re: Complex immediate fields
On 4/18/2024 12:45 PM, Ngan, Robert (DXC Luxoft) wrote: Assuming you have an assembly listing, you just need to look at the "R-Loc" (i.e. offset) value. We use two LOCTR's for data, one for data that needs to be within 4K of the base register, and another for data referenced with relative long, or long displacement instructions. That single base register will handle both LOCTR's. We do exactly the same thing (also using just one base register). It is a GREAT technique. Good for the programmers and good for the machine! -- 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: Complex immediate fields
Assuming you have an assembly listing, you just need to look at the "R-Loc" (i.e. offset) value. We use two LOCTR's for data, one for data that needs to be within 4K of the base register, and another for data referenced with relative long, or long displacement instructions. That single base register will handle both LOCTR's. Robert Ngan DXC/Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, April 15, 2024 22:07 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 4/15/24 20:31:33, Seymour J Metz wrote: > Expect a performance hit if you modify instructions. I like to use LOCTR to > keep data physically remote but visually near the instructions that use them. > . LOCTR is a boon for reading source. Perhaps less so for reading dumps. Are any symbolic debuggers LOCTR-savvy, perhaps assisted by ADATA? -- gil
Re: Complex immediate fields
Gil asked Are instruction pages REFReshable? z/OS does not refresh anything (be that instruction or data), whether the module is identified as refreshable or not. The only thing z/OS now pays attention to with respect to the refreshable option relates to the REFRPROT option, for which the whole pages within a module are page-protected. When made page-protected (outside of a store using a real address) you cannot modify them (whether key 0 or not) - you indicated that, whether the OS supports refreshable or not, that the module can handle it, and a module that can handle being refreshed is treated as one that better not modify itself because at any point it might be refreshed back to a previous state. Peter Relson z/OS Core Technology Design
Re: Complex immediate fields
On 4/15/24 20:31:33, Seymour J Metz wrote: Expect a performance hit if you modify instructions. I like to use LOCTR to keep data physically remote but visually near the instructions that use them. . LOCTR is a boon for reading source. Perhaps less so for reading dumps. Are any symbolic debuggers LOCTR-savvy, perhaps assisted by ADATA? -- gil
Re: Complex immediate fields
Expect a performance hit if you modify instructions. I like to use LOCTR to keep data physically remote but visually near the instructions that use them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Gary Weinhold Sent: Monday, April 15, 2024 2:06 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields From a performance and sometimes readability point of view, having constants (whether instructions or operands), close in memory to the instructions using them is desirable. As Gil mentions, macroes are likely to do it. There ia a data cache and an intruction cache, but there is nothing inherent to prevent a program from modifying the instruction stream or the instruction stream from branching into an area of the program that's in the data cache. (There may be key exceptions that create errors). But any modification to the instruction cache requires the instruction cache line to be moved to the data cache, and any attempt to execute instructions in the data cache requires the cache line to be moved to the instruction cache. I don't think this affects page fault handling. Whether instructions are refreshable depends on external factors, including binder options and characteristics of the load library. I don't know about USS. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://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 Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: April 15, 2024 13:37 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 4/15/24 10:09:06, Charles Mills wrote: > ... > And I would never, ever embed data in the instruction stream. > . I.e. no parameters following the CALL-type instruction? Don't some library macros (still) do this, bypassing with a relative (ugh!) branch instruction? Are instruction pages distinguished from data pages nowadays? Do page faults behave differently between the two? Are instruction pages REFReshable? -- gil
Re: Complex immediate fields
Business needs. The key questions are What is the oldest OS we have to support What is the oldest processor we have to support. Long ago in a galaxy far away I controlled dual passing with SYSPARM, tested by my private macros. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: Monday, April 15, 2024 2:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields Charles is right. IILF was first documented in the -08 level of the POO, for the z114/z196. z/OS 2.2 was the last release to run on that hardware, and has been unsupported since 2020-09-30. The extended mnemonic LFI was added later, but that isn't relevant. I don't understand the reluctance to use newer instructions when they are included in the minimum requirement for the operating system. -- Tom Marchant On Mon, 15 Apr 2024 09:09:06 -0700, Charles Mills wrote: >If you are running "sometimes" on older hardware I think you have a greater >risk from unsupported z/OS than from unsupported instructions. > >I'm not sure, but I think that IILF came along no later than the zEC12. Any >machine older than the zEC12 only supports z/OS V2R2 and below. V2R2 went out >of service almost four years ago. If you are running a current z/OS it won't >run on older hardware. > >I also think you are at greater risk of encountering unsupported instructions >in optimized COBOL 6 code than in hand-built assembler. > >And I would never, ever embed data in the instruction stream. > >Charles > > >-Original Message- >From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On >Behalf Of Jon Perryman >Sent: Sunday, April 14, 2024 11:09 PM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: Complex immediate fields > >> On current hardware there is an IILF (LFI) instruction, and I would like to >>> use it instead of the XR/ICM sequence. > >Before using any modern instructions, ask yourself if they are worth the risk. >Does your disaster recovery site guarantee this as a minimum machine level. >Maybe your employer has older machines available in case of capacity problems. >How about company acquisition. You need to consider the impact. > >>Back in he Assembler XF era I would code something like >> LAR0,L'DEST >> LAR1,DEST >> XRR15,R15 >> ICM R15,8,=C' ' >> MVCL R0,R14 > >Why use LFI when better alternatives for ICM =C' ' have been around forever. >J bydata >data dc A(X'4000',0,L'dest) >bydata LM R15,R1,data > >Since the J instruction only updates the PSW, I'm guessing it will replace the >update PSW in the previous instruction thus making this a single instruction >on current hardware but still compatible with older hardware. > >Alternatively, there is the NILH instruction which has existed for a couple >decades.
Re: Complex immediate fields
Tom, As a vendor, I have many customers on 'unsupported' levels of their operating system. I even have one customer running an OS/390 system running on a z/10. In the VSE arena this is even a bigger issue. I still have customers using Flex boxes and Integrated Servers. I just recently started allowing my company to use LHI instructions. On the other side of the equation, I also know that some customers running the older operating systems may never get current on my software. Thus, I have been slowing adding macros that dual-path during assembly time based on a SETC. If I have a customer does upgrade and report an issue during their testing, I can easily change the SETC in the macro and recreate a new software version with the older instructions. Tony Thigpen Tom Marchant wrote on 4/15/24 2:49 PM: Charles is right. IILF was first documented in the -08 level of the POO, for the z114/z196. z/OS 2.2 was the last release to run on that hardware, and has been unsupported since 2020-09-30. The extended mnemonic LFI was added later, but that isn't relevant. I don't understand the reluctance to use newer instructions when they are included in the minimum requirement for the operating system. -- Tom Marchant On Mon, 15 Apr 2024 09:09:06 -0700, Charles Mills wrote: If you are running "sometimes" on older hardware I think you have a greater risk from unsupported z/OS than from unsupported instructions. I'm not sure, but I think that IILF came along no later than the zEC12. Any machine older than the zEC12 only supports z/OS V2R2 and below. V2R2 went out of service almost four years ago. If you are running a current z/OS it won't run on older hardware. I also think you are at greater risk of encountering unsupported instructions in optimized COBOL 6 code than in hand-built assembler. And I would never, ever embed data in the instruction stream. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman Sent: Sunday, April 14, 2024 11:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. Before using any modern instructions, ask yourself if they are worth the risk. Does your disaster recovery site guarantee this as a minimum machine level. Maybe your employer has older machines available in case of capacity problems. How about company acquisition. You need to consider the impact. Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 Why use LFI when better alternatives for ICM =C' ' have been around forever. J bydata data dc A(X'4000',0,L'dest) bydata LM R15,R1,data Since the J instruction only updates the PSW, I'm guessing it will replace the update PSW in the previous instruction thus making this a single instruction on current hardware but still compatible with older hardware. Alternatively, there is the NILH instruction which has existed for a couple decades.
Re: Complex immediate fields
Charles is right. IILF was first documented in the -08 level of the POO, for the z114/z196. z/OS 2.2 was the last release to run on that hardware, and has been unsupported since 2020-09-30. The extended mnemonic LFI was added later, but that isn't relevant. I don't understand the reluctance to use newer instructions when they are included in the minimum requirement for the operating system. -- Tom Marchant On Mon, 15 Apr 2024 09:09:06 -0700, Charles Mills wrote: >If you are running "sometimes" on older hardware I think you have a greater >risk from unsupported z/OS than from unsupported instructions. > >I'm not sure, but I think that IILF came along no later than the zEC12. Any >machine older than the zEC12 only supports z/OS V2R2 and below. V2R2 went out >of service almost four years ago. If you are running a current z/OS it won't >run on older hardware. > >I also think you are at greater risk of encountering unsupported instructions >in optimized COBOL 6 code than in hand-built assembler. > >And I would never, ever embed data in the instruction stream. > >Charles > > >-Original Message- >From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On >Behalf Of Jon Perryman >Sent: Sunday, April 14, 2024 11:09 PM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: Complex immediate fields > >> On current hardware there is an IILF (LFI) instruction, and I would like to >>> use it instead of the XR/ICM sequence. > >Before using any modern instructions, ask yourself if they are worth the risk. >Does your disaster recovery site guarantee this as a minimum machine level. >Maybe your employer has older machines available in case of capacity problems. >How about company acquisition. You need to consider the impact. > >>Back in he Assembler XF era I would code something like >> LAR0,L'DEST >> LAR1,DEST >> XRR15,R15 >> ICM R15,8,=C' ' >> MVCL R0,R14 > >Why use LFI when better alternatives for ICM =C' ' have been around forever. >J bydata >data dc A(X'4000',0,L'dest) >bydata LM R15,R1,data > >Since the J instruction only updates the PSW, I'm guessing it will replace the >update PSW in the previous instruction thus making this a single instruction >on current hardware but still compatible with older hardware. > >Alternatively, there is the NILH instruction which has existed for a couple >decades.
Re: Complex immediate fields
>From a performance and sometimes readability point of view, having constants >(whether instructions or operands), close in memory to the instructions >using them is desirable. As Gil mentions, macroes are likely to do it. There >ia a data cache and an intruction cache, but there is nothing inherent to >prevent a program from modifying the instruction stream or the instruction >stream from branching into an area of the program that's in the data cache. >(There may be key exceptions that create errors). But any modification to the >instruction cache requires the instruction cache line to be moved to the data >cache, and any attempt to execute instructions in the data cache requires the >cache line to be moved to the instruction cache. I don't think this affects >page fault handling. Whether instructions are refreshable depends on external >factors, including binder options and characteristics of the load library. I >don't know about USS. 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 Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: April 15, 2024 13:37 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 4/15/24 10:09:06, Charles Mills wrote: > ... > And I would never, ever embed data in the instruction stream. > . I.e. no parameters following the CALL-type instruction? Don't some library macros (still) do this, bypassing with a relative (ugh!) branch instruction? Are instruction pages distinguished from data pages nowadays? Do page faults behave differently between the two? Are instruction pages REFReshable? -- gil
Re: Complex immediate fields
On 4/15/24 10:09:06, Charles Mills wrote: ... And I would never, ever embed data in the instruction stream. . I.e. no parameters following the CALL-type instruction? Don't some library macros (still) do this, bypassing with a relative (ugh!) branch instruction? Are instruction pages distinguished from data pages nowadays? Do page faults behave differently between the two? Are instruction pages REFReshable? -- gil
Re: Complex immediate fields
If you are running "sometimes" on older hardware I think you have a greater risk from unsupported z/OS than from unsupported instructions. I'm not sure, but I think that IILF came along no later than the zEC12. Any machine older than the zEC12 only supports z/OS V2R2 and below. V2R2 went out of service almost four years ago. If you are running a current z/OS it won't run on older hardware. I also think you are at greater risk of encountering unsupported instructions in optimized COBOL 6 code than in hand-built assembler. And I would never, ever embed data in the instruction stream. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman Sent: Sunday, April 14, 2024 11:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields > On current hardware there is an IILF (LFI) instruction, and I would like to >> use it instead of the XR/ICM sequence. Before using any modern instructions, ask yourself if they are worth the risk. Does your disaster recovery site guarantee this as a minimum machine level. Maybe your employer has older machines available in case of capacity problems. How about company acquisition. You need to consider the impact. >Back in he Assembler XF era I would code something like > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 Why use LFI when better alternatives for ICM =C' ' have been around forever. J bydata data dc A(X'4000',0,L'dest) bydata LM R15,R1,data Since the J instruction only updates the PSW, I'm guessing it will replace the update PSW in the previous instruction thus making this a single instruction on current hardware but still compatible with older hardware. Alternatively, there is the NILH instruction which has existed for a couple decades.
Re: Complex immediate fields
> On current hardware there is an IILF (LFI) instruction, and I would like to >> use it instead of the XR/ICM sequence. Before using any modern instructions, ask yourself if they are worth the risk. Does your disaster recovery site guarantee this as a minimum machine level. Maybe your employer has older machines available in case of capacity problems. How about company acquisition. You need to consider the impact. >Back in he Assembler XF era I would code something like > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 Why use LFI when better alternatives for ICM =C' ' have been around forever. J bydata data dc A(X'4000',0,L'dest) bydata LM R15,R1,data Since the J instruction only updates the PSW, I'm guessing it will replace the update PSW in the previous instruction thus making this a single instruction on current hardware but still compatible with older hardware. Alternatively, there is the NILH instruction which has existed for a couple decades.
Re: Complex immediate fields
> On current hardware there is an IILF (LFI) instruction, and I would like to > use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? For a space, the simplest method is: LFI R15,C' '*X'100' For a general byte value, if you want to use a macro or similar, you need to avoid arithmetic overflow, for example: MACRO LC1 , LFI ,((()/128)*256)*X'100' MEND ... LC1 R15,C'9' ... LC1 R1,X'FF' The architects agreed to our request that HLASM could add the more helpful alias LFI for IILF as part of the Z16 instruction set in 2022, and they also added LLGFI an an alias for LLILF. We were subsequently asked why we hadn't added LLGHI as an alias for LLILL, so we will probably add that in a future upgrade. Jonathan Scott, HLASM IBM Hursley, UK
Re: Complex immediate fields
When I compose a reply in Gmail, I have a fixed width font option. Does it come through below? (It would be really swell if the Assembler List knew about a fixed-width font for such examples.) LISTUSE MAIN ESD=0001 LOC= LEN=01000 REG=F OFF=0 LAB= 00 (1/12)10 WIPE BUF,C'A' 00 4100F01010(1/3)11+ LA0,BUF 04 A7180200 (1/4)12+ LHI 1,L'BUF 08 C029C10000(1/5)13+ LFI 2,C'A'*X'100' 0E 0E02 (1/6)14+ MVCL 0,2 10 (1/14)16 BUF DSCL512 000210 (1/15)17 END On Fri, Mar 29, 2024 at 4:47 PM Dan Greiner wrote: > The example I illustrated with the macro does not appear to have the > overflow issue that Robert mentions ... at least, not with the z390 > assembler. A slightly modified example (with LHI instead of LA) follows: > > Assembler Listing > 00(1/1)1 MACRO > 00(1/2)2WIPE > , > 00(1/3)3LA0, > 00(1/4)4 LHI > 1,L' > 00(1/5)5 LFI > 2,*X'100' > 00(1/6)6 MVCL 0,2 > 00(1/7)7 MEND > 00(1/9)8 MAIN CSECT > 00 (1/10)9 USING MAIN,15 > LISTUSE MAIN ESD=0001 LOC= LEN=01000 REG=F OFF=0 LAB= > 00 (1/12)10 WIPE > BUF,C'A' > 00 4100F01010(1/3)11+ LA0,BUF > 04 A7180200 (1/4)12+ LHI 1,L'BUF > 08 C029C10000(1/5)13+ LFI > 2,C'A'*X'100' > 0E 0E02 (1/6)14+ MVCL 0,2 > 10 (1/14)16 BUF DSCL512 > 000210 (1/15)17 END > > (It would be really swell if the Assembler List knew about a fixed-width > font for such examples.) >
Re: Complex immediate fields
Wow. Truly impressive. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Mar 29, 2024, 7:48 PM Ngan, Robert (DXC Luxoft) wrote: > When I first saw "Complex immediate fields", I thought of this code one of > our emulation macros used to generate: > > CGIJL R01,132-(L'BKwa_Module+1+L'BK_LPAOS+1),BK250 > + CGHI R01,(1-132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'X > + BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(L'BKX > + wa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LX > + PAOS+1))/256)*256)+256)/256)*256)/128))*(((132-(L'BKwa_MX > + odule+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPAOSX > + +1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOS+1X > + ))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256)/X > + 256)*256)+132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-X > + (L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(LX > + 'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BX > + K_LPAOS+1))/256)*256)+256)/256)*256)/128)*132-(L'BKwX > + a_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPX > + AOS+1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOX > + S+1))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+25X > + 6)/256)*256)-256)+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))+X > + 2147483520)*0+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))-2147X > + 483520)*0Emulated z10 CGIJL instruction > + JLBK250 ... > > > Robert Ngan > DXC Luxoft > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Seymour J Metz > Sent: Friday, March 29, 2024 11:57 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Complex immediate fields > > Back in he Assembler XF era I would code something like > > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 > > On current hardware there is an IILF (LFI) instruction, and I would like > to use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >
Re: Complex immediate fields
When I first saw "Complex immediate fields", I thought of this code one of our emulation macros used to generate: CGIJL R01,132-(L'BKwa_Module+1+L'BK_LPAOS+1),BK250 + CGHI R01,(1-132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'X + BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(L'BKX + wa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LX + PAOS+1))/256)*256)+256)/256)*256)/128))*(((132-(L'BKwa_MX + odule+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPAOSX + +1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOS+1X + ))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256)/X + 256)*256)+132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-X + (L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(LX + 'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BX + K_LPAOS+1))/256)*256)+256)/256)*256)/128)*132-(L'BKwX + a_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPX + AOS+1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOX + S+1))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+25X + 6)/256)*256)-256)+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))+X + 2147483520)*0+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))-2147X + 483520)*0Emulated z10 CGIJL instruction + JLBK250 ... Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 11:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
The example I illustrated with the macro does not appear to have the overflow issue that Robert mentions ... at least, not with the z390 assembler. A slightly modified example (with LHI instead of LA) follows: Assembler Listing 00(1/1)1 MACRO 00(1/2)2WIPE , 00(1/3)3LA0, 00(1/4)4 LHI 1,L' 00(1/5)5 LFI 2,*X'100' 00(1/6)6 MVCL 0,2 00(1/7)7 MEND 00(1/9)8 MAIN CSECT 00 (1/10)9 USING MAIN,15 LISTUSE MAIN ESD=0001 LOC= LEN=01000 REG=F OFF=0 LAB= 00 (1/12)10 WIPE BUF,C'A' 00 4100F01010(1/3)11+ LA0,BUF 04 A7180200 (1/4)12+ LHI 1,L'BUF 08 C029C10000(1/5)13+ LFI 2,C'A'*X'100' 0E 0E02 (1/6)14+ MVCL 0,2 10 (1/14)16 BUF DSCL512 000210 (1/15)17 END (It would be really swell if the Assembler List knew about a fixed-width font for such examples.)
Re: Complex immediate fields
The example I illustrated with the macro does not appear to have the overflow issue that Robert mentions ... at least, not with the z390 assembler: Assembler Listing 00(1/1)1 MACRO 00(1/2)2WIPE , 00(1/3)3LA0, 00(1/4)4 LHI 1,L' 00(1/5)5 LFI 2,*X'100' 00(1/6)6 MVCL 0,2 00(1/7)7 MEND 00(1/9)8 MAIN CSECT 00 (1/10)9 USING MAIN,15 LISTUSE MAIN ESD=0001 LOC= LEN=01000 REG=F OFF=0 LAB= 00 (1/12)10 WIPE BUF,C'A' 00 4100F01010(1/3)11+ LA0,BUF 04 A7180200 (1/4)12+ LHI 1,L'BUF 08 C029C10000(1/5)13+ LFI 2,C'A'*X'100' 0E 0E02 (1/6)14+ MVCL 0,2 10 (1/14)16 BUF DSCL512 000210 (1/15)17 END (It would be really swell if the Assembler List knew about a fixed-width font for such examples.)
Re: Complex immediate fields
I did not realize that one of your objections was having to code x'40' when what you meant was c' '. >From the feedback I got, LFI R15,C' '*ShiftLeft24 should work but LFI >R15,C'A'*ShiftLeft24 will not due to overflow. What about SETC BYTE(0) LFI C' ' I am not a proficient macro language hacker. Will the above compile? If not, will something like that? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 2:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields I'll have to try that once I get my userid back. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Friday, March 29, 2024 3:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields What about (untested) ShiftLeft24 EQU x'100' LFI R15,X'40'*ShiftLeft24 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
I'll have to try that once I get my userid back. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Friday, March 29, 2024 3:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields What about (untested) ShiftLeft24 EQU x'100' LFI R15,X'40'*ShiftLeft24 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
Good catch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Dan Greiner Sent: Friday, March 29, 2024 1:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields Seymour, You usage of the even/odd R0/R1 pair appears to be reversed (unless you intended to zero some memory at whatever location L'DEST resolves to ... not to worry, it happens to dyslexic programmers like me all the time). I don't know of any means by which you can split the definition of an immediate field such as you suggest, and I'm not sure I'd welcome that sort of complexity for what is otherwise a relatively simple concept: immediacy.
Re: Complex immediate fields
Back in the day the PDP-6 looked coll. MAP in IBSYS/IBJOB also had a feature that I would love to see in HLASM: the QUAL pseudo-op. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, March 29, 2024 1:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 3/29/24 10:56:49, Seymour J Metz wrote: > Ba... I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > Is LOCTR any help? (You would have loved the PDP-6 immediate facility. An immediate value could be any sequence of instructions and constants.) -- gil
Re: Complex immediate fields
That still uses hex notation for character data, which is what I'm trying to avoid. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Tom Harper <16c16a7381bc-dmarc-requ...@listserv.uga.edu> Sent: Friday, March 29, 2024 1:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields Seymour, How about this: LLILH R15,X’4000’ Tom Harper Phoenix Software International Sent from my iPhone > On Mar 29, 2024, at 12:56 PM, Seymour J Metz wrote: > > Back in he Assembler XF era I would code something like > > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 > > On current hardware there is an IILF (LFI) instruction, and I would like to > use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר 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: Complex immediate fields
That fails with an arithmetic overflow if the byte value has the high order bit set. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Friday, March 29, 2024 14:27 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields What about (untested) ShiftLeft24 EQU x'100' LFI R15,X'40'*ShiftLeft24 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
What about (untested) ShiftLeft24 EQU x'100' LFI R15,X'40'*ShiftLeft24 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
How about if you define the immediate field by simply multiplying the fill character by 16 megs? Assuming that the destination symbol has an implicit length, you could encapsulate this into a macro with just the destination and fill character as operands: MACRO WIPE , LA0, LA1,L' LFI 2,*X'100' MVCL 0,2 MEND Seems to assemble okay.
Re: Complex immediate fields
On 3/29/24 10:56:49, Seymour J Metz wrote: Ba... I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? Is LOCTR any help? (You would have loved the PDP-6 immediate facility. An immediate value could be any sequence of instructions and constants.) -- gil
Re: Complex immediate fields
Seymour, How about this: LLILH R15,X’4000’ Tom Harper Phoenix Software International Sent from my iPhone > On Mar 29, 2024, at 12:56 PM, Seymour J Metz wrote: > > Back in he Assembler XF era I would code something like > > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 > > On current hardware there is an IILF (LFI) instruction, and I would like to > use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר 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: Complex immediate fields
Seymour, You usage of the even/odd R0/R1 pair appears to be reversed (unless you intended to zero some memory at whatever location L'DEST resolves to ... not to worry, it happens to dyslexic programmers like me all the time). I don't know of any means by which you can split the definition of an immediate field such as you suggest, and I'm not sure I'd welcome that sort of complexity for what is otherwise a relatively simple concept: immediacy.
