The PowerPC has a concept of a “glue routine”. This is a little block of code to assist with control transfer, most of the time to allow a caller in one module to call a function in another module. There are two things that make glue routines tricky: Jumping to the final target and juggling two tables of contents (the caller’s and the callee’s). <\/p>\n
Registers r11<\/var> and r12<\/var> are available to glue routines as scratch registers. You can use them in your code, but be aware that they may be trashed by a glue routine, which means in practice that they are good only until the next taken jump instruction. (We saw earlier that r12<\/var> is used by prologues, but since prologues run at the start of a function, and you must have jumped there, prologues are welcome to use r12<\/var> as a scratch register because any valid caller must have assumed that r12<\/var> could have been trashed by a glue routine anyway.) <\/p>\n Let’s take care of the easy case first: Suppose the routines share the same table of contents. This is usually the case if the caller and callee are in the same module. A glue routine may become necessary if a branch target ends up being too far away to be reached by the original branch, and the linker needs to insert a glue routine near the caller that in turn jumps to the callee. (On the Alpha AXP, this is called a trampoline<\/i><\/a>.) <\/p>\n Exercise<\/b>: We had two choices for the register to use for the indirect jump. We could have used ctr<\/var> or lr<\/var>. Why did we choose ctr<\/var>? <\/p>\n Next is the hard part: A glue routine that needs to connect functions that may have different tables of contents. This sort of thing happens if you naïvely import a function. <\/p>\n The inter-module glue function sets up both the code pointer and the table of contents for the destination function. But there’s the question of what to do with the old table of contents. For now, we save it in one of the reserved words on the stack, but we’re still in trouble because the callee will return back to the caller with the wrong table of contents. Oh no! <\/p>\n The solution is to have the compiler leave a The system also leaves the word at If the compiler can prove² that the call destination uses the same table of contents as the caller, then it can omit the The glue code saves the table of contents at Exercise<\/b>: Discuss the impact of glue routines on tail call elimination. <\/p>\n\n bl toofar_glue\n ...\n\ntoofar_glue:\n lwz r11, n(r2) ; r11 = original jump target (toofar)\n mtctr r11 ; ctr = original jump target (toofar)\n bctr ; and jump to toofar\n<\/pre>\n
\n bl toofar_glue\n ...\n\ntoofar_glue:\n lwz r11, n(r2) ; r11 = function pointer\n lwz r12, 0(r11) ; r12 = code pointer\n stw r2, 4(r1) ; save caller's table of contents\n mtctr r12 ; ctr = code for target\n lwz r2, 4(r11) ; load callee's table of contents\n bctr ; and jump to toofar\n<\/pre>\n
nop<\/code> after every call that might be to a glue routine that jumps to another module. If the linker determines that the call target is indeed a glue routine, then it patches the nop to lwz r2, 4(r1)<\/code> to reload the caller’s table of contents. So from the caller’s perspective, calling a glue routine looks like this: <\/p>\n\n ; before\n bl toofar ; not sure if this is a glue routine or not\n nop ; so let's drop a nop here just in case\n\n ; after the linker inserts the glue routine\n bl toofar_glue ; turns out this was a glue routine after all\n ldw r2, 4(r1) ; reload caller's table of contents\n<\/pre>\n
8(r1)<\/code> available for the runtime, but I don’t see any code actually using it.¹ The remaining three reserved words in the stack frame have not been assigned a purpose yet; they remain reserved. <\/p>\nnop<\/code>. <\/p>\n4(r1)<\/code>, but the calling function may have already saved its table of contents on the stack, in which case saving the table of contents again<\/i> is redundant. On the other hand, if a function does not call through any function pointers, then it doesn’t explicitly manage its table of contents because it figures the table of contents will never need to be restored. So there’s a trade-off here: Do you force every function to save its table of contents on the stack just in case it calls a glue routine (and teach the linker how to fish the table of contents back out, so it can replace the nop<\/code> with the correct reload instruction)? Or do you incur an extra store at every call to a glue routine? Windows chose the latter. My guess is that glue routines are already a bit expensive, so making them marginally more expensive is better than penalizing every non-leaf function with extra work that might end up not needed after all.³ <\/p>\n