Now that we understand function calls and the table of contents, we can demonstrate some common calling sequences. If you are debugging through PowerPC code, you’ll need to be able to recognize these different types of calling sequences in order to keep your bearings. <\/p>\n
Non-virtual calls generally look like this:<\/p>\n
\n ; Put the parameters in r3 through r10,\n ; and additional parameters go on the stack\n ; after the home space (not shown here).\n mr r3, r30 ; parameter 1 copied from another register\n li r4, 1 ; parameter 2 is calculated in place\n add r5, r1, 32 ; parameter 3 is address of local variable\n bl destination ; call the function\n nop ; no need to restore table of contents\n<\/pre>\nThe final
nop<\/code> may be omitted if the compiler can prove thatdestination<\/code> is a function in the same module. If it turns out that the destination is a glue function, then thenop<\/code> becomes<\/p>\n\n lwz r2, 4(r1) ; restore table of contents\n<\/pre>\nVirtual calls load the destination from the target’s vtable, and it’s a function pointer, so we need to prepare the destination’s table of contents as well. <\/p>\n
\n ; \"this\" passed in r3. Other parameters go\n ; into r4 through r10, with additional parameters\n ; on the stack after the home space (not shown here).\n mr r3, r30 ; parameter 1 copied from another register\n li r4, 1 ; parameter 2 is calculated in place\n add r5, r1, 32 ; parameter 3 is address of local variable\n lwz r11, (r3) ; r11 = vtable of target\n lwz r11, n(r11) ; r11 = function pointer from vtable\n lwz r12, 0(r11) ; r12 = address of code\n lwz r2, 4(r11) ; load table of contents for destination\n mtctr r12 ; put code address into ctr\n bctrl ; and call it\n lwz r2, n(r1) ; restore our table of contents<\/font>\n<\/pre>\nI put all of the virtual dispatch code in one block of contiguous instructions, but in practice the compiler may choose to interleave it with the preparation of the function arguments to avoid data load stalls. The above example uses r11<\/var> and r12<\/var> as temporary registers for preparing the call, but in practice, the compiler will use any volatile register that is not being used to pass parameters.¹ <\/p>\n
A call to an imported function indirects through the import address table entry. This is made double-complicated because we have to ask the current table of contents where the import address table entry is, and then we need to set up the table of contents for the destination. <\/p>\n
\n ; Put the parameters in r3 through r10,\n ; and additional parameters go on the stack\n ; after the home space (not shown here).\n mr r3, r30 ; parameter 1 copied from another register\n li r4, 1 ; parameter 2 is calculated in place\n add r5, r1, 32 ; parameter 3 is address of local variable\n lwz r11, n(r2) ; r11 points to import address table entry\n lwz r11, (r11) ; r11 = point address table entry<\/font>\n lwz r12, 0(r11) ; r12 = address of code\n lwz r2, 4(r11) ; load table of contents for destination\n mtctr r12 ; put code address into ctr\n bctrl ; and call it\n lwz r2, n(r1) ; restore our table of contents\n<\/pre>\nA call to an imported function incurs several memory accesses: <\/p>\n
\n
- Loading the address of the import address table entry from the table of contents.<\/li>\n
- Loading the function pointer from the import address table.<\/li>\n
- Loading the destination function’s code pointer and table of contents from the descriptor.<\/li>\n<\/ol>\n
I put the last two together since they almost always come from the same cache line. The theory is that the load from the table of contents is probably also in cache, so it should be relatively cheap. (I don’t know how well this holds up in practice.) <\/p>\n
If the compiler sees multiple calls to the same imported function, it will often put the address of the import address table entry into a non-volatile register so it can avoid the load from the table of contents for the second and subsequent times it calls the function. <\/p>\n
The last interesting calling pattern for today is the jump table, commonly used for dense
switch<\/code> statements. Suppose we have this: <\/p>\n\n switch (n) {\n case 1: ...; break;\n case 2: ...; break;\n case 3: ...; break;\n case 4: ...; break;\n }\n<\/pre>\nThe resulting code would look like this:² <\/p>\n
\n ; jump to address based on value in r3\n addi r3, r3, -1 ; subtract 1\n cmplwi r3, 4 ; in range of the jump table?\n bnl default ; nope, go to the \"case default\"\n lwz r12, n(r2) ; get address of jump table\n rlwinm r3, r3, 2, 0, 29 ; convert to byte offset\n lwzx r12, r12, r3 ; load entry from jump table\n mtctr r12 ; put code address into ctr\n bctr ; and jump there\n<\/pre>\nThe jump table pattern first performs a single-comparison range check by the standard trick of offseting the control value by the lowest value in the range and using an unsigned comparison against the length of the range. Asssuming the range check passes, we have to load the address of the jump table from the table of contents, then use the adjusted value (shifted left by 2) to index into the jump table to fetch the jump destination. We then move the jump destination into
ctr<\/code> and jump to it. <\/p>\n