See comments added to text. ---------- > From: > To: PICLIST@MITVMA.MIT.EDU > Subject: Macro- How to use? > Date: Wednesday, June 17, 1998 3:12 PM > > Hello > > It has been suggested I write some macros to simplify my code. I haven't used > them before. The MPASM assemblers guide is limited. I have a couple of > questions. Please note I am a beginner > > In my code I am struggling to keep table and references to the PCL within the > first 255 addresses. The guide states macros must be defined prior to their > use. If I define them at the beginning of my code will they occupy those > addresses? > A macro *definition* uses no code space at all. When the macro is *referenced* in the body of your assembler code, *then* the assembler will produce actual code. The assembler will decode the macro and its arguments and place the required program code wherever the user has invoked the macro. You can define a macro and then decide never to use it. Perfectly OK. > Is it appropriate to define macros using an include file and simply make > reference to them at the beginning of the program? > Perfectly OK. The only thing about include files is that unless you have a copy of the include file you have no idea what the macro does. Unless, of course, you specify that information in comments within the program. In many cases it is useful to include a comment that gives the user the same sort of info that a C prototype would provide. In other words, you don't have to specify HOW the macro works, but you say in effect, "here is the name of a Macro I will be using, and here are the parameters" Personally, I always include a comment that tells me the END result of what it does. For example: ;Macro MULT8_X_Y *** Multiply 8 bit X times 8 bit Y and put ; result in 16 bit Z. When preparing documentation, don't forget to include a listing of all included files. > Is there a straight forward tutorial that could help me understand how to > implement macros? I have all the most popular PIC books but they don't go into > macros. I am not personally aware of any. But working with macros is really fairly stright-forward. What I suggest you do is experiment writing simple macros. Then progress to more involved macros once you have a good feel for the fundamentals. At the beginning keep things simple. Assemble and see what the assembler produces. Go from there. > > Is the Parrallax assembler a compilation of macros? In a certain sense, every assembler is a compilation of macros. They just don't call them macros. Whether or not the Parallax assembler was specifically designed that way or not, I do not know. What I do know is that you can write macros to implement any of the Parallax language you want to emulate in MPASM. There are a few gotchas, of course. For example, you cannot use as a macro name any already existing directive/instruction. For obvious reasons :) But you can easily add the Parallax style pseudo-8051 instructions. There is a certain danger in using macros this way, and that is that the assembler code does not immediately reveal HOW the instruction is being implemented, and so you might think an instruction is a single byte instruction, when in reality it is composed of several single byte instructions. As has already been pointed out on this PIC list this week, doing a BTFSS may not do what you expect, if the following "instruction" is not single byte, but actually a macro that is two or more bytes long. Gotcha! On a slightly different note, it is possible to write an assembler style program that gets almost all its info from a special "include" file. The contents of the file determine the target processor. Some companies produce such universal assemblers. They are quite useful because the programmer deals with the same basic product no matter what processor he is writing for at the moment. Every assembler has its own personal quirks. It is nice if the number of quirks you have to remember are few in number, and always the SAME quirks! Hope this helps.