For AArch64, Windows employs two calling conventions. One is for classic 64-bit ARM code and the other (named ARM64EC) is for 64-bit ARM code that is intended to interoperate with x64 emulation. The EC stands for “Emulation Compatible”. We’ll look at the ARM64EC calling convention later.<\/p>\n
The classic calling convention follows the Procedure Call Standard for the ARM 64-bit Architecture<\/a>. This is a rather lengthy document, summarized on MSDN<\/a>, and which I will further simplify here. If you need to dig into the details for weirdo edge cases, go to the other documents.<\/p>\n Integer and pointer parameters are passed in x0<\/var> through x7<\/var>, and floating point parameters go into v0<\/var> through v7<\/var>.<\/p>\n If a parameter does not fill its assigned register or memory, then the value goes into the low-order bits and the upper bits are uninitialized<\/i>.<\/p>\n If a parameter is a large structure (larger than 16 bytes), then it is passed by address. Small structures are passed by value, packed into integer registers. (Execption: If the small structure consists entirely of floats or entirely of doubles, then it is passed in floating point registers, one for each member.)<\/p>\n Each parameter is assigned the next available register for its value class (integer\/pointer or floating point). Since the value goes into the low-order bits, this means that floats are effectively passed in s#<\/var> and doubles in d#<\/var>.<\/p>\n If a parameter is a 128-bit integer, it consumes an even\/odd register pair. This may force an odd-numbered integer register to be skipped.<\/p>\n There is no backfilling, as occurred on AArch32. If a floating point register is used to hold a float, the remaining bits are left unused and cannot be used to hold a later float parameter.<\/p>\n If you run out of registers for a particular value class, future parameters go onto the stack. However, parameters of the other value class can still go into registers if registers are still available.<\/p>\n If a structure does not fit entirely in registers, then it goes completely on the stack.<\/p>\n There is no parameter home space on the stack. At function entry, the first stack-based parameter is stored directly at the top of the stack.<\/p>\n The return value is placed in x0<\/var>\/x1<\/var> or v0<\/var>\/v1<\/var>, depending on its value class. Again, if the return value doesn’t fill the output register, the unused bits are left uninitialized. If the return value doesn’t fit in two registers, then the caller passes as a secret first parameter a pointer to a block of memory that receives the return value.<\/p>\n All stack parameters are caller-clean. In practice, instead of cleaning the stack after every call, the caller preadjusts the stack pointer in its prologue to reserve space for all outbound stack-based parameters and just reuses the space for each function call, doing the cleanup in the epilogue.<\/p>\n Here are some examples:<\/p>\n The parameters that are smaller than a 64-bit register occupy the low-order bits of the 64-bit register, and the upper bits are garbage. The recipient may not assume that the upper bits are the zero-extension or sign-extension of the formal parameter.<\/p>\n Notice that parameter b<\/var> goes into x0<\/var> since it is the first integer\/pointer parameter. The fact that s0<\/var> was taken by a<\/var> is irrelevant.<\/p>\n Note also that parameter d<\/var> goes into s2<\/var> rather than sneaking into the unused upper bits of v0<\/var>.<\/p>\n Since integer\/pointer and floating point parameters are allocated independently, you can have multiple signatures that all use the same underlying calling convention.<\/p>\n In the next example, the structure The first parameter t1<\/var> is passed in registers s0<\/var> through s3<\/var>. Next comes a float, which goes into s4<\/var>. And then comes another Varadic functions follow a different set of register assignment rules: Floating point registers are not used by variadic functions. All floating point parameters are passed as if they were integer parameters: A single-precision floating point parameter is passed as if it were a 32-bit integer, and a double-precision floating point parameter is passed as if it were a 64-bit integer. This rule applies even to the non-variadic parameters.<\/p>\n Next time, we’ll look at how these parameter passing rules are implemented in code.<\/p>\n","protected":false},"excerpt":{"rendered":" How parameters are passed.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-107041","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":" How parameters are passed.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=107041"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107041\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=107041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}void f(int8_t a, int64_t b, int16_t c);\r\n\r\n ; x0[ 7:0] = a\r\n ; x1[63:0] = b\r\n ; x2[15:0] = c\r\n<\/pre>\n
void f(float a, int b, double c, float d)\r\n\r\n ; s0 = a\r\n ; x0[31:0] = b\r\n ; d1 = c\r\n ; s2 = d\r\n<\/pre>\n
void f(int i1, float f1);\r\nvoid f(float f1, int i1);\r\n<\/pre>\n
T<\/code> is a so-called homogeneous floating-point aggregate<\/i>: It consists of a series of identical floating point types. It therefore is passable in floating point registers.<\/p>\nstruct T { float x; float y; float a[2]; };\r\nvoid f(T t1, float f1, T t2, float f2, int i);\r\n\r\n ; s0 = t1.x\r\n ; s1 = t1.y\r\n ; s2 = t1.a[0]\r\n ; s3 = t1.a[1]\r\n ; s4 = f\r\n ; t2 on the stack\r\n ; f2 on the stack\r\n ; w0 = i\r\n<\/pre>\nT<\/code>, but there are not enough registers remaining, so t2<\/var> goes onto the stack. Note that f2<\/var> also goes on the stack; it does not backfill into s5<\/var>. On the other hand, we haven’t run out of integer registers, so i<\/var> can get passed in the low 32 bits of x0<\/var>.<\/p>\n