Optiroc wrote:
Passing addresses to a subroutine using only registers is thus not as straight forward as on 65816 or Z80. If you'd really want to, I guess it's most effective to put the address in YA, and then in the subroutine use "movw $dp,ya" to move the argument into a zeropage address. Which is all pretty moot since you're using a fixed zeropage address in the end, anyway...
The common pattern in to reserve different zeropage addresses for specific tasks and just write to those addresses before calling the subroutine. That's how the C64 basic kernal work, and most other 65xx code I've looked at.
Another approach, which I've seen in some SNES games, is to use a fixed zeropage range more like a register file, which is pushed/pulled together with the actual registers when necessary. Not as crazy as it sounds for some designs, I suppose – but for the specific and isolated tasks you usually do on the SPC700 I don't really see an argument for not using the zeropage as a fast (and huge) scratchpad.
I'm of the opinion, that if you're gonna write code - you should probably have a perspective/mentality of a software engineer, not a hardware engineer. From your perspective, if those 256 bytes of zeropage were located on the processor vs ram, it'd be accessed the same way with the same opcodes (you'd still need one extra byte to complete the effective address because that's too many registers to be emdedded into an 8bit opcode). When I'm writing code on the original 68k cpu, I don't give a crap that the ALU is 16bit and the microcoded opcodes use a dual pass on it; I'm writing code for a 32bit processor. And I treat it as such.
ZP are just registers in external memory instead of internal. Voila - up to 128
address registers, or 256
data registers. However you use them. Thus, is becomes
straight forward in how to use them. If you're pointing to a string of arguments with HL or BC on the z80, then you're doing the same thing with any ZP pair. It's no different. I even push ZP bytes into the hardware stack, as if I were pushing cpu regs on the stack - because I needed nested routine support using the same "regs".