These are my notes for where I can see both PPC and SPU varying from ia32, as presented in the video Part 3 — GDB Usage Primer. The usage of gdb is effectively the same for all three architectures — I’ve noted here some of the differences in the program being debugged.
In the ia32 disassembly of SimpleDemo.c, the call instruction is generated for function calls.
When compiled for PPC, I see bl — branch to address offset from bl instruction, placing the address of the following instruction in the link register (lr).
When compiled for SPU, I see brsl — branch to address offset from brsl instruction, placing the address of the following instruction into the specified register (typically r0, used as link register).
Neither PPC nor SPU pass args on the stack (at least not for two scalar args as for the add function in SimpleDemo.c). Those values can still be seen as being present on the stack when examining it in gdb. The reason appears to be that when compiled with no optimisation, a number of registers are pushed to the stack that are not needed. Compiling at -O1 eliminates the superfluous pushes, so the args are no longer visible there, being present in the appropriate registers when the function is called.
(This document on calling conventions from Intel seems to say that args get passed to functions in regs where possible on ia32 as well… I can see it happening for amd64, not ia32)
As noted above, PPC and SPU store the function return address in the link register (lr or r0), not on the stack.
All three architectures appear to put the return value in a register (eax or r3).
Previous assembly primer notes…
Part 1 — System Organization — PPC — SPU
Part 2 — Memory Organisation — SPU