{"id":90801,"date":"2015-07-29T07:00:00","date_gmt":"2015-07-29T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/20150729-00\/?p=90801\/"},"modified":"2019-03-13T12:17:50","modified_gmt":"2019-03-13T19:17:50","slug":"20150729-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20150729-00\/?p=90801","title":{"rendered":"The Itanium processor, part 3: The Windows calling convention, how parameters are passed"},"content":{"rendered":"

The calling convention on Itanium uses a variable-sized register window. The mechanism by which this is done is rather complicated, so I’m first going to present a conceptual version, and then I’ll come back and fix up some of the implementation details. For today, I’m just going to talk about how parameters are passed. There are other aspects of the calling convention that I will cover in separate articles. <\/p>\n

Recall that the first 32 registers r0<\/var> through r31<\/var> are static (do not change), and the remaining registers r32<\/var> through r127<\/var> are stacked. These stacked registers fall into three categories: input registers<\/i>, local registers<\/i>, and output registers<\/i>. <\/p>\n

The input registers receive the function parameters. On entry to a function, the function’s parameters are received in registers starting at r32<\/var> and increasing. For example, a function that takes two parameters receives the first parameter in r32<\/var> and the second parameter in r33<\/var>. <\/p>\n

Immediately after the input registers are the registers for the function’s private use. These are known as local registers<\/i>. For example, if that function with two parameters also wants four registers for private use, those private registers would be r34<\/var> through r37<\/var>. <\/p>\n

After the input registers are the registers used to call other functions, known as output registers<\/i>.¹ For example, if the function with two parameters and four local registers wants to call a function that has three parameters, it would put those parameters in registers r38<\/var> through r40<\/var>. Therefore, a function needs as many output registers as the maximum number of parameters of any function it calls. <\/p>\n

The input registers and local registers are collectively known as the local region<\/i>. The input registers, local registers, and output registers are collectively known as the register frame<\/i>. <\/p>\n

Any registers higher than the last output register are off-limits to the function, and we shall henceforth pretend they do not exist. Since the registers go up to r127<\/var>, and in practice register frames are around one or two dozen registers, there end up being a lot of registers that go unused. <\/p>\n

The first thing a function does is notify the processor of its intended register usage. It uses the alloc<\/code> instruction to say how many input registers, local registers, and output registers it needs. <\/p>\n

\nalloc r35 = ar.pfs, 2, 4, 3, 0\n<\/pre>\n
This means, “Set up my register frame as follows: Two input registers, four local registers, three output registers, and no rotating registers. Put the previous register frame state (pfs<\/var>) in register r35<\/var>.” <\/p>\n
The second thing a function does is save the return address, typically in one of the local registers it just created. For example, the above alloc<\/code> might be followed by <\/p>\n
\nmov r34 = rp\n<\/pre>\n
On entry to a function, the rp<\/var> register contains the caller’s return address, and most of the time, the compiler will save the return address in a register. Note that this means that on the Itanium, a stack buffer overrun will never overwrite a return address, since return addresses are not kept on the stack. (Let that sink in. On Itanium, return addresses are not kept on the stack<\/i>. This means that tricks like _Address­Of­Return­Address<\/code><\/a> will not work!) <\/p>\n
By convention, the rp<\/var> and ar.pfs<\/var> are saved in consecutive registers (here, r34<\/var> and r35<\/var>). This convention makes exception unwinding slightly easier. <\/p>\n
Let’s see what happens when somebody calls this function. Suppose the caller’s register frame looks like this: <\/p>\n\n\n\n\n
static<\/td>\n<\/td>\nlocal region<\/td>\noutput<\/td>\n<\/tr>\n
input<\/td>\nlocal<\/td>\n<\/tr>\n
r0<\/var><\/td>\nr1<\/var><\/td>\n…<\/td>\nr30<\/var><\/td>\nr31<\/var><\/td>\nr32<\/var><\/td>\nr33<\/var><\/td>\nr34<\/var><\/td>\nr35<\/var><\/td>\nr36<\/var><\/td>\nr37<\/var><\/td>\nr38<\/var><\/td>\nr39<\/var><\/td>\nr40<\/var><\/td>\nr41<\/var><\/td>\n<\/tr>\n<\/table>\n
The caller places the parameters to our function in its output registers, in this case r37<\/var> and r38<\/var>. (Our function takes only two parameters, so r39<\/var> and beyond are not used.) <\/p>\n\n\n\n\n\n
static<\/td>\n<\/td>\nlocal region<\/td>\noutput<\/td>\n<\/tr>\n
input<\/td>\nlocal<\/td>\n<\/tr>\n
r0<\/var><\/td>\nr1<\/var><\/td>\n…<\/td>\nr30<\/var><\/td>\nr31<\/var><\/td>\nr32<\/var><\/td>\nr33<\/var><\/td>\nr34<\/var><\/td>\nr35<\/var><\/td>\nr36<\/var><\/td>\nr37<\/var><\/td>\nr38<\/var><\/td>\nr39<\/var><\/td>\nr40<\/var><\/td>\nr41<\/var><\/td>\n<\/tr>\n
0<\/td>\nA<\/td>\n…<\/td>\nF<\/td>\nG<\/td>\nH<\/td>\nI<\/td>\nJ<\/td>\nK<\/td>\nL<\/td>\nM<\/td>\nN<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n<\/table>\n
The caller then invokes our function. <\/p>\n
Our function opens by performing this alloc<\/code>, declaring two input registers, four local registers, and three output registers. <\/p>\n
\nalloc r35 = ar.pfs, 2, 4, 3, 0\n<\/pre>\n
That alloc<\/code> instruction shuffles the registers like this: <\/p>\n