Binyamin, as others have pointed out, no such option exists. But: you can roll your own, if you want to! I built a prototype, and it works like a charm.
Here's what I did: 1) replace EQU with a macro. Register all register equates in a set of GBLx tables. Thus, even MY_DCB_POINTER can be used as a register name and the code will know it. 2) Create a USE macro that encapsulates USING. Again, keep track of status in GBLx arrays. Where others employ a DUMMY using, I employ a USE without target address to declare a register as occupied. 3) sidestep, please forgive my verbosity: With these two in place, it is possible to create a macro that will allocate a register upon request. I use &label EQUREG options to have the assembler allocate an available register at pre-assembly time. 4) I built a LR macro to replace the LR opcode. it will diagnose unnecessary LR instructions, such as LR R5,MY_REG where MY_REG happens to equ R5. It could be enhanced to check for registers declared protected on your version of the USE macro. 5) This macro should be converted into a template, such that macros for all register-modifying opcodes can be generated. You certainly do not desire to maintain all of those manually :-( Generating these on the flight is possible using STACK instructions. I'm sure I've missed some important details. I built this stuff 18 years ago... But you're experienced enough to do get the drift. Kind regards & Happy programming! Abe Kornelis ========== Op 25/06/2018 om 17:49 schreef Binyamin Dissen: > Since the assembler knows which instructions modify which registers, it would > be nice if there was a way to "protect" a register for a code range. > > Perhaps > > USING area,Rx,protect > > Any alteration of the register until the DROP would cause a warning message on > the instruction. > > Or might such an option exist? > > -- > Binyamin Dissen <bdis...@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. >
