You might end up encountering some difficulties assembling those stz (_sp),y instructions

Mike B.

I haven't thought about how to have a macro do that. I guess I'd like to get more code done with it to identify a pattern so the macro truly clarifies things. However, the following is from the parameter-passing chapter of the 6502 stacks treatise, about 30% of the way down the long page:

If you want to access that output data that's on the stack before pulling it off, perhaps even in arbritrary order, remember that X is still valid from the subroutine using it for indexing into the stack, as shown below. If you've done TSX again, adjust your indexed numbers to account for the fact that the return address is no longer there, and in the case below, that there was a PLA after the TSX such that now after the subroutine return, the outputs are at 101,X to 104,X. If you have not done TSX again, the old indexed numbers will still be valid.

The example above calls the UM_STAR subroutine below which takes Bruce Clark's improvement on my commented bug fix on the UM* multiplication in fig-Forth, and it modifies it for I/O on the hardware stack. The structures are per my structure macro article and source code linked there. They assemble exactly the same thing you would by hand, but make the conditions and branches in the source code clearer.


Code:
UM_STAR: LDA #0                 ; Unsigned, mixed-precision (16-bit by 16-bit input, 32-bit output)
         PHA                    ; multiply.  Add a variable byte to the stack, initializing it as 0.
         TSX                    ; Now 101,X holds that new variable, 102,X and 103,X hold the return
         LSR $107,X             ; address, and 104,X to 107,X holds the inputs and later the outputs.
         ROR $106,X
         FOR_Y  16, DOWN_TO, 0  ; Loop 16x.  The DEY, BNE in NEXT_Y below will drop through on 0.
             IF_CARRY_SET
                 CLC
                 PHA            ; Note that the PHA (and PLA below) doesn't affect the indexing.
                    LDA $101,X
                    ADC $104,X
                    STA $101,X
                 PLA
                 ADC $105,X
             END_IF
             ROR
             ROR $101,X
             ROR $107,X
             ROR $106,X
         NEXT_Y
         STA $105,X
         PLA                    ; Retrieve the variable byte we added at the top, cleaning up the stack.
         STA $104,X             ; Again note that the PLA changed S but not X, so the 104 is still 104.
         RTS
 ;------------------

(Note: In many situations, it will be advantageous to give names to the items on the stack, using EQUates, so it's more clear what 101,X is, what 102,X is, 103,X, and so on. (But don't forget to still put the ,X after them.) More on that later.

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

I'm not sure if the ca65 macros, which are really great, could do it either. I could not get it to count how many arguments I needed in an argument and then push that many arguments, regardless of where the function was called. Instead, I pushed the count of arguments to the stack so my loop takes a few extra cycles. I do think it would be very doable with a custom macro system. I wonder if I could pass a source through a macro program without assembling then change some things and run it back through. That would be extremely powerful without having to write a new macro system.

This is really slick. I think what I'm afraid of with this kind of stack stuff is needing nested X and Y loops that also need to use X to index into the stack and the value of X for something else. It seems like you would have a lot of switching overhead.

Would you tend to use X indexing for everything until you absolutely need the extra speed? What do you like about doing it this way over zero page with no X index?

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

I swear no one is paying me to shill for the ca65 assembler, I am just really impressed. You can supply less than the number of arguments the macro was written to use and compile conditionally based on whether an argument is blank or how many arguemtns it receives: http://www.cc65.org/doc/ca65-12.html

Could be. Maybe I am premature in saying you can't do what I want to with macros. There are two problems I have not been able to see how macros could solve without being designed specifically to do it:

I think to do this you might need some higher level abstraction but maybe it can be done with macros.

Another problem is where to put the memory to reduce pushes. Imagine if you assigned $00-$07 like this:
func1: $00-$03
func2: $04-$07
func3: ??? (4 bytes)

If the calling order is func1->func2->func3, it doesn't matter since it will have to push anyway.
With this order: func2->func1 and func2->func3 , func3 should use $00-$03.
With this order: func1->func2 and func1->func3 , func3 should use $03-$07.

Another useful feature would be basic optimizing like this:
If #VALUE is 5 then it should automatically reduce to this, since it is both smaller and faster than what it replaces:
On the other hand if #VALUE is 7 (and it's your only call to func) it could become this:

The trick is, I think, having the assembler spot that #VALUE is a constant that always leads to the same result and computing it for you. The strength is you only have to write the function once and it still works when A is loaded with something not constant, in which case the function should stay intact.

I can deal without most of what C has to offer but it would be nice to have just enough abstraction to do those kinds of optimizations. I think if you 1.) treated normal labels as function names, 2.) only used temporary labels within functions, and 3.) only jumped to functions using their names, rather than hard coded addresses, you could do quite a lot. I think you would also never have to compromise performance and you would only increase program size if you chose speed over size. I suspect you would need a lot more than macros though.

Interesting. Out of curiosity, do you have an idea of the speed trade off between doing the same job in assembly?

You can also do it in the WDC Official Assembler; a trivial example using WDC syntax, it extends my CopyByte macro so that you can make two copies of the same byte by passing a second destination argument.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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

The point of doing things differently to me is the gain in performance with local variables (not with passing arguments), although I do see how you would prefer using stacks for that too, even though it's slower. LDA, STA, and ADC (just as examples) only take 3 cycles from zero page, whereas they take 4 cycles with X indexing into a zero page stack or the return stack.

