As the OP, the version leveraging a similar instruction is infinitely more
useful to me as it allows the assembler to deal with the multitude of operand
formats rather than making me have to.

i

------ Original Message ------
Received: 04:16 PM COT, 12/21/2013
From: Mark Boonie <[email protected]>
To: [email protected]
Subject: Re: macros to implement opcodes

> Stepping back from everything that's already been suggested, when I wrote
> this from scratch, I used something simpler:
>
>          MACRO ,
> &LABEL   DIAG  &RX,&RY,&DISP
> &LABEL   DC    0H,X'83',AL.4(&RX,&RY),Y(&DISP)
>          MEND  ,
>
> The overwriting of another instruction seems unneccesarily complex.  I'm
> guessing that the intent was to allow the assembler to produce register
> cross-reference entries, but some Diags use only Rx and not Ry, some use an
> implied Rx+1 and Ry+1, etc., which means that (the lack of) any
> cross-reference entries can't be trusted anyway.  If the overwriting was
> done for another reason, hopefully someone will let me know.
>
> - mb
>
> IBM Mainframe Assembler List <[email protected]> wrote on
> 12/21/2013 03:11:29 PM:
>
> > From: Mark Boonie/Poughkeepsie/IBM@IBMUS
> > To: [email protected],
> > Date: 12/21/2013 03:14 PM
> > Subject: Re: macros to implement opcodes
> > Sent by: IBM Mainframe Assembler List <[email protected]>
> >
> > Like John Gilmore, I (strongly) dislike hard-coded 3's and 4's,
> especially
> > when a macro generates several instructions that must be ORG'ed into and
> > around.  Labels are our friends.  If I were writing this macro and found
> > that the user-supplied label was optional, I would probably write code to
> > generate my own label and ORG to that.  In fact, I'd probably also define
> a
> > label that follows the generated instruction and ORG back to that.  But,
> I
> > would hazard a guess that these are techniques that most of us are
> already
> > aware of.
> >
> > - mb
> >
> > IBM Mainframe Assembler List <[email protected]> wrote on
> > 12/21/2013 01:20:48 PM:
> >
> > > From: John Gilmore <[email protected]>
> > > To: [email protected],
> > > Date: 12/21/2013 01:23 PM
> > > Subject: Re: macros to implement opcodes
> > > Sent by: IBM Mainframe Assembler List <[email protected]>
> > >
> > > Steve Comstock wrote:
> > >
> > > <begin extract>
> > > Neither version is bullet proof, but Ed's works in both cases of a
> > > label supplied or not (neither of which is an error, so 'bullet
> > > proofing' for a missing  label is really irrelevant).
> > > </end extract>
> > >
> > > and this---Let me quote him---is
> > >
> > > Nonsense!
> > >
> > > When someone writes a macro definition he or she is free to make the
> > > omission of or a putatively inappropriate value of any symbolic
> > > parameter an error, as I did with the skeletal sample lines that
> > > tested for the presence or absence of a label in the DIAG macro
> > > instruction.   In general the omission of a label may be innocuous in
> > > one context and a severe error in another, in the judgment of the
> > > writer of a particular macro instruction.
> > >
> > > Bullet proofing is never irrelevant.  It is tedious, certainly; but
> > > the only appropriate stance for the writer of a production macro
> > > definition is that those who write macro instructions that use it will
> > > be ignorant, malicious or perhaps both.
> > >
> > > Ed Jaffe's point is more substantial; but, as he well knows, there are
> > > simple ways to guard against the difficulty he raised.  Indeed, there
> > > are alternative ways to induce the assembler to do the necessary
> > > arithmetic without resort to the magic numbers 3 and 4,  which still
> > > seem to me to be ugly.
> > >
> > > I do not at all mind being ganged up upon.  Let's do it again sometime
> > soon.
> > >
> > >
> > > John Gilmore, Ashland, MA 01721 - USA
> > >

Reply via email to