Peter, I understand what you're asking. This particular macro does more than simply generate a CLC. It supports various optional keyword parameters that make it do different things. The one constant: no matter what it's doing, it always operates on a two-byte field. That's why I'd rather not force the caller to provide the explicit length of 2.
But it's actually more complicated than that. Sometimes instead of generating a CLC, the macro does something different. In particular, it might generate an LLHH. The macro includes this statement (controlled by conditional assembly): LLHH R0,&FIELD1 That's fine, provided that the caller specifies &FIELD1 as a relocatable address *without* an explicit length. But if an explicit length of 2 is provided on the parameter, then that length value is interpreted by the assembler as *index register 2* in the generated LLHH instruction. That's obviously a disaster. I protect against that by generating a DC S(&FIELD1) in the macro and ORGing back over it. That way, the assembler complains if an explicit length *is* present. That seemed a reasonable approach. In any event, that's where my original question comes from (for better or worse). David On Mon, 26 Feb 2024 16:27:20 +0000, Farley, Peter <[email protected]> wrote: >David, > >Maybe you are approaching this from the wrong perspective. Why isn’t it >incumbent on your macro users to code the length for you? Why does your macro >have to be the one to figure out what to do? > >OTOH, there are IBM “inner” macros which are used in various externally >documented macros that are responsible for picking apart arguments and >translating them into “correct” symbols for an instruction. In particular I >think there are one or more IHBIN* macros with similar responsibilities >(decode (an) argument(s) for the outer macro), so perhaps one of them can do >the work for you, or at least serve as a source of inspiration for you to code >your own version. Such macro code is tedious to write and debug, but the >problem of decoding “arbitrary” arguments is not new and has certainly already >been solved by IBM. Might be worth investigating, anyway. > >Peter > >From: IBM Mainframe Assembler List <[email protected]> On Behalf >Of David Eisenberg >Sent: Monday, February 26, 2024 9:47 AM >To: [email protected] >Subject: Re: Macro parameters: parsing a relocatable address > > >Well, it's a CLC (not an MVC)... but I understand your solution. With that >approach, and PRINT NOGEN is in effect, I get this in the listing: > > > > Loc Object Code Addr1 Addr2 > >0002AC D501 0000 0000 00000 00000 > > > >and what I'm trying to do (if possible) is to show the relocatable addresses >under Addr1 and Addr2 in the listing alongside the D501. I.e., I'd like to >generate a single CLC instruction, so that it looks that way in the printed >object code. (I realize that PRINT NOGEN would show the addresses in the >expansion, but they still wouldn't appear on the same line as the CLC opcode.) >So far, the best solution I've come up with is my approach # 2 below (a single >DC statement) which produces: > > > > Loc Object Code Addr1 Addr2 > >0002AC D501BE65BE63 > > > >That's not bad, but the assembler treats it like a DC (which it is), and not a >machine instruction... and it looks like a DC in the object code. > > > >The reason I'm generating the CLC in a macro is because the macro is doing >much more than this. There are various macro keyword parameters that I haven't >bothered showing here, and lots of analysis going on with the comparands >before I generate the CLC. I genuinely believe that showing all those things >here would only serve to complicate my question. > > > >David > > > >On Mon, 26 Feb 2024 13:44:17 +0000, Seymour J Metz ><[email protected]<mailto:[email protected]>> wrote: > > > >>Why? What are you trying to solve by wrappng the MVC in a macro? > >> > >> MVC 0(2),0 > >> ORG *-4 > >> DC S(&OP1) > >> DC S(&OP2) > >> > >>but, again, why? > >> > >>-- > >>Shmuel (Seymour J.) Metz > >>https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!JyaTP2bKZR-gA1rIwn_R2ehzHljIr3u3vpWygK3ogqeegxcRzrPuZujPPzVM7n_uWXoUxOk_iSNN0FD5_antrAM-TfrW0Q$<https://urldefense.com/v3/__http:/mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!JyaTP2bKZR-gA1rIwn_R2ehzHljIr3u3vpWygK3ogqeegxcRzrPuZujPPzVM7n_uWXoUxOk_iSNN0FD5_antrAM-TfrW0Q$> > >>עַם יִשְׂרָאֵל חַי > >>נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > >> > >>________________________________________ > >>From: IBM Mainframe Assembler List >><[email protected]<mailto:[email protected]>> on >>behalf of David Eisenberg >><[email protected]<mailto:[email protected]>> > >>Sent: Monday, February 26, 2024 8:22 AM > >>To: [email protected]<mailto:[email protected]> > >>Subject: Macro parameters: parsing a relocatable address > >> > >>I’m seeking some guidance if anyone is able to help. I’d like to write a >>macro like this: > >> > >>&NAME MYCLC &FIELD1,&FIELD2 > >> > >>in which both &FIELD1 and &FIELD2 are relocatable addresses. It’s &FIELD1 >>that is of particular interest to me. &FIELD1 might be expressed as a >>hard-coded displacement and base register, or a relocatable symbol… or it >>could be an absolute symbol equivalent to a displacement, followed by a base >>register… etc. I.e., it could be any valid relocatable address syntax. What >>&FIELD1 will *not* have is an *explicit length.* The macro parameters will >>specify valid relocatable addresses, and nothing more. > >> > >>My question: I’d like the MYCLC macro to generate a CLC instruction in which >>the two parameters are compared to each other for a constant length of 2. So >>far, the only ways I can think of to do this are: > >> > >>1. Parse &FIELD1 to figure out how the relocatable address is expressed, and >>insert an explicit length of 2 to generate a valid CLC first operand. I would >>do it that way, but (unless I'm missing something) it seems quite complex to >>code. > >>2. Generate this DC statement: DC X’D501’,S(&FIELD1,&FIELD2) . This seems to >>work, but it’s a bit unattractive in a PRINT GEN (and it looks a bit odd in >>the assembly listing, because the assembler doesn't treat it like a machine >>instruction in the object code on the left side of the listing). > >> > >>I’m wondering if anyone can suggest a reasonable way to code option 1 above. >>Can the macro assembler give me any help in parsing &FIELD1 so that I can >>transform that parameter to insert an explicit length, regardless of how >>&FIELD1 is expressed? Or is there some other approach that I haven’t >>considered at all? Or should I just go with option 2 above? > >> > >>Please note that I don’t want the macro to generate more than one machine >>instruction. One way or another, I just want the macro to generate a CLC for >>a length of 2. (And I really do want the CLC located in the macro as opposed >>to open code, because the macro does some analysis on the comparands prior to >>generating the CLC.) > >> > >>Any advice would be appreciated... thank you! > >> > >>David > >-- > > > >This message and any attachments are intended only for the use of the >addressee and may contain information that is privileged and confidential. If >the reader of the message is not the intended recipient or an authorized >representative of the intended recipient, you are hereby notified that any >dissemination of this communication is strictly prohibited. If you have >received this communication in error, please notify us immediately by e-mail >and delete the message and any attachments from your system.
