It seems to me that large blocks of assembly code used in multiple places should be written as subroutines, and short blocks of code that are repeated frequently should be macros. I reasoned this is so because I don't want to needlessly duplicate large blocks of code, so a subroutine makes sense for large blocks of code use in multiple places. For example, I have written as a subroutine my code to loop through a string and print characters to the console, and code to draw a collection of shapes to screen.

OTOH, subroutine calls have a bit of overhead associated with them, including moving data into correct registers or memory location in order to set arguments and deal with return values, so probably those should be macros. So I've written code for 16-bit addition and subtract, about sixteen bytes apiece, as macros.

Is my reasoning sound? Am I missing anything?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

My programming method differs substantially enough from the norm that macros are pretty much redundant for useability. What I do is find as many common routines as possible with a lot of similarities and try to join them into a single sub-routine, then make multiple uses for that sub-routine. It really goes a long way to keeping code small.

I also find source with macros very hard to streamline until I get the source expanded without macros.

What it mostly comes down to though, is readability by the developer and what you are trying to accomplish.

My recommendation is If you want the assembled code to be more compact with the use of sub-routines as the final result, you won't need macros because very little code gets duplicated to make macros useful.
If you want the source to be more compact and somewhat easier to read or follow, then use macros.

One last mention is that in-line code is faster to process compared to subroutines or loops and if memory permits, by all means use it.

At the simple level, the trade-off is space vs. speed.

Use subroutines - compact code, but runs slower. Use Macros, then it runs faster but the code is bigger.

I use macros extensively in my BCPL VM environment as I want to make every cpu cycle count for as much as possible - however I have the luxury of lots of RAM. I'm even unwinding loops just to save a JMP in some places too - and that was initially by defining a macro then just repeating it 32 times until I realised my assembler (as65 from the cc65 suite) could auto repeat loops...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

One way to think of macros is like a sophisticated copy and paste. For something like 16 bit addition, you will always be using the same 7 line sequence, so a macro can save you typing. You probably wouldn't want to make that it's own subroutine unless you're going for extreme size reduction.

imo which ever best suits individual programming style is the one to use, no right answer.

I don't use macros because I didn't have them with EDTASM+ in the 80's though that Assembler line numbers like BASIC interestingly enough!

I also think they can be limiting because they are high level programming language that creates blocks of asm.

I wrote BASIC compilers for the 6502 and a soft blittter in 6502 Assembly without using any macros but I did use subroutine to create nuanced macros; the BASIC Compiler is a macro compiler in that sense, the macros written by hand in assembly with the subroutine psuedo-op can be tuned in more detail than macros written by hand in a macro language.

Depending upon your application, high level Macro languages can go very nicely combined with Assembly to speed development in much the same way BASIC and assembly were combined bitd with the hotspots benefitting the most from pure assembly coding.

_________________
Load BASIC from tape on your Atari 2600:
http://RelationalFramework.com/vwBASIC.htm

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I am a big fan of macros when I program in assembly. The reason is that they reduced typing of repeated code blocks and raise the level of semantic abstraction when reading code. For example:

The 6502 has no add without carry, so you always clear carry then add. As pointed out above, you're synthesizing a missing machine instructions. There's several other missing instructions that macros make easier.

Incrementing a word is always the same pattern of code. Repeating it by hand is unnecessary typing and potentially error prone. This is also true for all 16 bit mathematical operations.

The lack of stack relative addressing and small stack means the 6502 lacks a robust procedure calling mechanism. There are patterns to workaround this, but after you pick one you might want to wrap it in macros. That way if you change your mind, you change the macro, and not all the code that invokes it.

I studiously avoided learning how to use macros until I ran out of memory space for source code in a large program I was writing. Source larger than memory would hold could be read in from disk, but this imposed a huge time penalty in assembly time. So I decided that to save space I would write macros. This would be a net win if the size of the macro definition plus all its invocations was less than writing out what it was supposed to do in detail each time. I created macros for common 16-bit operations, move, add, subtract, etc. It turns out that if your assembler allows nested macros, then you can write little macros that do just a little bit and then combine them into more capable bigger macros. So you can write a "move" macro that understand most of the addressing modes of the 6502 and then use many of the little macros again in add and subtract macros that also "understand" the same address modes.

So that worked for keeping everything in memory, at least for a while. But you can also write macros to do things like allocate labelled memory without worrying too much about exactly where it is (within limits, of course). The trick is to have a macro that "remembers" the last address allocated and puts the next request right after that, updating as it goes. And that was also helpful.

You can also rename or alias mnemonics. These don't do anything but make clearer programmer intention. My most common use of this is to rename BIT zp and BIT ab into "SKPB" (skip byte) and "SKPW" (skip word). They execute but the result doesn't interest me; generally there is a value in one of the registers that I want preserved through a whole chain of these with entry points to load those registers. Most often these are error codes, because this technique saves space at the expense of time, but I don't really care how long it takes because reporting an error is not usually time sensitive.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thank you all for your diverse input. Most of my macros so far have been to data between struct fields and registers, or to simplify 16 bit operations. On the 16 bit operations front, I got most of what I needed implemented, then had a sudden thought: my 16-bit macros overlap about half of what the SWEET16 opcodes cover.

That makes sense as Woz invented SWEET16 for 16 bit operations. But macros inline their code so they are faster than a byte code VM.

Thanks for that confirmation. That's why I kept going with the macros I needed rather than implementing SWEET16. I figured macros might result in three times as many bytes for each 16-bit op, but I'm not using so many such ops that the decreased code size seemed worth the slower speed. 6502 code assembled by CA65 is already so much smaller than what CC65 generated from my first stab with C for the 6502.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?