Variadic macro in ca65 possible?

[tokumaru]

You got everything right. Indeed, only the .promote macro is relevant to the topic of variable-length parameters, but I wanted to put it into context.

I cannot imagine trying to debug this if something went awry with either an address the linker generated

The good thing is that since the macros are fairly small, straightforward and stored together in a single file, it's really easy to fix any bugs they might have and instantly fix the whole program. That doesn't happen often, though. You can certainly break the macros of you try, but they work very well if used as designed. I could certainly make them more robust and check for every little thing that could go wrong, but that could easily duplicate the size of the macro definitions, and I'm trying to keep things simple.

(it almost looks like a kind of half-ass implementation of a C++ class?)

I envisioned the blocks similar to simple functions in procedural languages (.block is practically a variant of the built-in .proc, but with a configurable entry point), the similarity to OO languages probably comes from separating scopes with "_", but that's mostly artificial. I can pretend FunctionB is inside FunctionA by calling it FunctionA_FunctionB, but there's no real connection. Anyway, I was indeed trying to give ASM more form, and standardize most common programming patterns.

The only case I can work out is .promote being relevant to that subject?

Yeah, sorry if the rest of the code is not relevant, I just wanted to give ".promote" some context.

There is no .block/.endblock in ca65 (that I know of), so these too are macros, but they don't appear to have argument lists

Correct, .block takes the name of the block (which is used to create a reference to it in the global scope, and an optional parameter specifying what's the entry point to that block. In a sense the argument count is variable, since the second argument is optional.

(re: jsr Add_WithoutCarry is not a macro call, it's a subroutine)?

Yeah, that's pure ASM.

Iinstead it looks like {blockname}_{labelname} is the syntax you use...

Yes, to make the hierarchy of the labels clear and avoid collisions.

so is the point that you want to be able to do something like nested blocks, ex. end result of jsr Add_WithoutCarry_OtherBlock_LabelName_Block3_MoreStuff_HowLong_CanThisGet

I don't intend to have nested blocks, I've not had the need for that so far. The longest labels I have so far are of the form Module_Function_Label, such as Video_DrawSprite_Relative.

or does it pertain to .promote specifically? If the latter: I now understand (and sympathise) with your concern/want.

The main purpose of .promote is to allow external code to pass parameters to subroutines, but it's also useful for providing extra entry points in the case of subroutines that perform different tasks, and to provide access to the individual arrays of a structure of arrays, such as this:

Code: Select all

	.block HitBoxes

Top:

	.byte $10, $12, $08, $10

Bottom:

	.byte $10, $00, $04, $00

Left:

	.byte $04, $08, $08, $0f

Right:

	.byte $04, $08, $08, $0f

	.promote Top, Bottom, Left, Right

	.endblock

Apologies if my question isn't clear enough. Ask and I can probably reword it.

I'm not sure I understood all the questions, so let me know if I failed to address something.