On 12/8/2020 at 1:22 PM, Johan Kårlin said:
Thanks for your answers!
@StephenHorn I took a look at math.inc. It is clearly a better way of doing it compared to what I am doing now. I guess I have reached the limit for what ACME can do. Both for this and other macro implementations it would really be a relief to not have to write multiple macros just to cope with the fact that parameters can be passed by value or reference. After my current project I will probably start developing with ca65 instead. By the way - why not finish math.inc and upload it as a development tool : )?
Bump.
There is a drawback, though, to trying to use smart macros. So I have tried to go ahead and expand on the smart macros for my math.inc, and things mostly worked... mostly. I'm having some issues with certain cases being mis-identified, resulting in bugs. For instance, an easy way to foil the smart macros seems to be anything in the form of this:
Quote
.repeat 3, i
MY_MACRO #(arg+i)
.endrep
This should be an immediate (prefixed with "#"), but the assembler macro logic to detect that fails.
I'm not sure if this is a bug with CA65, but more generally, you can force syntax errors with statements like this:
Quote
.out .string(#1)
...which I would expect would cause the assembler to output "#1".
So. Smart macros. A clever idea, but if there are bugs like this then maybe I'll end up leaving them be while *also* implementing dumber, more explicit versions.
(This is the second assembler with which I've managed to hoist myself on my own petard, trying to make a smart macro library. At least this time I'm able to diagnose where the problem lies.)