Imagine a function that uses four temporary variables in zero page with values calculated in the function (ie not arguments passed in). Here is an example of a fragment of an X indexed loop.
If you store your variables in zero page, this fragment takes 30 cycles. Here is how I think you would do it with a data stack in zero page (please let me know if there is a faster way to do it).
This takes 56 cycles (or can you speed it up?), which is almost twice as slow! Of course, I am deliberately trying to create the worst case scenario to prove a point, which is that unindexed zero page is faster when you are working with intermediate values. If you are using arguments passed to the function, which might already be on the stack, as you do with the Forth style stack you mentioned, I see why it is faster to leave them on the data stack and not make a new copy for every function call. However, every time the function rereads one of those stack arguments with X indexing, it incurs a one cycle penalty. If you access it enough times, it will be faster to allocate space for it in zero page and make a copy.

Right. I am using a, b, c, and d as temporaries. They also cease to exist when func1 or func2 exit since other functions are free to use that zero page memory (the same concept as a stack).

I see the convenience in not having to figure out where to put them. My only point was that figuring out where to put them yourself avoids X indexing for temporary local variables like a, b, c, and d, which is faster. I was doing things like this myself and it quickly became unmanageable, as well as probably not as efficient as a computer could manage. One caveat I see is that the speed gain has to outweigh the longer time it takes to push and pull zero page to a stack, versus adjusting X for your data stack.

How would you handle an HLL function like this?:Would you take these steps?:
1.) leave the calculated x, y, and z values on the stack without storing them somewhere else (yet)
2.) not make a copy of them for the first call to func
3.) make a copy of them on the stack in a different order for the second call to func

I imagine you would have to expand all the macros first of all so that you are left with only instructions and data. Then you could interpret the code line by line and figure out which paths are useful and which can be boiled down to constants. Then you could hand it over to the assembler after you had made your own changes.

Do you know of an assembler that will output source after macro expansion but before assembling?

EDIT: Woops, missed part of your post:
I meant if you wanted to try to get a program to optimize like in my example, you would have to follow a few rules of abstraction. There is no way to tell from a JMP instruction if it is entering a new function or just going back to the head of a loop in the same function. You would have to know that (I think) to optimize well.

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

Oops. Good point.

As long as you have stack space to hold copies of the zero page you are using temporarily, using zero page memory is also re-entrant and permits recursion. If you leave arguments on the stack and only use zero page to hold temporary calculations, wouldn't you use the same amount of memory as doing the same job with stack space? Here is what I have done in the past:

The temporary usage of $00 here is not necessary but it shows that you can allocate temporary storage in zero page and still use recursion. Also, it doesn't take up more stack space than using the stack for temporary storage.

You do have to do it at least once through each loop for the DEX/BNE if you are using X as your loop counter, although that might only potentially happen once per loop. Is there a faster way to loop than using X when you not only need to do something a certain number of times but also need to use the value of the counter each time through the loop? Too bad there is no LDA Address, (zp, X) to replace LDA Address, X

Perhaps, but you still have to copy X to the stack somehow after you do DEX (unless you are looping a different way like I mentioned above. DEC Counter, X in that case?). It does seem like keeping the counter variable (updated only once per loop) on the stack would be faster than LDX x_copy/DEX/STX/BNE.

Agreed. Seems like worst case scenario.

Right but the difference is the optimizer/assembler will take longer to figure that out than not optimizing. It will not slow down performance, only the compile time (hopefully by less than a second).

Pushing zero page addresses is just as re-entrant as using the stack and it also permits recursion. If a function uses $00-$03 in zero page, just push those bytes to a/the stack every time you enter the function and restore them when you exit. It is similar to pushing registers. The added benefit is you can spot yourself or with a macro/optimizer when they don't need to be pushed before the function begins and skip the push/restore sequence. Don't HLLs often assign register use in a smart way and only push the ones a function will need before jumping? I'm thinking of zero page as 256 registers.

Exactly. This is why I think a program to figure out what goes where would be a great help.

This would also be absolutely necessary anyway to let the program assign zero page memory for temporary usage. I think it makes sense to do both things at the same time.

I got it to preprocess only with Macroassembler AS using arguments -P +G. I'm not sure how good it is as an assembler but it claims to support 65xx (and it was the first Google hit).

My idea was that you could use any macro you wanted and the program would only work on the assembly that that generates. Otherwise, you would be locked in to supporting certain structures, which I would like to avoid. I think it would be neat if it relied on as little abstraction as possible. I think you would only need "byte" and "word" to reserve temporary zp, "call" and maybe "function," with all of those being optional and mixable with everything else like JSR.

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

I skimmed it a while ago. You have a lot of good stuff in there. I like your idea of mixing different methods depending on the situation. This is another area where an optimizer could do a lot of good by comparing the penalty of pushing zero page versus X indexing for you (I would not want to have to figure this out by hand).

Woops, that was my lame attempt at a joke. You can do LDX zp, X then LDA Address, X but not combined in one step like LDA Address, (zp, X).

Right, you can't pre-compute everything but why not look for things that you can? You can also look for parts of code that your program will never reach.

I just mean if I worked on a program to optimize assembly I would definitely be against adding any sort of keywords you have to use. I like the idea of keeping it 100% compatible. Otherwise, you start to drift towards your own language, which I would not want to do.

Good point.

That could be interesting too but all of the stuff I'm thinking about seems to be well beyond what you could do with a macro.

They call programs that do this "compilers".

I don't think it would be a real stretch to write a "high level assembler" that has Garth-like iteration and control structures with higher level routine management, and the compiler can do some of these optimizations of allocating zero page work variables based on graph and data flow analysis.

This is exactly what prompted me to come up with PLASMA: Proto Language AsSembler for Apple. Too low level to be called a real compiler, but higher level than an assembler. PLASMA has grown a little beyond this over the years, but being able to do a little analysis can reap big rewards. One of the big benefits was to track the zero page evaluation stack during expression evaluation and adjust the stack offset instead of INX or DEX. Only with flow-of-control changes did X need to be reconciled. Caching TOS in A and Y helped a great deal. Local function variables can easily be managed as well.

Dave...