Well known. But the instruction I’m proposing has no registers involved (other than base displacement) and thus there is no way to restart the instruction to complete the process.
So to avoid that, limiting it to 256 bytes removed that as an issue. Sent from my iPhone > On Apr 15, 2022, at 9:45 AM, Seymour J Metz <sme...@gmu.edu> wrote: > > You can have interruptability without an arbitrary length restriction; CLCL > and MVCL work just fine. All that you need is that the instruction be > resumeable and for the hardware/microcode/millicode to periodically check for > pending interrupts and update the registers as needed > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Robin Vowels [robi...@dodo.com.au] > Sent: Friday, April 15, 2022 5:08 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Next instruction needed > > ----- Original Message ----- > From: "Tom Harper" <tomhar...@phoenixsoftware.com> > To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > Sent: Friday, April 15, 2022 3:06 AM > > >> IMHO, the next instruction to add to z/Architecture would be an instruction >> to clear storage to >> zeros. > >> Right now a number of methods are in widespread use, none of which are clean >> and simple. I mean, >> it’s been almost sixty years. > >> MVCL takes three registers to set up beforehand; > > So? Write yourself a macro. > >> XC sets the condition code and is not variable length, and the overlapping >> MVC is a kluge > > But it does the job well. > >> and not variable length either. > > Use Ex. > >> An EX instruction is also a kluge. > >> All you need is the address and length to accomplish this, preferably in two >> versions, >> one with an immediate operand for the length > > Really?! A few lines ago, you were decrying XC and MVC because they have a > "fixed length". > >> and another which uses, for example, a register, perhaps register zero. A >> long displacement would >> be a plus. > > To avoid issues with interruptibility, the length would need to be limited to > 256 bytes. > > What? Back to a limit of 256? what's the point of that? > MVCL will do as long as you want. > >> I don’t think the length restriction would be an issue in most cases. > > There's no point in having an instruction with a length restrictionof 256. > >> Such an instruction might look like this: > >> CLEAR FieldA > >> Or > >> LLGF R0,Varlen >> CLEARR > > A macro reference would require one line. > >> Similar instructions for compare logical and move would be nice as well. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirus&data=05%7C01%7Csmetz3%40gmu.edu%7C321a88f8873f489ae2aa08da1ebf8695%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637856105217726958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1YlHbddJyGWkzKpajlykSLpgYc4F%2B%2BF26AYQ%2FgecQ78%3D&reserved=0 -------------------------------------------------------------------------------- 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.
