Gameboy Development Forum

bbsfoo wrote:

thank you for sharing

Thank you for checking it out!

I've posted the source to https://github.com/DonaldHays/snake-gb . I have a number of questions before starting another project, so first and foremost:

Argument-passing and register management. For the most part, I pass arguments directly in registers, and place return values in registers, and have doc comments that note which registers are "destroyed" by the routine (have their value changed to something that the subroutine does not specify). Routines are also obviously able to read data from memory. One thing I didn't do, but read a little bit about, was push arguments onto the call stack. I've noticed that there are some instructions that deal particularly with SP, and look to be meant to be used to handle arguments on the stack. Are there any articles or tutorials about using the stack for arguments? My Googling failed to turn up much other than really basic descriptions of, say, the LD HL, [SP+n] opcode. Or could somebody kindly walk through an example of pushing an argument onto the stack, calling a subroutine, reading the argument in the subroutine, and then returning and cleaning up the stack appropriately?

Thanks for taking the time to reply, Shonumi! Unfortunately, that's not quite what I was looking for. I apologize for failing to communicate clearly!

I didn't mean to ask about pushing and popping registers in general, but rather about pushing values onto the stack in order for a subroutine to use them as arguments. In my game I didn't run into any particular situations where I wanted to do that (everything I wanted to pass to my subroutines fit in registers), but imagine a situation where you want to pass a lot of data to a subroutine, like, for example, six arbitrary pointers. If you want to pass that much data to a subroutine, you don't have enough room to pass them in via registers. You could write them to a buffer in RAM and just pass the routine the address to the buffer, but let's ignore RAM techniques like that for now. The third way you could pass the arguments is by pushing the pointers onto the stack, and then calling the routine, which then examines the pointers on the stack. Instructions like LD HL, [SP+n] appear to be built specifically for this purpose. So my inquiry was asking about that, if there's any material written about using the stack as means of passing arguments.

Yeah, that's exactly what I was looking for, thanks, Shonumi!

I wonder how common such techniques were in practice. I mean, they made an instruction dedicated to it. GBDK's output makes copious use of it for argument passing. But in games that are written in assembly from the start, I wonder how many do those sort of arguments-on-the-stack things, vs how many only use registers and RAM. Maybe the instruction is there primarily to accommodate compilers of higher-level languages?

Also, since calling a subroutine pushes the return address to the top of the stack, such stack reading would need to take that into account, right? In your first example, when you pop HL in `mysubroutine`, HL will then hold the return address, not $CODE, right?

Last edited by DonaldHays (2016-08-04 16:45:17)

AntonioND wrote:

"ld hl,[sp+n]" doesn't exist, it's "ld hl,sp+n". It just loads to HL the value of SP+n, not the value in that address.

That kind of instruction is used a lot by GDBK, not so much by hand-made assembly code. I sometimes use it, but I try not to and divide my function into smaller ones if I think it's getting to complex.

PS: Some assemblers also accept "jp [hl]", which is incorrect, it should be "jp hl". And the assembler used by GBDK has a crazy way of writing some instructions like "add sp,n" or "ld hl,sp+n".

Whoops! My bad, you're correct. All of my GBZ80 code is hand-made as hexadecimal values, so I suppose I overlooked that detail. The syntax should have been a red-flag. I rarely use that instruction any way, probably also explains why I didn't catch it. In that case, everyone can ignore the latter half of my previous post.

DonaldHays wrote:

I wonder how common such techniques were in practice. I mean, they made an instruction dedicated to it. GBDK's output makes copious use of it for argument passing. But in games that are written in assembly from the start, I wonder how many do those sort of arguments-on-the-stack things, vs how many only use registers and RAM. Maybe the instruction is there primarily to accommodate compilers of higher-level languages?

Using the stack like that is probably more common on the GBA where the stack itself is much more flexible and you get way more registers to play with. As I said before stack operations are 16-bit, so they can take up a lot of cycles if you're not careful. If you did have something like that, I'd suspect it'd be on the GBC where you can take more liberties with the system.

DonaldHays wrote:

Also, since calling a subroutine pushes the return address to the top of the stack, such stack reading would need to take that into account, right? In your first example, when you pop HL in `mysubroutine`, HL will then hold the return address, not $CODE, right?

Yeah, totally glossed over that little bit. At the beginning of the routine, you should find a way to save the original SP (if you don't know how much you're going to change it), then move it so that it points to $C0DE. Keep calling POP and when you're done, restore SP. The easiest method would be to use ADD SP+n to subtract and add values to SP ("n" here is still a signed byte). E.g.

... Assume SP is at $C006
... Assume we only PUSH $DEAD $C0DE

LD HL, $DEAD
PUSH HL
LD HL, $C0DE
PUSH HL


CALL mysubroutine
    ... SP is now at $C000, with $C000-$C001 being the return address, $C002-$C003 being $C0DE, and $C004-$C005 being $DEAD
    ... At the beginning move SP ourselves
    ADD SP + 2

    POP HL
    ... Do something with the pointer

    POP HL
    ... Do something again

    ADD SP -6
    RET
    ... SP will be $C006, but we need $C000 before we return

Last edited by Shonumi (2016-08-04 19:58:03)

Yeah, the homebrew GB documentation isn't the most accurate in the world...