assembler macros!

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

Garth, just had to write in. I sincerely hope all will go well with your job...

The boss just now apologized on the phone for his disastrous behavior Thursday, and gave me a lot of credit he had not given me before. What a breath of fresh air.

Yes, but did he give you a raise as well? You can't buy groceries with air, fresh or not.

[teamtempest]

I find that macros help make code clear, correct and compact.

It was actually the "compact" attribute that caused me to learn to use them in the first place. A project I was writing using the Merlin64 assembler was running out of room in memory for source code, and I wanted to avoid disk-based assembly over the slow serial connection of the 1541 drive. The frequent necessity of moving 16-bit quantities around suggested that a 16-bit "MOVE" macro would be a good candidate for reducing overall code size. So it did, but alas this only delayed and did not ultimately eliminate the need for disk-based assembly.

Still, once the macro was written to recognize several address mode variants, the resulting clarity of the code was useful enough in itself to make the whole exercise worthwhile. The basic ideas used were easily extended to 16-bit add, substract, compare, etc., macros. These weren't used as often as MOVE but were just as helpful in the "clear" and "correct" attributes.

[BigDumbDinosaur]

I use quite a few different macros, both to synthesize MPU instructions and to reduce typing. Two I use a lot are PRINTCHR (print a charactor) and PRINTSTR (print a null-terminated string). In particular, typing PRINTSTR TEXTSTR is a lot less typing in a large program than:

Code: Select all

          LDX #<TEXTSTR
          LDY #>TEXTSTR
          JSR SPRINT

and also avoids the inevitable typo, such as:

Code: Select all

          LDX #>TEXTSTR
          LDY #>TEXTSTR
          JSR SPRINT

I also have macros like ADD and SUB (subtract), where ADD 2,3 is equivalent to 2+3, etc.

[GARTHWILSON]

Quote:

I use quite a few different macros, both to synthesize MPU instructions and...

This is a good addition to your post on the first page. As an example, the the non-existent SXY (swap X and Y) instruction someone brought up is synthesized with a macro here. (It was brought up as a potential nice addition to an enhanced 6502.)

I synthesize a lot of 6502-style instructions with macros when I do PIC programming. The PIC's assembly language is considerably more cryptic and the logic is often backwards, causing more programming errors, so I do some work-arounds with 6502-style mnemonics as macro names.

[OwenS]

GARTHWILSON wrote:

Quote:

I use quite a few different macros, both to synthesize MPU instructions and...

This is a good addition to your post on the first page. As an example, the the non-existent SXY (swap X and Y) instruction someone brought up is synthesized with a macro here. (It was brought up as a potential nice addition to an enhanced 6502.)

I synthesize a lot of 6502-style instructions with macros when I do PIC programming. The PIC's assembly language is considerably more cryptic and the logic is often backwards, causing more programming errors, so I do some work-arounds with 6502-style mnemonics as macro names.

You mean beauties like BTFSC/BTFSS?

I must admit I quite like programming PIC16s because of the minimality, but yes some things are most definitely backwards.

[GARTHWILSON]

Quote:

You mean beauties like BTFSC/BTFSS?

Yep. For the general-purpose ones I especially have the conditional branches (BMI, BEQ, etc.) and SEI which has to assemble a loop to reliably disable interrupts on the PIC, then there are the push and pull status in the ISR which are a disaster on a PIC as are several other things. I show some comparisons here. It's a very mickey-mouse processor, but with every project I do on it, my code becomes more concise and clear, using macros.

[dclxvi]

GARTHWILSON wrote:

For the general-purpose ones I especially have the conditional branches (BMI, BEQ, etc.) and SEI which has to assemble a loop to reliably disable interrupts on the PIC, then there are the push and pull status in the ISR which are a disaster on a PIC as are several other things.

One thing I prefer is mnemonics that tell you whether interrupts are enabled or disabled, like ENI and DSI, rather than CLI and SEI, since on some processors a 1 means enable interrupts and on other processors a 1 means disable interrupts. Macros are great for this sort of thing, of course, and that way you don't have to remember which way it is. Sort of like the often-recommended SHORTA/LONGA/SHORTX/LONGX (or A8/A16/X8/X16 or whatever) macros for REP/SEP #$20 and REP/SEP #$10.

[BigDumbDinosaur]

I recently updated my posting of Kowalski macros for the 65C816 with new ones. It should be understood that the 65C816 macros allow one to assemble programs for that MPU but not actually run them within the simulator. Also, note that WDC-specific 65C02 instructions, e.g., WAI or STP, will not be understood by the simulator as well.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

I recently updated my posting of Kowalski macros for the 65C816 with new ones.  It should be understood that the 65C816 macros allow one to assemble programs for that MPU but not actually run them within the simulator.  Also, note that WDC-specific 65C02 instructions, e.g., WAI or STP, will not be understood by the simulator as well.

EDIT: The above-referenced macros are obsolete, as the Kowalski editor/assembler/simulator now understands the 65C816 assembly language, as well as the enhancements that are specific to the WDC 65C02.