Re: Destructive Overlap (Was: MVCRL)
On Jun 9, 2022, at 09:11:44, Ed Jaffe wrote: ... Reverse-sequence tables are counterintuitive; harder to understand and debug, but their use has always been worthwhile in light of the performance gains. You needn't keep the table in reverse sequence; merely keep the unused space at the front rather than the back. An additional pointer reference may be necessary too get to the front. -- gil
Re: Destructive Overlap (Was: MVCRL)
Ed, >> it will be fun to be able to use it someday (if I live that long...) I thought the very same - but it is easier for me- It is an excellent instruction when you need to extent an object (of a PDF-file) in the middle. Had to use a work-area with a length of the rest of the object- But hey- wait a second! Why is there that silly(IMHO) restriction of only the last byte of R0 can be the length(=256)? Martin
Destructive Overlap (Was: MVCRL)
On 6/8/2022 6:06 AM, Jonathan Scott wrote: Please note that there is already an instruction with the mnemonic MVCRL, "Move right to left", used to shift up data to make a gap for inserting new data. Destructive overlap is often quite useful (for clearing fields, etc), but it's a PITA when you need to insert an entry into the middle of a sequentially-organized table. I have for decades ordered such tables backwards (in reverse address order) to facilitate better-performing inserts using MVCL. Reverse-sequence tables are counterintuitive; harder to understand and debug, but their use has always been worthwhile in light of the performance gains. The MVCRL instruction (new with z15) is only about four decades too late for me. Still, it will be fun to be able to use it someday (if I live that long...) -- 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: Subject: MVCRL
Also, CLCL and MVCL are interruptable and resumeable; an interrupt leaves the registers updated for resumption. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Thursday, June 9, 2022 8:47 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Subject: MVCRL Why isn't there a Move Relative Long instruction The answer is likely because there is insufficient reason to have one, to justify the cost. Instructions are typically created when they solve a problem and, often, when they can be done faster if implemented in the machine than if done piece by piece in a program (which, surprising to some, is not necessarily the case if the instruction is implemented in millicode). Why can't you simply use MVCL (or MVCLE), having set up the address operands using LARL if they are relatively addressable (as long as a halfword boundary is OK as a limitation)? Any instruction that needs two fully defined addresses (think of an SS-type instruction such as MVC) has limited space for additional information (such as a length). The instruction length is limited to 6 bytes. You need at least 2 bytes for base+displacement or for the offset if relatively addressing, for each of the two operands. You need at least 1 byte for the opcode. That leaves you one byte for everything else. MVCL has a lot of "everything else". That is why MVCL has its operands in double-reg pairs. So would any other MVCL-like thing. So the approach for using a hypothetical move-long-relative would be the same as using MVCL, just using LARL where needed. And once the setup has been done, there is no need for a new instruction. Peter Relson z/OS Core Technology Design
Re: Subject: MVCRL
Why isn't there a Move Relative Long instruction The answer is likely because there is insufficient reason to have one, to justify the cost. Instructions are typically created when they solve a problem and, often, when they can be done faster if implemented in the machine than if done piece by piece in a program (which, surprising to some, is not necessarily the case if the instruction is implemented in millicode). Why can't you simply use MVCL (or MVCLE), having set up the address operands using LARL if they are relatively addressable (as long as a halfword boundary is OK as a limitation)? Any instruction that needs two fully defined addresses (think of an SS-type instruction such as MVC) has limited space for additional information (such as a length). The instruction length is limited to 6 bytes. You need at least 2 bytes for base+displacement or for the offset if relatively addressing, for each of the two operands. You need at least 1 byte for the opcode. That leaves you one byte for everything else. MVCL has a lot of "everything else". That is why MVCL has its operands in double-reg pairs. So would any other MVCL-like thing. So the approach for using a hypothetical move-long-relative would be the same as using MVCL, just using LARL where needed. And once the setup has been done, there is no need for a new instruction. Peter Relson z/OS Core Technology Design
