The responses to my post did not address the problem I thought was being discussed. Tom Marchant's post seems to me to recommend that a macro definition, call it M, that modifies any or all of registers 1, 4, or 15 without bracketing all such changes with a push/pop or the like for it or them should contain a DROP for each of these registers that it modifies.
We were, I thought, talking about what should/could could be done during the execution of an M macro instruction; and my point was that there is not enough information obtainable within a macro definition to make Tom's proto-recommendation feasible. The other question, how to protect oneself from an ill-behaved macro, is interesting too; and John Ehrman's construct | drop , in one that I had not seen before; but the two questions are very different ones. John Gilmore Ashland, MA 01721-1817 USA > Date: Mon, 11 Jul 2011 14:04:55 -0700 > From: [email protected] > Subject: Re: Annoyance with the IEZJSAB macro > To: [email protected] > > John Gilmore commented on Tom Marchant's query: > > > Tom Marchant wrote: > > > > <begin snippet> > > > I might go so far as to contend that whenever a macro alters registers > 1, 14, or 15 it should issue a drop for those registers if there is an > active using. Unfortunately, AFAIK, there is no way to do this. > > > </end snippet> > > > Fortunately, in my view, he is quite right that there is no way to do > this. > > This technique sometimes works: > > PUSH USING Save current USINGs > DROP , Drop all registers > - - - Call the ill-behaved macro > POP USING Restore original USINGs > > If the ill-behaved macro requires local addressability, establish a local > base register; it will be DROPped automatically by the POP USING.
