6502.org

Hello, new here so apologies if this has been done before and posted...

I've just started learning to use the 64Tass assembler (and brushing up on assembly language in general), and I was inspired by the wonderful article here https://wilsonminesco.com/StructureMacros/ to port some of these macros over to tass. This process has certainly helped me understand the features of Tass - I've tried to utilize the more advanced macro features where I could when porting (lists, slices, nested macros, etc.)

Posting here in case anyone finds use for these. Included a tiny bit of test/example code as well.

At some point I'll likely do more testing, as well as maybe add some more macros (for..next for sure). But I really should get back to the original point of me learning all this, and finish my emulator...

Caveat: These are all largely untested, and as I said above I'm certainly no pro at assembly nor 64Tass, so I'm sure there bugs somewhere in there.

Appreciate you creating that article (along with all the others)! Very helpful stuff.
Thanks for sharing some more for me to chew on! I'm not too familiar with the '816 yet, but generally my path forward is to get a 65c02 emulator working, then transition the code to an '816 emulator, so sooner or later I'll be digging through those manuals and materials.

Hello laztrezort!

I'd recommend an alternate approach by stacking namespaces instead of branch instruction locations.

The advantage is that it's possible to define symbols like _skip or _loop in them. Using these as branch destinations there's no need for patching with .byte directives. Error diagnostics will work better, it's compatible with automatic long branching and the assembly listing becomes more readable.

Wow, that's amazing, I had no idea one could (ab)use namespaces like that! Also, I see I was using naive list handling in my code - thanks for sharing.
I'm still trying to wrap my ahead around it a little, but I believe it's basically just using those symbols as temporaries to get the assembler to do the branch target patching, instead of manually filling in the branch opcodes. The 64Tass scoping hides all of those symbols so you're not polluting your normal symbol namespace, and aren't meant to ever be used directly.

I'm kind of lost since I'm not familiar with 64Tass; but once the macros are written and proven, there's no further reason to look at their innards (except maybe when you want to use them as templates to modify to make new macros).  Then it doesn't matter how they do their job silently behind the veil, although you're keeping in mind that (in most cases) they're assembling exactly the same thing you would by do hand if you didn't have the luxury of the macros.

Yes, those are 64tass directives. I haven't explained them as they're a documented elsewhere and thought there isn't much interest.

The .namespace/.endnamespace pair creates or uses a namespace. This allows sharing symbols across "#if" and "#else" or "#endif" for example.

The .segment/.endsegment directives are the non-scoped versions of .macro/.endmacro. I've used them because scoping would be redundant due to .namespace/.endnamespace and also if no labels are defined which need hiding.

The .function/.endfunction directives are used to implement namespace stack push/pop operations. A new empty one is added to the end (-1) or gets sliced off. Both return the top of the stack as that's what's needed to select the namespace where new labels will be defined or where the label for the branch resides.

That .switch/.case/.default/.endswitch block is a shorthand for .if/.elsif/.else/.endif and .proff/.pron hides code in listing.

They aren't pseudo-ops though, they are assembler directives that control the conditional assembly of the code - at least that's what I assumed. For example, your pushparm.asm would be a lot clearer if it could use switch and case directives to check .m against the various options, instead of nested (and increasingly indented) if/else directives. Ultimately these preprocessor-like constructs are all there to make it possible to write more powerful macros, enabling the user code to be conceptually simpler and less repetitive. Even though I don't personally use macros much, as I do like sticking more-or-less to the instructions that the processor understands natively, I do see the value in them.