stack pointer start address?

[serige]

In learning assembly language, I am still not quite sure how does the PSP allocation for a program ans its data.

Assume that I am in pre-3.7x fw, now if I have a memory dump from 0x08800000 - 0x08800000 + 0x01800000 = 0x098800000 (I am not sure if I am looking at the right memory region, correct me if I am wrong), what address does $sp point to just after all registers first have been initialized but before the first line of the assembly code get executed?

Since the stack is growing down, I suspect that the $sp will start at 0x098800000. Or will it be different across different types of application (i.e. ISO's vs homebrew apps)?

[Fanjita]

The stack will be different for every thread running, since they all share the same address map (there's no MMU in the PSP) - otherwise, they'd trample on each other's stacks.

If you have access to the thread info structures, you can query those as I believe they store the origin of $SP directly, for each thread. I'm afraid I don't remember where those are stored in RAM, although presumably it's in the kernel memory range. If you know the names of any threads present, you could probably work backwards from finding the addresses of those names in the RAM dump.

In theory you could probably predict the $SP origins for each thread, if you know how many threads are running and what their stack sizes are. But in practice, since about FW 2.5 or so, the stack origin is subject to a small random offset - roughly within the range +/- 512 bytes, IIRC, so that wouldn't be reliable. For that, you can probably blame those naughty people who try to exploit stack overflows ;)

[serige]

Thanks for the clarification.

Assuming in the simplest possible situation, in which you only have the main thread running for the target application (I am not sure if this is the case for every real application out there), in this case, should the initial address of $sp start somewhere at the top of the main ram?

[J.F.]

No, you specify the amount of stack space a thread will use (there's a macro to set it beyond the default value), and it's allocated. So it could be anywhere depending on how memory is in use (other plugins, etc).

That was a bug in SDL I identified a few weeks back... the stack size the SDL_main was specifying was too small for many SDL apps (real apps, not demos). You should set the stack size for your threads to be big enough to allow for local stack usage.

[TyRaNiD]

I am wondering why you need to worry? Let the PSP firmware do its job and handle memory allocation for you and not pay any attention to where you stack ends up :)

[Fanjita]

I am wondering why you need to worry? Let the PSP firmware do its job and handle memory allocation for you and not pay any attention to where you stack ends up :)

I think the aim was to understand how to understand static memory dumps - where of course the firmware can't really help.

However the best way to learn is probably to write an app that will use the firmware funcs to iterate across all the threads, dumping their info, and then dumping the RAM, to get a feel for how it works.

Thanks for the clarification.

Assuming in the simplest possible situation, in which you only have the main thread running for the target application (I am not sure if this is the case for every real application out there), in this case, should the initial address of $sp start somewhere at the top of the main ram?

On the PSP, we don't really talk about threads in the traditional sense - they're much closer to processes on a more familiar OS. So there's never just the main application thread running - there are plenty of OS processes running too.

IIRC there are options on thread creation to create the stack almost anywhere - but I think the default is to create it at the top of the available memory space.