Hello Jon. > It has been suggested I write some macros to simplify my code. Who suggested that (I wonder!)? > I haven't used them before. The MPASM assembler guide is limited. Typical! > Please note I am a beginner I can't believe that from seeing the code you write! > In my code I am struggling to keep table and references to the PCL > within the first 255 addresses. I have already made some suggestions on that.... > 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 is an interesting concept; otherwise called a "template". In other words, it sets the pattern of something. When you call it, the values you supply in the call fill the "holes" (local variables) in the template and you "punch out" a piece of code with this pattern. You only make code (and use code space) when you call the macro. Conversely, *each* time you do so, you make more code (but not necessarily the *same* code, this is the beauty of it) and use more code space. As has been pointed out, if you use a macro library either in-line or as an include file, the unused macros contribute *nothing* to your code size. Compare this with subroutines; the subroutine is compiled into code once only (therefore can only ever do the same operation though it may have alternate branches) whether or not you call it. It is not therefore a good idea to use libraries of these unless an "intelligent" linker is used to boot out the unwanted ones. (Most "C" systems work something like this.) However, even if you call it a hundred times in your code, it still only appears once and occupies a single instance in code space. > Is it appropriate to define macros using an include file and simply > make reference to them at the beginning of the program? This is one of the *principal* uses of include files. The other, "defines" are very much the same; in fact a macro is in effect little more than a multi-line "define" with a parameter substitution mechanism. > 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. Can't say. See if you can figure how the macros I sent you fit. There are two main reasons to use macros. One is to avoid mistakes! The lesser is to use smaller, more concise source code. Where you have a similar sequence of instructions again and again in the code, you can write a macro to summarise on one line that sequence, factoring out the variables. If for example, the sequence movlw movwf .. appears frequently, and in PIC code it certainly *does*, you define a macro such as: movl2 macro var, lit movlw lit movwf var endm .. where "movl2" is the macro name (*not* in this case a label for an address in code space) and "var" and "lit" are local variables which in the macro invocation will be set to the (string) values following "movl2" wherever it appears in code as a pseudo-op. The code snippet (in this case the next two lines) with these substitutions made will then be assembled into code space as if it had been in-line in the first place. "endm" means the end of the code to be substituted. So, if you have thus defined "movl2" previously in the code, the sequence: MOVL2 PULSIN_H,3 .. will be seen by the assembler as: movlw 3 movwf PULSIN_H .. and assembled accordingly. Note that this is my choice of a mnemonic and Parallax uses something different. I chose it so that it reads "Move Literal TO ", but also the "2" reminds that it takes two program words and cycles; I favour a naming convention for similar two- words macros. In this case, the advantages are that since the operation only really affects one register (even though it leaves the literal value in W), the connection of the literal and the register is made on the same line. There is no need to look at the code and determine "chicken and egg" especially if a cascade of tehse loads occur together; in a series, each operation links source and target on the one line. While the obvious use of macros is to code a long sequence into a short mnemonic and make the source less cluttered, the readability benefits may also be worth defining a set of operations used only *once* as macros, so that the series of macro calls subsequently forms a self- documenting summary of program flow (FORTH-syyle). This makes MACRO very much a "high-level" language with implementation-hiding. **************** *How* does a macro assembler do it? Well, it maintains a "stack" of macro invocations (loosely; "calls") and an area into which macros are compiled as they are read from the source. The stack contains pointers to the current reading position for each macro within the macro storage space, plus the value of each of the substituted parameters. Macros are by *no* means unique to assemblers, there are generic macro processors, text processors (with features still uncommon in WYSIWYG word processors) etc. As again has already been mentioned, a good macro processor with a mathematical expression evaluator can be used to make an assembler or disassembler for virtually *any* processor by using include files. Most macro assemblers for one CPU type can be used to compile for another, even with a quite different architecture and language, so you can for example, use MPASM to program a 68HC11 (I think - I haven't tested it)! > Is the Parallax assembler a compilation of macros? Again, as others have said - probably! That certainly is *one* way it could have been built. Apologies if this is too elementary for some - I will re-work it into a FAQ on my home page - sometime! Cheers, Paul B.