Over on http://forum.6502.org/viewtopic.php?f=2&t=7304 I asked whether syntax would have more assembly coders think of zero page as registers instead of byte-saving global. That %Rnnn syntax led me to another syntax-based solution to another common 6502 coding question, how best to pass parameters to subroutines.

The 1980s and 1990s CPUs mostly solved this with a addressing mode relative to the stack pointer. FORTH implementation in the 8-bit CPUs often manage a second “data stack”. A zero page pointer is the obvious place to do this on the 6502.

I came up with something inspired by that, but simper. My solution is a new syntax in the assembler. The general form is %%n.mm, and the mapping from that to addresses is inspired by the $Cn00 memory layout on the Apple II.

%%n where n =0-7, with the lowest level subroutines using 7, the next lowest 6, then 5, and the top-level application using 0. (I’ve yet to use 2, 3, or 4 so 8 layers is probably too many).

%%n.mm where mm is a decimal values, 1-15. I use the shortcut %%n to refer to %%n.0

For example, my PrintString low-level subroutine expects the pointer to the string in %%7, as a two-byte address. CompareString has two parameters, %%7 and %%7.2, both two byte addresses.

In my Apple II4 project, I map this syntax to start at $D000 (after the I/O space and after the screen buffers), but the assembler can map in anywhere in memory.

The result is basically a manual data stack. Yes, it seems to waste space, but on a typical stack you waste the yet-used space where I’m wasting the in-between space. The benefit is that I know exactly what address the parameters for every subroutine should be, making debugging a lot simpler.

Plus there is no push or pull and thus no way to get into a state where the return address or current parameters are not where they are expected to be. The stack pointer just deals with JSR/RTS and the parameters only get set, never unset.

Plus, every so often my code makes a sequence of low-level subroutine calls and as the first parameter to all of those is always %%7, in those cases I can just set %%7 once.

The result of all this feels a lot like a manual version of what a C compiler does, minus the pushing and pulling. I’m manually looking up the list of parameters and %%addresses of the subroutine I’m calling, mustering the parameters in place, then JSR. Then inside any subroutine it’s just LDA %%n.mm to grab the value.

And with the manually set “levels” there is never a conflict.

Anyone have a similar solution? Or something better?

_________________
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 setting the levels at runtime, I’m setting them in the architecture of the code at assembly time.

Or in other words, I know which subroutines are the lowest level, as they don’t call any others. Those use %%7. PrintChar, ClearScreen, CompareStrings, etc. The next level up can call “down” to that level or within the same level, and thus are assigned %%6. In my system that is FileOpen, FileRead, FileClose, etc.

I’m using %%0 at the top level of the command line, with a Unix-like ARGN as %%0, the name of the command as %%0.1, and the other parameters as %%0.n. That then leaves the %%1 level for subroutines that implement the commands. I’ve yet to need %%2-5 but only because my programs so far have been relatively simple.

Yes, I read your post on stacks, and it inspired this simpler, manual stack.

Mine is unarguable less flexible but makes debugging easier and faster. I’m a long-time C coder and jumping back to assembly I’m often debugging one char errors like a missing # or $ or before this %% syntax, a subroutine stomping on a memory location.

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

It's been a while, but I think I did something similar for a UCSD p-code interpreter. There was dedicated zero-page scratch area, two 16-bit data and two 16-bit addr (which was almost all I ever needed - except integer math needed at least one more 16-bit data), that any subroutine could use as long as it "knew" that area could be trashed if it called another subroutine. That could be used for passing parameters as well, and if more were needed, they could be passed on the stack and removed to a "safe" area by the callee.

The lowest Level-0 routines were not allowed to call anything while active. Level-1 could call Level-0 (and would, else they would not be Level-1). Level-2 could call Level-1 and Level-0. Basically the idea was that at any level calls could be made to any lower level, but never upward. The collection of these made up the layer that separated the virtual p-machine from the hardware it was running on. I think the levels topped out at Level-3, but I seem to recall thinking that any more were going to be increasing difficult to manage. But that may have been partly because it getting harder to find "private" zero-page memory both protected from lower level routines and small enough to not miss when not in use.

Yes. But with a typical stack you have to reserve the maximum number of bytes you think you'll need, as pushing past the end (or wrapping) is usually catastrophic.

So it's really just another version of optimizing compile time vs. runtime. Your choice probably uses less memory, but remember, I have a 24-bit 6502 with plenty of memory. My pseudo-stack uses $D000-$D7FF to cover eight levels of parameters, 256 bytes per level. That is huge compared to the 256 bytes of the JSR/RTS stack, and given I'm only using four levels I'm wasting 4x more than that built-in stack, but it's 2K of the 256K of my system and thus less than 1%.

And again, the tradeoff is that I know at all times where a parameter is supposed to be. It has saved me hours of debugging by looking at the listing, dumping the address, and seeing that the value isn't where it should be.


True, but with 256 bytes per level, so far there is always plenty of extra space. So worst case I could add a half level, putting the parameters of the squeezed-in subroutine as %%n.127, %%n.126, ... downward instead of upward, highly unlikely to clash with the subroutine making the call unless it expects dozens of parameters.

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!