I'm starting to compile some code with the CCA65's CA65. When I compile it without MAcros, all is working ok. But if I use macros the macros don't be compiled (but the process don't give error.
Are you compiling C code, or are you assembling? Compiling and assembling are two different things.
I thought that when assembling the macro, a subroutine was generated that was embedded in some free area of memory. So I was looking for that subroutine that was obviously nowhere to be found. What happens is that the code resulting from the macro is embedded in the program code itself every time the macro is invoked. And that makes more sense than my idea (although it takes up more memory).
So reviewing the list produced by ca65 when assembling the source, yes, indeed the macros were embedded there.
This is the code I tried to assemble (thanks, Gordon):
That's essentially what I'd expect. Macros are expanded in-line with your code, making it larger, subroutines aren't.
So you need to think about where you place the subroutines then JSR to them and end them with an RTS - there is no magic/automatic conversion of macros into subroutines. (it can be done, but you need to DIY it)
And this is the list resulting from assembling it:
[...]
00F004 1 A4 EA 88 D0 waitBaud; Delay 1 bit time
00F008 1 FD
00F009 1 EA NOP
00F00A 1 A4 EA 88 D0 waitBaud; Delay 1 bit time
[...]
I thought that when assembling the macro, a subroutine was generated that was embedded in some free area of memory. So I was looking for that subroutine that was obviously nowhere to be found. What happens is that the code resulting from the macro is embedded in the program code itself every time the macro is invoked. And that makes more sense than my idea (although it takes up more memory).
That's what a macro is. The following is from the front page of the macros section of my site, the first couple of paragraphs under "First, what is an assembly-language macro?":
As you write an assembly-language program, you may see repeating patterns. If it's exactly the same all the time, you can make it a subroutine. That incurs a 12-clock performance penalty for the subroutine call (JSR) and return (RTS), but program memory is saved because the code for the subroutine is not repeated over and over.
There will be other times however where the repeating pattern is the same but internal details are not, so you can't just use a JSR. The differences from one occurrence to another might be an operand, a string or other data, an address, a condition, etc.. It would be helpful to be able to tell the assembler, "Do this sequence here; except when you get down to this part, substitute-in such-and-such," or, "under such-and-such condition, assemble this alternate code." That's where it's time for a macro. "White Flame" on the 6502.org forum wrote, "Macros are assembly-time function calls, whose return value is source code."
As a side note, 6502user, you can put [code] and [/code] around your code to preserve the white space and force monospacing. I sent a PM about this. It would be good to click on "User Control Panel" (in the top-right corner of your screen), then "Board preferences" (on the left edge of the screen), then where it says "Notify me on new private messages:" and the line below it, "Pop up window on new private message:", make sure the "Yes" buttons are clicked. And before you post, click "Preview" under the box where you write your post, to make sure it will look the way you intended. You can also edit your post after it's already posted, by clicking "Edit".
