Hi guys, I recently came across this pattern in the Acorn DFS 0.90 ROM (http://mdfs.net/Info/Comp/BBC/DFS/DFS090.zip), and wondered whether any of you have come across or used something like it before, and what you all thought of it.

The idea is to create a routine that you can "JSR" into at the start of one of your own routines, and have it save all the registers and arrange for them to be restored automatically when your routine returns, without your routine having to explicitly pull them from the stack.

I initially thought the purpose was to save code size, as I guess it reduces 10 bytes of prologue/epilogue to just 3 bytes of prologue, and also allows tail calls at the end of routines as there's no longer any epilogue needed. But I'm not sure, because that's not a huge amount of space saving. It also strikes me that this is a kind of continuation, and potentially knowing the exact stack shape might allow it to arrange a kind of deferred return later on, e.g. after a latent operation has finished.

I'm not convinced though, so if anyone has any better ideas of the value, do let me know!

The code below is a reformatting of the disassembled code, with my own label names and comments to try to explain what's going on.

In a nutshell though, on entry we have a return address on the stack as usual - which is usually right at the start of one of the ROM's API entry points. And above that is the return address of the caller of that routine. What this code does is first push all the registers to save their values, and then it shuffles the stack frame around so that there are two return frames on the stack. The deepest frame restores the registers and returns to the caller's caller; and the shallow one restores the registers and returns to the caller itself. Between the two is inserted the address of the new epilogue code.

So after rearranging the stack, this fragment's epilogue runs, restoring the registers and returning to the immediate caller; but leaving this epilogue's own address on the stack. So when the caller returns, now it runs this epilogue again, which restores the register from the deeper stack frame, and returns to the caller's caller.

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

Yes, the zip is mostly just a disassembly, with very few annotations. It's the main disc filesystem driver for the BBC Micro, so it implements a wide range of OS APIs, handles how the filesystem is stored on the disc (directories, files, etc) and also deals directly with the disc controller hardware.

As you said, it is a lot of overhead, if the only purpose is to save a few bytes in each subroutine.


Ah yes that looks very interesting, thank you!

_________________
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 quite like the idea. A "JSR saveregs" at the start of a subroutine so I don't have to think about preserving registers (and maybe even the carry flag) at the moment. Then come back and then optimize later. It's a shame that the approach precludes using the registers for return values.

I especially like this in the linked discussion:


I really struggle to settle on a policy for registers. At the moment, I use A and Y for parameters and expect them to be clobbered. It seems to me that parameters to subroutines are not often used after the JSR and can be saved by the caller when they are. Even though I don't use Forth, I use X as the data stack pointer, keeping it in "save_x" (in ZP) on the rare occasion when code needs X such as for the x,indirect addressing mode (indirect pointer in ZP at X). Extra parameters are then on the data stack at X+1, X+2, etc. X is mostly preserved naturally by the code by balanced DEX and INX, though branches can sometimes cause bugs here. The carry flag is useful as a return value if the caller will branch based on the return value. It's a relief to remember that leaf subroutines don't have to worry about being re-entrant.

In my own code I don't have a general policy, I adapt for the needs of what I'm writing.

Some subroutines are intended to have no side-effects, to make them ready to drop in - especially things like text and number output routines which are useful to add and remove during debugging.

Apart from those, I evolve local policies depending on what the code does. A lot of my subroutines are only called in one or a few places, so it's simple to make the caller responsible for saving anything it cares about which is also clobbered (no need to save things that aren't used in the called routine) but if all callers would need to save the same registers, and it would make the code more readable, I may save them in the callee instead


Flags for binary returns are really useful. I never save the flags through a subroutine call. I often use A for returned values, but not if the subroutine needs to save other registers in the stack as my recent code has been for the BBC Micro and so PLX/PLY are not available. So in those cases, returning in X or Y is more straightforward. Again, local policies which are fine when routines are only used internally in a few places.

I've considered suffixing labels with details of which registers a subroutine clobbers, but not gone that far yet.

In my VTL02 interpreter I use X for a global ZP pointer and Y for a global statement offset pointer. Right before or right after interpreting a statement they're fair game, because moving on to the next statement (either program or command line) re-initializes them. Doing things this way is compact, but a little bit bug-prone. IIRC, all of my bugs while developing VTL02 involved not taking proper care of Y.

I have streamlined VTL02C as a back-burner project (smaller and slightly faster), but it's currently buggy, and I'm willing to bet it has something to do with Y ... I should have thoroughly tested my incremental changes more often, but hindsight's 20/20 ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I can't say that the idea of spending so much to automate pushing and pulling of just three registers looks that useful to me, given that on most 8-bit CPUs you're constantly in a state of "what's my state" when programming anyway. But I suppose there are circumstances where that sort of thing might be useful, at least as a temporary thing. Actually, come to think of it, certain debugging situations do come to mind.

But what triggered my interest here was:

I've been experimenting a bit with this sort of thing in the last little while. I've not ported it over to 6502 yet, but you can some ideas in some 6800 code I consed up. I'm not entirely sure of the utility of this yet, but I do use continuations in a somewhat different form in my monitor, where I have both a return specifically set up to be a different location than the "JSR" (not actually that instruction) was done, and also store the stack pointer at a certain point to allow an unwind to that point from any arbitrary depth without having to know the depth.

_________________
Curt J. Sampson - github.com/0cjs