Quote:
My example is simple but there is a reason for my wanting to do this.
Let's say I wanted to execute a macro 1000 times. The macro needs an index variable. I would much rather have 1 variable and inc it's value and then pass it to the macro as an argument vs having an extremely large code block.
Often it helps others to know "what is the problem you're really trying to solve?" rather than "what's the technique for doing 'X'?" The latter only implies that you've thought of a solution to a problem but simply don't know how to make it work. But perhaps there are other solutions to the real problem you haven't thought of yet.
Your description of the "real problem" above still isn't completely clear to me. Are you to trying to expand a macro 1000 times at assembly time? If so, that's still a lot of code no matter what variable you use. Or are you at run time trying to execute the code of one macro expansion 1000 times? If so, why a macro and not a subroutine?
As far as I understand your original question, the answer is "yes". The most basic function of all macro processors is simple text substitution. The form you show is what I'd call an "implied" form, where any actual arguments provided to the macro at expansion time are assigned to pre-defined formal argument names (typically numbered names, often with the name '0' standing for the total number of arguments supplied). It's possibly the most elementary form (ie., the easiest to implement) of macro processor. Not as easy to use as those that let you name formal arguments yourself, though.
In the 6502-family world at least the Merlin series of assemblers use this form of macro. I don't recall any others offhand, but there certainly may be.
Login
Register
FAQ
Search
