قراردادهای فراخوانی اکس۸۶
این مقاله توصیف قراردادهای فراخوانی (به انگلیسی: calling conventions) مورد استفاده، در هنگام برنامه‌نویسی میکروپروسسورهای معماری اکس۸۶ است.
قراردادهای فراخوانی، رابط کاربری کد فراخوانی شده را توصیف می‌کند:
این دقیقاً با تخصیص دادنِ اندازه‌ها و فرمت‌ها به انواع زبان برنامه‌نویسی مرتبط است. یکی دیگر از موضوع‌های خیلی مرتبط برانگیختگی نام (Name mangling) است، که تعیین می‌کند که چگونه نمادها در کد به نماد مورد استفاده در لینکر مرتبط و تبدیل شوند. قراردادهای فراخوانی، نمایندگی‌های نوع، و برانگیختگی نام، همه بخشی از آنچه که به عنوان یک رابط دودویی نرم‌افزار شناخته می‌شود هستند.
اغلب تفاوت‌های ظریفی در نحوه پیاده‌سازی این قراردادها در کامپایلر‌های مختلف وجود دارد، بنابراین اغلب سخت است که کدی را که توسط کامپایلرهای مختلف کامپایل شده‌است نمایش دهیم. از سوی دیگر، قراردادهایی که به عنوان استاندارد API (مانند stdcall) مورد استفاده قرار می‌گیرند، به‌طور خیلی یکسان پیاده‌سازی می‌شوند.
قبل از میکرو رایانه‌ها، تولیدکننده دستگاه، به‌طور کلی یک سیستم عامل و کامپایلر‌هایی برای چند زبان برنامه‌نویسی ارائه می‌داد. قرارداد (های) فراخوانی برای هر پلت فرم، توسط ابزار برنامه نویسیِ سازنده آن تعریف می‌شود.
میکرو رایانه‌های اولیه قبل از Commodore Pet و Apple II به‌طور کلی بدون سیستم عامل یا کامپایلرها عرضه می‌شدند. رایانه شخصی IBM با سیستم عامل دیسک (DOS) (پیشگام مایکروسافت برای ویندوز) عرضه شد، اما بدون کامپایلر. تنها سخت‌افزار استاندارد برای ماشین‌های سازگار با رایانه شخصی IBM توسط پردازنده‌های اینتل (۸۰۸۶، ۸۰۳۸۶) تعریف شد که سخت‌افزار تحت اللفظی IBM نامیده می‌شد. سپس فرمت‌های سخت‌افزاری و تمامی استانداردهای نرم‌افزاری (ذخیره برای قراردادهای فراخوانی BIOS) برای رقابت در بازار عرضه شد.
بسیاری از شرکت‌های نرم‌افزارهای مستقل، سیستم عامل‌ها و کامپایلرهایی برای بسیاری از زبان‌های برنامه‌نویسی و برنامه‌های کاربردی ارائه می‌دهند. بسیاری از طرح‌های مختلف فراخوانی کردن توسط شرکت‌ها پیاده‌سازی شده‌است که اغلب متقابلاً منحصر به فرد، بر اساس الزامات مختلف، شیوه‌های تاریخی و خلاقیت برنامه‌نویس هستند.
پس از انعطاف‌پذیری بازار IBM، سیستم عامل‌های و ابزارهای برنامه‌نویسی مایکروسافت (با قراردادهای متفاوت) غالب بودند، در حالی که شرکت‌های رده دوم مثل Borland و Novell و پروژه‌های منبع بازمانند GCC هنوز استانداردهای خود را حفظ کردند. در نهایت مقررات مربوط به قابلیت همکاری بین فروشندگان و محصولات به تصویب رسید، ساده کردن مشکل انتخاب یک قرارداد قابل قبول بود.
در این قراردادها، فراخوانی کننده، آرگومان‌ها را از پشته پاک می‌کند.
cdecl (که بر پایه تعریف C است) یک قرارداد فراخوانی است که از زبان برنامه‌نویسی C سرچشمه می‌گیرد و توسط بسیاری از کامپایلرهای C برای معماری x86 استفاده می‌شود. در cdecl، آرگومان‌های تابع به پشته منتقل می‌شوند. مقادیر اعداد صحیح و آدرس‌های حافظه به وسیلهٔ ثبات (رجیستر) EAX و مقادیر اعشاری در ثبّات ST0 x87 بازگردانده می‌شوند. ثبّات‌های EAX, ECX، و EDX ذخیره شده توسط فراخوانی‌کننده (به انگلیسی: caller-saved) و بقیه ذخیره شده توسط فراخوانی شونده (به انگلیسی: callee-saved) هستند. ثبّات‌های اعشاری x87 T ST0 تا ST7، هنگام فراخوانی یک تابع جدید باید خالی (برداشته شده یا آزاد) باشند و ST1 تا ST7 باید در هنگام خروج از یک تابع خالی باشد. ST0 نیز باید زمانی خالی باشد که برای بازگشت مقدار مورد استفاده قرار نگیرد.
در چارچوب زبان برنامه‌نویسی C، آرگومان‌های تابع بر روی پشته از راست به چپ قرار می‌گیرند، یعنی اول آخرین آرگومان قرار داده می‌شود. در لینوکس، GCC استانداردهای "واقعی را" برای قراردادهای فراخوانی تنظیم می‌کند. از زمان GCC نسخه ۴٫۵، هنگام فراخوانی یک تابع، پشته باید به یک مرز ۱۶ بایت برسد (نسخه‌های قبلی فقط یک تراز ۴ بایت نیاز داشتند)
قطعه کد مرجعِ C زیر را در نظر بگیرید:  int callee(int, int, int);
int caller(void) return callee(1, 2, 3) + 5; caller: push ebp ; save old call frame mov ebp, esp ; initialize new call frame push 3 push 2 push 1 call callee ; call subroutine 'callee' add eax, 5 ; modify subroutine result  ; compilers will usually produce the following instead, mov esp, ebp ; most calling conventions dictate ebp be callee-saved, pop ebp ; restore old call frame ret ; return
برخی تغییرات در بیان cdecl, به ویژه در نحوه بازگشت مقادیر وجود دارد. در نتیجه، برنامه‌های کامپایل شده توسط x86 با سیستم عامل‌های مختلف یا کامپایلرهای مختلف می‌تواند ناسازگار باشد، حتی اگر آن‌ها هر دو از قراردادهای "cdecl" استفاده کنند و به محیط زیر وابسته نباشند. بعضی از کامپایلرها ساختار داده‌های ساده را با طول ۲ ثبّات یا کمتر در جفت ثبّات EAX: EDX برمی‌گردانند، و ساختارهای بزرگتر و اشیاء کلاس‌ها که نیاز به رفتار ویژه توسط رسیدگی کنندهٔ استثنا دارند (مانند سازندهٔ تعریف شده، تخریب‌کننده یا اختصاص دادن) به حافظه برگرداننده می‌شوند. برای انتقال "در حافظه"، فراخوانی‌کننده حافظه را اختصاص می‌دهد و یک اشاره گر به آن را به عنوان پارامتر پنهان می‌دهد؛ فراخوانی شده حافظه را پر می‌کند و اشاره گر را برمی‌گرداند (هنگام بازگشت اشاره گر پنهان برداشته می‌شود).
در لینوکس / GCC، مقادیر اعداد اعشاری هشت بایتی(double) / چهار بایتی(float) باید به وسیلهٔ شبه پشتهٔ x87 روی پشته قرار بگیرند. مثل این:  sub esp, 8 ; make room for the double fld [ebp + x] ; load our double onto the floating point stack fstp [esp] ; push our double onto the stack call funct add esp, 8 قراردادهای فراخوانی cdecl معمولاً قرارداد فراخوانی پیش فرض برای کامپایلر‌های x86 C است، اگر چه بسیاری از کامپایلرها مجهز به گزینه‌هایی برای تغییر خودکار قراردادهای فراخوانیِ استفاده شده هستند. برای تعریف کردن دستی تابع به عنوان cdecl، برخی نحو زیر را پشتیبانی می‌کند:
return_type _cdecl func_name();
این مشابه cdecl است در آن آرگومان‌ها از راست به چپ در استک قرارداده می‌شوند. ECX, EAX و EDX ذخیره نمی‌شوند. اندازه لیست پارامترها در doublewords به AL منتقل می‌شود.
Syscall قرارداد فراخوانی استاندارد برای OS / 2 API سی و دو بیت (۳۲ بیت) است.
آرگومان‌ها از راست به چپ در پشته قرارداده می‌شوند. سه آرگومان اول (چپ‌ترین) در EAX, EDX و ECX منتقل می‌شود و بیشتر از چهار آرگومان اعشاری در ST0 از طریق ST3 منتقل می‌شود، اگرچه فضای آن‌ها در لیست آرگومان‌ها بر پشته رزرو می‌شود. نتایج در EAX یا ST0 برگردانده می‌شوند. ثبّات‌های EBP, EBX, ESI، و EDI حفظ می‌شوند.
Optlink توسط کامپایلر IBM VisualAge استفاده می‌شود.
در این قراردادها، تابع فراخوانی شده، آرگومان‌ها را از پشته پاک می‌کند. تشخیص توابعی ک این قراردادها را استفاده می‌کنند در کد ASM آسان است زیرا آن‌ها پس از بازگشت، پشته را باز می‌کنند. دستور x86 ret به پارامتر ۱۶ بیتی اختیاری اجازه می‌دهد که بعد از بازگشت به فراخوانی کننده، تعداد بایت‌های مشخصی از پشته را آزاد کند. نمونه ای از این کد به صورت زیر است:
بر اساس قرارداد فراخوانی زبان برنامه‌نویسی Borland Pascal، پارامترها بر روی پشته از چپ به راست (مخالف cdecl) قرار می‌گیرند و فراخوانی شده مسئول حذف آن‌ها از پشته است.
بازگشت نتیجه به شرح زیر است:
این قرارداد فراخوانی در APIهای ۱۶ بیتی زیر رایج بود:
OS / 2 1.x، مایکروسافت ویندوز 3.x و Borland Delphi نسخه 1.x. نسخه‌های مدرن ویندوز API از stdcall استفاده می‌کنند، که هنوز هم فراخوانی شده پشته را طبق قرارداد پاسکال را ذخیره می‌کند، اما اکنون پارامترها از راست به چپ قرارداده می‌شوند.
قرارداد فراخوانی stdcall تغییری در قرارداد فراخوانی پاسکال است که در آن فراخوانی شده مسئول پاک کردن پشته است، اما پارامترها در پشته به ترتیب از راست به سمت چپ، همان‌طور که در قرارداد فراخوانی _cdecl قرار دارد، قرار می‌گیرند. ثبّات‌های EAX, ECX و EDX برای استفاده درون تابع تعیین می‌شوند. مقادیر بازگشتی در ثبّات EAX ذخیره می‌شوند.
stdcall استاندارد برای مایکروسافت Win32 API و Open Watcom CPP است.
قرارداد مایکروسافت or GCC fastcall__ (معروف به msfastcall__) دو آرگومان اول (که از چپ به راست به دست می‌آید) را می‌دهد که در ECX و EDX قرار می‌گیرند. آرگومان‌های باقی مانده راست به چپ در پشته قرار می‌گیرند. هنگامی که کامپایلر MS برای IA64 یا AMD64 کامپایل می‌شود، کلمه کلیدیfastcall__ را نادیده می‌گیرد و به جای آن یک قرارداد فراخوانی ۶۴ بیتی را استفاده می‌کند.
در ویژوال استودیو ۲۰۱۳، مایکروسافت قرارداد فراخوانی vectorcall__ پاسخگو به نگرانی‌های توسعه دهندگان کد در مورد کارآییِ بازی‌ها، گرافیک، ویدئو / صدا است. برای کدهای IA-32 و x64، قرارداد vectorcall__ شبیه fastcall__ و قرارداد فراخوانی اصلی x64 است، اما آن‌ها را با پشتیبانی از پاس دادن آرگومان‌های برداری با استفاده از ثبّاتهای SIMD گسترش می‌دهد. برای x64، زمانی که هر یک از شش آرگومان اول، از نوع برداری (float ,double __m128 , __m256 و غیره) باشند، از طریق ثبّاتهای XMM / YMM مربوطه منتقل می‌شوند. به‌طور مشابه برای IA-32، حداکثر تا ۶ ثبّاتها XMM / YMM به صورت تکراری برای آرگومان‌ها از نوع بردار از چپ به راست بدون در نظر گرفتن موقعیت قرار می‌گیرد. علاوه بر این، vectorcall__ پشتیبانی کردن از انتقال مجموعه ای از مقادیر همگن بردار (HVA) را اضافه کرد، که از نوع ترکیبی است که شامل بیش از چهار نوع بردار یکسان است، با استفاده از شش ثبّات یکسان. هنگامی که ثبّاتها برای آرگومان‌های برداری اختصاص داده می‌شوند، ثبّاتهای استفاده نشده به آرگومان‌های HVA از چپ به راست بدون توجه به موقعیت اختصاص داده می‌شوند. نتیجه نوع برداری و مقادیر HVA با استفاده از چهار ثبّات اول XMM / YMM بازگرداننده می‌شود.
ارزیابی آرگومان‌ها از چپ به راست، سه آرگومان را از طریق EAX, EDX, ECX منتقل می‌کند. آرگومان‌های باقی مانده در پشته از چپ به راست قرارداده می‌شوند. این قرارداد فراخوانیِ پیش فرضِ کامپایلر ۳۲ بیتی دلفی است، جایی که به عنوان ثبّات شناخته می‌شود. GCC این قرارداد فراخوانی را با گزینه "regparm = ۳ پشتیبانی می" کند. این به وسیلهٔ هسته لینوکس روی i386 از نسخه ۲٫۶٫۲۰ (منتشر شده در فوریه ۲۰۰۷) استفاده می‌شود. این قرارداد فراخوانی نیز توسط C ++ Builder Embarcadero استفاده می‌شود، جایی که "fastcall__" نامیده می‌شود. در این کامپایلر، "fastcall" مایکروسافت را می‌توان به عنوان "msfastcall__ استفاده کرد".
Watcom از کلمه کلیدی "fastcall__" پشتیبانی نمی‌کند مگر این که نام مستعار آن را null کند. قرارداد فراخوانی ثبّات ممکن است توسط سوئیچ خط فرمان انتخاب شود. (با این حال، IDA از "fastcall__" برای یکنواخت کردن استفاده می‌کند)
تا ۴ ثبّات به ترتیب به آرگومان‌های eax, edx, ebx, ecx اختصاص داده می‌شوند. آرگومان‌ها از چپ به راست به ثبّاتها اختصاص داده می‌شوند. اگر هر آرگومان نتواند به یک ثبّات تخصیص داده شود (می‌گویند خیلی بزرگ است)، آن و تمام آرگومان‌های بعدی به پشته اختصاص داده می‌شوند. آرگومان‌هایی که به پشته اختصاص داده می‌شوند از راست به چپ قرار می‌گیرد. نام‌ها با اضافه کردن پسوند _ تغییر می‌کنند.
توابع متغیر بر اساس قرارداد فراخوانی به پشتهٔ Watcom سقوط می‌کنند.
کامپایلر Watcom C / C ++ نیز از دستور pragma aux# که به کاربر اجازه می‌دهد که خودشان قرارداد فراخوانی خود را مشخص کنند. همان‌طور که در کتابچه راهنمای آن آمده‌است: «تعداد کمی از کاربران احتمالاً به این روش نیاز دارند، اما اگر لازم باشد، می‌تواند یک نجات دهنده باشد».
اولین چهار پارامتر عدد صحیح در ثبّاتهای، ebx, ecx و edx منتقل می‌شوند. پارامترهای اعشاری به پشته اعشاری منتقل می‌شوند - ثبّاتهای st0، st1، st2، st3، st4، st5 و st6. پارامترهای ساختاری همیشه به پشته منتقل می‌شوند. پارامترهای اضافی پس از خروج ثبّاتها به پشته منتقل می‌شوند. مقادیر عدد صحیح در eax، نشانگرها در edx و انواع اعداد اعشاری در st0 بازگرداننده می‌شوند.
در Delphi و Free Pascal روی ویندوز مایکروسافت، قرارداد فراخوانی امن رسیدگی خطای (COM (Component Object Model را بسته‌بندی می‌کند، به این ترتیب استثناها به فراخوانی‌کننده نفوذ نمی‌کنند، اما در مقدار بازگشت HRESULT گزارش می‌شوند، همان‌طور که COM / OLE درخواست داده‌است. در هنگام فراخوانی یک تابعِ safecall از کد دلفی، دلفی به صورت خودکار HRESULT را بررسی می‌کند و در صورت لزوم استثنا را مطرح می‌کند.
قرارداد فراخوانی امن با قرارداد فراخوانی stdcall یکسان است، به جز اینکه آن استثناها به فراخوانی‌کننده در EAX به عنوان یک HResult (به جای در [FS:[0 ) منتقل می‌شوند، در حالی که نتیجه تابع توسط مرجع در پشته( هرچند آن پارامتر نهایی «خارج» باشد ) منتقل می‌شود. هنگام فراخوانی یک تابع دلفی از دلفی، این فراخوانی درست مثل هر قرارداد فراخوانی دیگر ظاهر می‌شود، زیرا هرچند استثنائات در EAX منتقل می‌شوند، آن‌ها به‌طور خودکار به وسیلهٔ فراخوانی‌کننده به حالت استثناء مناسب تبدیل می‌شوند. هنگام استفاده از اشیاء COM که در زبان‌های دیگر ایجاد شده‌است، HResults به صورت خودکار به عنوان استثنا مطرح می‌شود و نتیجه برای دریافت توابع در آن نتیجه است نه یک پارامتر. هنگام ایجاد اشیاء COM در دلفی با استفاده از safecall، نیازی به نگرانی در مورد HResults وجود ندارد، زیرا استثنائات می‌توانند به عنوان نرمال مطرح شوند اما به عنوان HResults در سایر زبان‌ها دیده می‌شود.  function function_name(a: DWORD): DWORD; safecall; function function_name(a: DWORD; out Result: DWORD): HResult; stdcall;
این قرارداد فراخوانی برای فراخوانی توابع عضو غیر استاتیک C ++ استفاده می‌شود. دو نسخه اصلی از thiscall بسته به نوع کامپایلر استفاده می‌شود و اینکه آیا این تابع از یک متغیر عددی از آرگومان‌ها، استفاده می‌کند یا خیر.
برای کامپایلر GCC، قرارداد thiscall تقریباً با cdecl یکسان است :تماس گیرنده پشته را پاک می‌کند، و پارامترها با ترتیب راست به چپ منتقل می‌شوند. تفاوت در اضافه کردن اشاره گر this است که آخرین چیزی است که به پشته منتقل می‌شود، به شرط اینکه اولین پارامتر در نمونه اولیه تابع(function prototype) باشد.
در کامپایلر مایکروسافت ویژوال سی + +، اشاره گر this در ECX منتقل می‌شود و آن "فراخوانی شونده است" که "پشته را" پاک می‌کند، که منعکس کردن قرارداد stdcall مورد استفاده در C برای این کامپایلر و در توابع API ویندوز است. وقتی توابع از یک متغیر عددی از آرگومان‌ها استفاده می‌کنند، فراخوانی‌کننده است که پشته را پاک می‌کند ( cf. cdecl ).
قرارداد فراخوانی thiscall فقط می‌تواند در Microsoft Visual C ++ 2005 به صراحت مشخص شود. در هر کامپایلر دیگر "thiscall" یک کلمه کلیدی نیست. (با این حال، disassembler‌ها، مانند IDA، باید آن را مشخص کنند؛ بنابراین IDA از کلید واژه "thiscall__" برای this استفاده می‌کند)
بخشی دیگر از یک قرارداد فراخوانی این است که کدام یک از ثبّاتها تضمین می‌کنند که بعد از فراخوانی فرعی، مقادیر خود را حفظ کنند.
با توجه به اینتل ABI که اکثریت کامپایلرها با آن مطابقت دارد، EAX, EDX و ECX برای استفاده در یک فرایند یا تابع آزاد هستند و لازم نیست که حفظ شوند
همان‌طور که از نامش بر می‌آید، این ثبّاتهای همه منظوره معمولاً اطلاعات موقت (بی‌ثبات) را نگه می‌دارد که می‌تواند توسط هر تابع رونویسی شود.
بنابراین، این مسئولیت تماس گیرنده است که هر یک از این ثبّاتها را بر روی پشته قرار دهد، اگر مایل به بازگرداندن مقادیر خود پس از فراخوانی فرعی باشد.
دیگر ثبّات‌ها برای نگهداری مقادیر طولانی مدت (غیرقابل تغییر) استفاده می‌شود که باید در فراخوانی‌ها حفظ شود.
به عبارت دیگر، هنگامی که فراخوانی‌کننده روند فراخوانی را اجرا می‌کند، می‌تواند انتظار داشته باشد که آن ثبّاتها پس از بازگشت از فراخوانی شده، همان مقدار را نگه داشته‌اند.
بنابراین، فراخوانی شده مسئول هر دو کارِ ذخیره (قراردادن در پشته در ابتدا) و بازیابی (برداشتن از پشته به ترتیب) آنها، قبل از بازگشت به تماس گیرنده، می‌شود. همان‌طور که در مورد قبلی، این تمرین فقط باید در ثبّاتی انجام شود که فراخوانی شده آن را تغییر می‌دهد.
قراردادهای فراخوانی x86-64 از فضای اضافی ثبّات برای انتقال آرگومان‌های بیشتر در ثبّات‌ها بهره می‌برد. همچنین تعداد قرادادهای فراخوانی ناسازگار کاهش یافته‌است. دو مورد استفادهٔ رایج وجود دارد.
قرادادهای فراخوانی مایکروسافت x64 در Windows و pre-boot UEFI (برای حالت طولانی در x86-64) دنبال می‌شود. این با استفاده از رشته‌های RCX, RDX, R8، R9 برای چهار آرگومان عدد صحیح یا اشاره گر اول (به همان ترتیب) است و XMM0، XMM1، XMM2، XMM3 برای آرگومان‌های اعشاری استفاده می‌شود. آرگومان‌های اضافی به پشته (از چپ به راست) اضافه می‌شوند. مقادیر بازگشتی از نوع عدد صحیح (شبیه به x86) در RAX اگر ۶۴ بیت یا کمتر برگرداننده می‌شوند. مقادیر بازگشتی اعشاری در XMM0 بازگردانده می‌شوند. پارامترهایی که کمتر از ۶۴ بیت طول دارند، با صفر بسط داده نشده‌اند؛ بیت‌های بالا صفر نیستند.
هنگام کامپایل کردن معماری x64 در یک زمینه ویندوز (چه با استفاده از ابزارهای مایکروسافت یا غیر مایکروسافت)، فقط یک قراداد فراخوانی وجود دارد - همان‌طور که در اینجا توضیح داده شده‌است، به طوری که stdcall, thiscall, cdecl, fastcall و … در حال حاضر همه یکی و یکسان هستند.
در قراداد فراخوانی مایکروسافت x64، مسئولیت تماس گیرنده است که دقیقاً قبل از فراخوانی تابع (صرف نظر از تعداد واقعی پارامترهای مورد استفاده) ۳۲ بایت از فضای سایه(shadow space) را در پشته اختصاص داده و از پشته را بعد از فراخوانی بردارد. فضای سایه برای ریختن RCX, RDX, R8، و R9، استفاده می‌شود اما باید تمام توابع، حتی آن‌هایی که با کمتر از چهار پارامتر هستند، را در دسترس بسازد.
ثبّاتهای RAX, RCX, RDX, R8، R9، R10، R11 فرار هستند (ذخیره شده توسط فراخوانی کننده).
ثبّاتهای RBX, RBP, RDI, RSI, RSP, R12، R13، R14 و R15 به عنوان غیر فرار (ذخیره شده توسط فراخوانی شده) محسوب می‌شوند.
به عنوان مثال، یک تابع که ۵ آرگومان عدد صحیح می‌گیرد، اولین تا چهارم را در ثبّاتها می‌گیرد، و پنجم در بالای فضای سایه قرار می‌دهد؛ بنابراین هنگامی که تابع فراخوانی شده وارد می‌شود، پشته از (به ترتیب صعودی) آدرس برگشتی، و سپس فضای سایه (۳۲ بایت) و پارامتر پنجم تشکیل می‌شود.
در x86-64 ویژوال استودیو ۲۰۰۸ اعداد اعشاری را در XMM6 و XMM7 (و همچنین XMM8 از طریق XMM15) ذخیره می‌کند. به این ترتیب، برای x86-64، تابع زبان اسمبلیِ نوشته شده توسط کاربر باید XMM6 و XMM7 را حفظ کند (در مقایسه با x86 که در آن نیازی نیست تابع زبان اسمبلیِ نوشته شده توسط کاربر XMM6 و XMM7 را حفظ کند). به عبارت دیگر، تابع زبان اسمبلیِ نوشته شده توسط کاربر باید برای ذخیره / بازگرداندن XMM6 و XMM7 قبل / بعد از تابع در هنگام حمل از x86 به x86-64 به روز شود.
مایکروسافت با شروع از ویژوال استودیو ۲۰۱۳، قرارداد فراخوانی vectorcall__ را معرفی کرد که قرارداد x64 را گسترش می‌دهد.
قرارداد فراخوانی System V AMD64 ABI در Solaris، Linux، FreeBSD، macOS دنبال می‌شود و عملاً استانداردی در میان سیستم عامل‌های شبه یونیکس و یونیکس است. اولین شش آرگومان عدد صحیح یا اشاره گر در RDI, RSI, RDX, RCX, R8، R9 ثبت می‌شوند (R10 به عنوان یک نشانگر زنجیره ای استاتیک در مورد توابع توزیع شده )، در حالی که XMM0، XMM1، XMM2، XMM3، XMM4، XMM5، XMM6 و XMM7 برای برخی از آرگومان‌های اعشاری استفاده می‌شود. همان‌طور که در قرارداد فراخوانی مایکروسافت x64، آرگومان‌های اضافی به پشته منتقل می‌شوند . مقادیر بازگشتی صحیح تا ۶۴ بیت در اندازه در RAX ذخیره می‌شوند در حالی که مقادیری تا ۱۲۸ بیت در RAX و RDX ذخیره می‌شوند. مقادیر بازگشتی اعشاری به‌طور مشابه در XMM0 و XMM1 ذخیره می‌شود. .
اگر فراخوانی شده مایل به استفاده از ثبّاتهای RBX, RBP، و R12-R15 باشد، باید قبل از بازگشت کنترل به دست تماس گیرنده، مقادیر اصلی خود را بازگردانی کند. در صورت تمایل فراخوانی‌کننده به حفظ مقادیر خود، تمام ثبّاتهای دیگر باید توسط تماس گیرنده ذخیره شوند.
برای توابع گره برگ (توابع که هیچ تابع دیگری را فراخوانی نمی‌کند)، یک فضای ۱۲۸ بایت فقط در زیر اشاره گر پشته تابع ذخیره می‌شود. فضا به نام منطقه قرمز نامیده می‌شود. این منطقه توسط هر سیگنال یا مدیریت کنندگان وقفه (interrupt handlers) خراب نخواهد شد. کامپایلرها می‌توانند از این منطقه برای ذخیره متغیرهای محلی استفاده کنند. کامپایلرها ممکن است برخی از دستورالعمل‌ها را در شروع عملیات (تنظیم RSP, RBP) با استفاده از این منطقه حذف کنند. با این حال، سایر توابع می‌توانند این منطقه را خراب کنند؛ بنابراین، این منطقه فقط باید برای توابع گره برگ استفاده شود. codice_1 و codice_2 پرچمِ codice_3 را برای غیرفعال کردن بهینه‌سازی قرمز منطقه ارائه دادند.
اگر فراخوانی شده یک تابع varadic باشد، سپس تعداد آرگومان‌های اعشاری که به تابع در ثبّاتهای برداری منتقل می‌شود، باید توسط فراخوانی‌کننده در ثبّات AL ارائه شود.
بر خلاف قرارداد فراخوانی مایکروسافت، فضای سایه ارائه نشد؛ در ورودی تابع، آدرس بازگشتی مجاورِ عدد صحیح هفتم در پشته است.
این لیستی از قراردادهای فراخوانی x86 است. این قراردادها عمدتاً برای کامپایلرهای C / C ++ (به ویژه بخش ۶۴ بیتی در زیر) تعریف شده‌اند و در نتیجه موارد بسیار خاصی در نظر گرفته شده‌است. زبان‌های دیگر ممکن است از فرمت‌ها و قراردادهای دیگر در پیاده‌سازی خود استفاده کنند.
Milind Girkar, Hongjiu Lu, David Kreitzer, Vyacheslav Zakharin, eds. (2013-07-17). "System V Application Binary Interface: AMD64 Architecture Processor Supplement (With LP64 and ILP32 Programming Models)" (PDF). 1.0.CS1 maint: Uses editors parameter ()