The calling convention used by Windows CE for the SH-3 processor looks very much like the calling convention for other RISC architectures on Windows.<\/p>\n
The short version is that the first four parameters (assuming they are all 32-bit integers) are passed in registers r4<\/var> through r7<\/var>, and the rest go onto the stack after a 16-byte gap. The 16-byte gap is the home space for the register parameters, and even if a function accepts fewer than four parameters, you must still provide a full 16 bytes of home space.<\/p>\n More strictly, the first 16 bytes of parameters are passed in registers r4<\/var> through r7<\/var>. If a parameter is a floating point type, then how it gets passed depends on how the parameter is declared in the function prototype.<\/p>\n The reason for this rule is the same as before. Variadic parameters go into integer registers because the callee doesn’t know what type they are upon function entry. To make things easier, variadic parameters are always passed in integer registers, so that the callee can just spill them into the home space and treat them all as stack-based parameters. And unprototyped functions pass the floating point values in both floating point and integer registers because it doesn’t know whether the function is going to treat them as variadic or non-variadic, so it has to cover both bases.<\/p>\n On entry to the function, the return address is provided in the pr<\/var> register, and on exit the function’s return value is placed in the r0<\/var> register. However, if the function’s return value is larger than 32 bits, then a secret first parameter is passed which is a pointer to a buffer to receive the return value. The parameters are caller-clean; the function must return with the stack pointer at the same value it had when control entered.<\/p>\n If the concept of home space offends you, you can think of it as a 16-byte red zone that sits above the stack pointer<\/a>.<\/p>\n The stack for a typical function looks like this:<\/p>\n The function typically starts by pushing onto the stack any nonvolatile registers, as well as its return address. This takes advantage of the pre-decrement addressing mode. In practice, the Microsoft C compiler allocates nonvolatile registers starting at r8<\/var> and increasing, and preserves them on the stack in that order, followed by the return address.<\/p>\n In this example, the function has four registers to save, plus the return address.<\/p>\n At some point (perhaps not immediately), the function will adjust its stack pointer to create space for its local variables and outbound parameters. If the function has a small stack frame, it can use the immediate form of the If the function has a large stack frame, it will be difficult to access variables far away from r15<\/var> due to the limited reach of the register indirect with displacement<\/i> addressing mode. To help with this problem, the compiler might park the frame pointer register r14<\/var> in the middle of the frame, or at least close to a frequently-used variable, so that it can reach more local variables in a single instruction.<\/p>\n At the exit of the function, the operations performed in the prologue are reversed: The stack pointer is adjusted to point to the saved return address, and the saved registers are popped off the stack. Finally, the function returns with a Lightweight leaf functions are those which call no other functions and which can accomplish their task using only volatile registers and the 16 bytes of home space. Such functions may not modify the pr<\/var> register or any nonvolatile registers (which includes the stack pointer).<\/p>\n\n
\n\n
\n MIPS<\/th>\n Contents<\/th>\n \u00a0<\/td>\n SH-3<\/th>\n Contents<\/th>\n<\/tr>\n \n a0<\/var><\/td>\n a<\/var><\/td>\n r4<\/var><\/td>\n a<\/var><\/td>\n<\/tr>\n \n a1<\/var><\/td>\n unused<\/td>\n r5<\/var><\/td>\n b<\/var><\/td>\n<\/tr>\n \n a2<\/var><\/td>\n b<\/var><\/td>\n r6<\/var><\/td>\n<\/tr>\n \n a3<\/var><\/td>\n r7<\/var><\/td>\n c<\/var><\/td>\n<\/tr>\n \n on stack<\/td>\n c<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n
\n \u22ee<\/td>\n<\/tr>\n \n param 6<\/td>\n (if function accepts more than 4 parameters)<\/td>\n<\/tr>\n \n param 5<\/td>\n (if function accepts more than 4 parameters)<\/td>\n<\/tr>\n \n param 4 home space<\/td>\n<\/tr>\n \n param 3 home space<\/td>\n<\/tr>\n \n param 2 home space<\/td>\n<\/tr>\n \n param 1 home space<\/td>\n \u2190 stack pointer at function entry<\/td>\n<\/tr>\n \n \n \n saved return address<\/td>\n \u2190 stack pointer after saving registers<\/td>\n<\/tr>\n \n \n \n \n \n param 4 home space<\/td>\n<\/tr>\n \n param 3 home space<\/td>\n<\/tr>\n \n param 2 home space<\/td>\n<\/tr>\n \n param 1 home space<\/td>\n \u2190 stack pointer after prologue complete<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n function_start:\r\n MOV.L r8, @-r15 ; push r8\r\n MOV.L r9, @-r15 ; push r9\r\n MOV.L r10, @-r15 ; push r10\r\n MOV.L r11, @-r15 ; push r11\r\n STS.L pr, @-r15 ; push pr\r\n<\/pre>\n
SUB<\/code> instruction. Otherwise, it’s probably going to load a constant into a register and use that as the input to the two-register form of the SUB<\/code> instruction.<\/p>\nrts<\/code>.<\/p>\n LDS.L @r15+, pr ; pop pr\r\n MOV.L @r15+, r11 ; pop r11\r\n MOV.L @r15+, r10 ; pop r10\r\n MOV.L @r15+, r9 ; pop r9\r\n RTS ; return\r\n MOV.L @r15+, r8 ; pop r8 (in the delay slot)\r\n<\/pre>\n