Why use static RAM addresses instead of the stack?

Question

I'm studying the 65c816 assembly for the 1994 game, Super Metroid.

A hobbyist studied the game in-depth and created a RAM map. From it:

7E:0B56 - 7E:0B57    Moves Samus this distance horizontally, in subpixels.
7E:0B58 - 7E:0B59    Moves Samus this distance horizontally, in pixels.
7E:0B5A - 7E:0B5B    Moves Samus this distance vertically, in subpixels.
7E:0B5C - 7E:0B5D    Moves Samus this distance vertically, in pixels.

I'm new to assembly, but as I understand it, the game stores Samus's movement in RAM, to be picked up later by some code that performs the actual moving (the "function"). But why do things this way? Why not simply push the above "parameters" onto the stack and pop them from within the "function"? Is storing the parameters in static addresses somehow more efficient? Is it to save space on the stack? Is it for better code organization?

Answer 1

The 8 bit 6502 family doesn't have any stack-relative addressing modes that would make it easy to use the stack for variable storage. One can access values on the stack with a sequence such as TSX; LDA &102, X, but that's slower, clobbers X, and uses more memory (both in code size and stack usage) than a global variable.

The 65C816 adds stack-relative instructions such as LDA 2, S, so it is now plausible to use local variables on the stack. But global variables were idiomatic on the 6502 and old habits die hard…

Answer 2

Off the top of my head I can think of two reasons, there are probably more.

The first reason is that these variables may be set by a routine each frame, and then a lot of code uses them during the time of the whole frame. Every interrupt routine that fires during that frame may want to read out the current direction.

The second reason is that, in a real-time embedded environment¹ like a console game, it's important to know that you have enough resources to handle the worst-case conditions. One resource is time; you want to make sure that everything you want to perform can be handled in one frame update. Another resource, and relevant in this case, is memory. Whatever happens, you can't run out of memory². There's no swap space, you can't pop up a requester, or kill off something else. Add to this the fact that embedded platforms like this do not have any form of memory protection, so if you write too much on the stack — game over, man.

The combination of these two makes it reasonable to reserve RAM for variables like this.

---

^{1. These platforms still exist today, think control systems for robots, your fridge, basically every "hidden" microcontroller.}

^{2. I've recently worked with an operating system designed for high reliability. It had every type of dynamic allocations removed. No malloc() for you.}

Answer 3

As mentioned previously the timing issue is the cause not to waste time in pushing up parameters, access them with cost-intensive addressing modes and pull them finally from stack. Too much action if this occurs in a tight, time-critical frame building routine. In a games of a certain size usually all could be handled with global variables. Some state of the game has to be held into globals anyway. It's a just a waste of time to copy the global state into local parameters all the time. There is no advantage or gain to use high-level language structures like parameter passing to functions or subroutines. Local variable protection, opaque variables, a common calling interface convention and so on are simply not necessary in a closed world of a game. An important exception is the calling interface to a surrounding operating system, to attach a game to the system environment and using its resources or gain access to libraries with offers graphical or sound support and so on (3D engines, sound players, ...).

Larger developments or projects tend to use a high-level language which implies the usage of such techniques. On assembler level you have only to bother with the high-level calling interface if you want to embed such routines for (mostly) time-critical reasons. It can simply seen as a connection of some assembly with the rest of the project in high-level.

Answer 4

It's also worth pointing out that the intricacies of maintaining variables on the stack can result in slower code. And of course there are limits to how big the stack can be; even with the more expansive stack on the 65816, you're still limited to a fraction of bank $00 (so 64K minus the direct page(s) minus any other stacks you have around minus any I/O space or ROM or the like you have. So preserving bank zero space for use by other code that actually has to use it is pretty critical.

As has been pointed out, the '816 does have stack relative addressing. But it's a little awkward and is very easy to screw up. If you make any changes to the configuration of the stack, you can mess up all kinds of stuff with things getting misaligned. Especially if you pass parameters on the stack.

So it's just so much easier to not use the stack that way unless you're either (a) really sure of what you're doing or (b) really sure it will make a huge difference.

Answer 5

Code written in high-level languages do a lot of stack-relative operations, because compilers are good at keeping track of which stack offset refers to which variable in the current context.

In hand-written assembly code it was often more common to store things as 'globals' in well-known memory locations, just because it's easier for humans to think about memory layout in that way. If recursion or concurrent instances are not needed in a particular function, then global storage is a possible solution.

I worked on Z80 and 8086 assembly code software systems back in the day, and even though both of these processors have index registers that would allow stack-relative storage of variables, it was common practice to store variables as globals.

Answer 6

Another example in the tightly constrained world of games - especially those with a real-time loop (e.g., for updating the display on a fixed schedule): there was no space for a "task queue" and/or no time for a "rendezvous" mechanism that would enable data to be passed from one thread to another in one of the "structured" methods that would be more common today. Instead, the programmer passed data via global variables and was responsible for analyzing (and preventing or mitigating) data races and other concurrency hazards. These solutions are fast and cheap at runtime, slow and expensive at coding time ...

BTW, when looking at older code for very resource-constrained systems you'll frequently find coding techniques that are generally shunned today - for good reason! The most egregious would be self-modifying code which was much more common on earlier and/or smaller architectures with less choice of addressing modes, fewer registers, etc. Look at those mechanisms and marvel how we were able to do so much with so little ... and in such a way that it nearly always worked!

Answer 7

From your description, it sounds like a normal thing to do even today — you just have the wrong model in your head.

The description sounds like there is a "physics" thread responsible for updating the state of the game world, and updates happen periodically (say... once per frame, just before rendering).

When some routine wishes to move Samus Aran, it doesn't do it directly; instead it would invoke a method to queue up the change, and then the next time the physics thread runs, it executes all of the changes at once.

This model makes it easier to ensure regular updates of the world state. Additionally, if multiple changes happen between frames, it is likely much more efficient to only have to calculate the effect of motion once per frame rather than doing so after each individual event.

---

The gameplay of Super Metroid appears to be so that the motion doesn't need to be broken into individual events, and so it doesn't need an actual queue; instead the changes in each direction simply get added up, and only the total change in each direction effected.

(naturally, the method to queue up the change would be inlined, so you wouldn't see a function call at all)