Conceptually,the MVCL instruction could treat cases that specified the same register pair for source and target operands as a request to clean or fill the designated storage area.
Keven Sent from my iPhone > On Apr 15, 2022, at 13:54, Mike Hochee <[email protected]> wrote: > > I apparently stopped reading before the 'limited to 256' statement in the > original post and incorrectly assumed it covered long moves as well, since > you mentioned MVCL* type instructions (of course they cover all lengths). I > see it being a lot more useful if it had long capabilities. > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Tom Harper > Sent: Friday, April 15, 2022 2:19 PM > To: [email protected] > Subject: Re: Next instruction needed > > Caution! This message was sent from outside your organization. > > I think that is unnecessary because the proposal is only for one to 256 bytes > so no need to make it interruptible. If you want to use for longer areas, use > a move long. > > Many instructions have been added over the years for small items. This would > find significant use as soon as the instruction would become available > without dual pathing. > > The cost to implement should be minimal. > > Sent from my iPhone > >>> On Apr 15, 2022, at 1:51 PM, Paul Gilmartin >>> <[email protected]> wrote: >>> >>> On Apr 15, 2022, at 11:34:40, Tom Harper wrote: >>> >>> If it was interrupted, where would the hardware restart? The instruction >>> itself cannot be changed. >>> >> Make it an RFE. Support it with a business case, that it would >> provide added value to end users inducing them to spend more on IBM >> equipment than the engineering cost of developing the new hardware. >> >> -- >> gil > > > -------------------------------------------------------------------------------- > 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.
