I have a decent handle on 6502 ASM. I'm trying to work out a new macro that can point to a sort of variable label and I'm running into a stumbling block. This may not be possible, but it seems with the component pieces, it should be.

Here is what I'm effectively trying to do, with bad syntax (I know this won't work, but for the concept):



Where this...



...would effectively give me:



Is there a way to do something like this?

What assembler are you using?

Syntax and macro capabilities vary greatly.

Gotcha.

ASM6.

I don't quite see any way to combine these literal strings to then be read as a single label this way, but it seems like it *should* be possible. There's just no way I can see to append strings like this (+ always looks for a number). But before I make the presumption, I just want to make sure there's no deeper hidden (and probably obvious) method I'm not considering.

I can easily make it a single argument and it functions as expected. But I can't figure out a way inline to combine the arguments to have it read as the single label to then work with.

Thanks!

Some assemblers do have string concatenation as a native capability. One of those might help here.

Alternatively, you might try to substitute directly and see if that works. Instead of



try:

with ca65 this could be easily done using the built-in ".sprintf" function that works exactly like sprintf in C:



".ident" just converts the resulting string from ".sprintf" into an identifier (ie a symbol or label).

then again, why seperate the label names only to them combine them again in a macro? like what exactly is the use case for this?
maybe with a better understanding of what you're trying to do, an alterantive could be worked out.

That sort of thing can be useful when the calling site is also in a macro, and one of the components of the label name is an argument to that outer macro.

Direct subbing doesn't work (all manners and combinations of things I've exhausted).

As far as use case, I can think of a million, but let me try to come up with a functional one. Let's just say I have a program that draws various boxes. Each box is its own width, height, has its own contents. Effectively, it's a multi-dimensional array of data to form the box.

I could do this easy with tables...something like:



All good. I could draw this box with just a y offset to get the length, width, and contents for the Yth box and create a draw routine. Easy.

But now I have a box that might have variable data inside of it. So for contents, it might look more like this:



What I'd love to be able to do is something where I could, say, have a macro:


Then I'd end up coding:


...which could give me easy access to Box_0_contents as the label to point to to get that particular boxes contents, because in the macro itself, I could combine the argument (Box_0) with what table for that box I'm looking for (_contents), and read away.

The way that I would do it now is have some pointer table...something like:



...and then use the same offset for the box I'm looking for, have it point to the table, get the relevant data via indirect indexed addressing...whatever. I guess this system would avoid the need for this table and that sort of fetch. The routine could look up "Box_" + the identity of the box + "_" + the parameters and labels it needs to work with just by invoking a macro. But I can't quite figure how to do it with this assembler.

This is just an off the cuff example, but does it make sense as for as intent?

hmm, to me that sounds like you want to replicate the functionality of C structs (with dynamically sized elements).

so you could just copy exactly what structs in C do and use a pointer to dynamically sized elements instead of directly storing them in the struct itself.
which means they're slower to access, but simplifies the code required to deal with them as you don't need to worry about your structs being differently large.

for example a regular struct that deals with a box (position and size only) could be made by having the base address of the struct and adding a constant offset to it, depending on which element you want to access:



for dynamically sized elements, pointers (similar to how you're already doing it) seem like the best way to go. so here the same example again but with an added "contents" element that points to a NULL terminated list somewhere in memory:


and if you want to be able to deal with multiple dynamically created structs at runtime, all your functions will have to do some math to calculate the addresses of elements relative to the starting address of the struct, and then use indirect addressing modes to access those. sadly there is no double-indirect addressing mode so when accessing a pointer you have to save it to ZP first before being able to use it.

i hope this was atleast somewhat helpful and is what you were looking for in terms of functionality.

_________________
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?

Proxy - yeah, that's not so dissimilar to what I'm actually doing now. Lot's of pointer / indirect look ups. It get's more ugly when a system has multiple properties with multiple values...recursive indirect lookups to bog things down in what seems like a needless way since the root text of multiple tables is always the same. But there doesn't seem to be a way in this assembler to account for that in the way I was hoping.

Was worth a shot.

Proxy, on that note...help me with this one as an alternative way to *end* the contents rather than null (in the event it's a situation where I need all 256 values). I can conceive of something like this when I KNOW the label in question:



...and use that with something like this:




No problem. That works fine...presuming we're dealing with a static address (myContents0).

But I guess I get a bit confused when I start factoring in pointers. If I end up utilizing zpPointer know where doLoop should be fetching (works fine), how can I do this exact compare? Obviously #(zpPointer),y won't be correct. Is there a way to utilize this nifty way of tracking the length this way but with a variable pointer value rather than a static value? Maybe this is easy and I'm thinking too hard about it.

Thanks!

I'm not exactly sure what you mean, as long as your data is completely static and known at assemble time you can use "myContents0_length" to do this no matter if you access the data directly or indirectly through a pointer.

but if you meant that the amount of data can change at runtime (ie the assembler doesn't know how much data the contents table will have) then you just need to add another variable to your struct that keeps track of that, and manually update it when you add or remove values from the contents table.

Alright - I'm not getting expected results there, so I'm guessing I'm asking a syntax question.

This is part of a Macro / subroutine combo so that I can reuse the functionality with different elements, in each case, different, but it is static at time of assembly. If I have proper index in y, and the address of myContents0 is loaded into (zpPointer), and that position should return myContents0_length = $-myContents0, comparing against (zpPointer),y does not work as expected. I guess what is needed is immediate indirect addressing...like #(zpPointer),y? But that does not work as expected either.

So manually, the example works perfect (when I actually put in the label as above). However, trying the same trick through indirect addressing does not seem to work. Just seeing if anyone can give me a clue as to what's wrong with the syntax, or a proper way to do this? Thanks!

EDIT: Was making this harder on myself than I had to. I got it working.

If anyone is looking for a solution for this, the solution is simple. The table ends up looking like this:



...and then it's just reading that value via the pointer. So far, as long as myContent's number of values < 256, this seems to work fine, and I could conceive of how to do it with 16 bits as well if needed.

Thanks for the help, guys.

One way is to use decrementing rather than incrementing. Instead of:



try:



...so the entry point is 'doLoop' (or whatever better name you think of). The point is that you can load the Y-register with whatever value you want just before calling this routine. It doesn't have to be the same value each time.

or if you really want to increment:



...again pre-loading Y with the correct terminating value just before calling this routine.

If you find that most calls will use the same terminating value:



...and call 'static_entry' most of the time and 'variable_entry' when you have something less common to do.

This discussion has meandered on and I am not clear exactly what you seek to accomplish.

As for your original question, sometimes a more primitive assembler can be more useful.

The FLEX 6809 assembler macro facility does not use names for parameter substitution. Instead, you use &1, &2, etc based on the position on the macro invocation line.

For example, in my cross assembler,