payamvha/North_RAG huggingface dataset:
و بقیه ذخیره شده توسط فراخوانی شونده (به انگلیسی: 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; در x86، ممکن است کد اسمبلی (به روش نوشتاری اینتل) زیر تولید کند: 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
; call subroutine 'callee' add eax, 5 ; modify subroutine result ; (eax is the return value of our callee, ; so we don't have to move it into a local variable) ; compilers will usually produce the following instead, ; which is just as fast, and, unlike the add instruction, ; also works for variable length arguments ; and variable length arrays allocated on the stack. mov esp, ebp ; most calling conventions dictate ebp be callee-saved, ; i.e. it's preserved after calling the callee. ; it therefore still
after calling the callee. ; it therefore still points to the start of our stack frame. ; we do need to make sure ; callee doesn't modify (or restores) ebp, though, ; so we need to make sure ; it uses a calling convention which does this pop ebp ; restore old call frame ret ; return فراخوانی‌کننده پس از اتمام فراخوانی کردن تابع، پشته را پاک می‌کند. برخی تغییرات در بیان cdecl, به ویژه در نحوه بازگشت مقادیر وجود دارد. در نتیجه، برنامه‌های کامپایل شده توسط x86 با سیستم عامل‌های مختلف یا کامپایلرهای مختلف
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 با استفاده از این روش تضمین
call funct add esp, 8 با استفاده از این روش تضمین می‌شود که این در پشته به فرم صحیح قرار داده شده‌است. قراردادهای فراخوانی cdecl معمولاً قرارداد فراخوانی پیش فرض برای کامپایلر‌های x86 C است، اگر چه بسیاری از کامپایلرها مجهز به گزینه‌هایی برای تغییر خودکار قراردادهای فراخوانیِ استفاده شده هستند. برای تعریف کردن دستی تابع به عنوان cdecl، برخی نحو زیر را پشتیبانی می‌کند: return_type _cdecl func_name(); اصلاح‌کننده cdecl_ باید در نمونه اولیه تابع (به انگلیسی: function prototype) و در تعریف تابع گنجانده شود تا
prototype) و در تعریف تابع گنجانده شود تا هر تنظیمات دیگری را که ممکن است در جای خود باشد را لغو کند. قرارداد syscall. این مشابه cdecl است در آن آرگومان‌ها از راست به چپ در استک قرارداده می‌شوند. ECX, EAX و EDX ذخیره نمی‌شوند. اندازه لیست پارامترها در doublewords به AL منتقل می‌شود. Syscall قرارداد فراخوانی استاندارد برای OS / 2 API سی و دو بیت (۳۲ بیت) است. قرارداد optlink. آرگومان‌ها از راست به چپ در پشته قرارداده می‌شوند. سه آرگومان اول (چپ‌ترین) در EAX, EDX و ECX منتقل می‌شود و بیشتر از چهار آرگومان
EDX و ECX منتقل می‌شود و بیشتر از چهار آرگومان اعشاری در ST0 از طریق ST3 منتقل می‌شود، اگرچه فضای آن‌ها در لیست آرگومان‌ها بر پشته رزرو می‌شود. نتایج در EAX یا ST0 برگردانده می‌شوند. ثبّات‌های EBP, EBX, ESI، و EDI حفظ می‌شوند. Optlink توسط کامپایلر IBM VisualAge استفاده می‌شود. پاک کردن توسط فراخوانی شده. در این قراردادها، تابع فراخوانی شده، آرگومان‌ها را از پشته پاک می‌کند. تشخیص توابعی ک این قراردادها را استفاده می‌کنند در کد ASM آسان است زیرا آن‌ها پس از بازگشت، پشته را باز می‌کنند. دستور x86 ret به
از بازگشت، پشته را باز می‌کنند. دستور x86 ret به پارامتر ۱۶ بیتی اختیاری اجازه می‌دهد که بعد از بازگشت به فراخوانی کننده، تعداد بایت‌های مشخصی از پشته را آزاد کند. نمونه ای از این کد به صورت زیر است: ret 12 قراردادهایی به نام fastcall یا ثبّات استاندارد نشده‌اند و پیاده‌سازی آن بسته به نوع فروشنده کامپایلر متفاوت است. به‌طور معمول قراردادهای مبتنی بر ثبّات، یک یا چند آرگومان را به ثبّات‌هایی که تعداد دسترسی‌های حافظه مورد نیاز برای فراخوانی را کاهش می‌دهد و به این ترتیب آن‌ها را سریع تر می‌کند، ارسال
و به این ترتیب آن‌ها را سریع تر می‌کند، ارسال می‌کنند پاسکال. بر اساس قرارداد فراخوانی زبان برنامه‌نویسی Borland Pascal، پارامترها بر روی پشته از چپ به راست (مخالف cdecl) قرار می‌گیرند و فراخوانی شده مسئول حذف آن‌ها از پشته است. بازگشت نتیجه به شرح زیر است: این قرارداد فراخوانی در APIهای ۱۶ بیتی زیر رایج بود: OS / 2 1.x، مایکروسافت ویندوز 3.x و Borland Delphi نسخه 1.x. نسخه‌های مدرن ویندوز API از stdcall استفاده می‌کنند، که هنوز هم فراخوانی شده پشته را طبق قرارداد پاسکال را ذخیره می‌کند، اما اکنون
را طبق قرارداد پاسکال را ذخیره می‌کند، اما اکنون پارامترها از راست به چپ قرارداده می‌شوند. قرارداد stdcall. قرارداد فراخوانی stdcall تغییری در قرارداد فراخوانی پاسکال است که در آن فراخوانی شده مسئول پاک کردن پشته است، اما پارامترها در پشته به ترتیب از راست به سمت چپ، همان‌طور که در قرارداد فراخوانی _cdecl قرار دارد، قرار می‌گیرند. ثبّات‌های EAX, ECX و EDX برای استفاده درون تابع تعیین می‌شوند. مقادیر بازگشتی در ثبّات EAX ذخیره می‌شوند. stdcall استاندارد برای مایکروسافت Win32 API و Open Watcom CPP است.
برای مایکروسافت Win32 API و Open Watcom CPP است. قرارداد فراخوانیِ سریع مایکروسافت fastcall. قرارداد مایکروسافت 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 مربوط
و غیره) باشند، از طریق ثبّاتهای XMM / YMM مربوط منتقل می‌شوند. به‌طور مشابه برای IA-32، حداکثر تا ۶ ثبّاتها XMM / YMM به صورت تکراری برای آرگومان‌ها از نوع بردار از چپ به راست بدون در نظر گرفتن موقعیت قرار می‌گیرد. علاوه بر این، vectorcall__ پشتیبانی کردن از انتقال مجموعه ای از مقادیر همگن بردار (HVA) را اضافه کرد، که از نوع ترکیبی است که شامل بیش از چهار نوع بردار یکسان است، با استفاده از شش ثبّات یکسان. هنگامی که ثبّاتها برای آرگومان‌های برداری اختصاص داده می‌شوند، ثبّاتهای استفاده نشده به آرگومان‌های
می‌شوند، ثبّاتهای استفاده نشده به آرگومان‌های HVA از چپ به راست بدون توجه به موقعیت اختصاص داده می‌شوند. نتیجه نوع برداری و مقادیر HVA با استفاده از چهار ثبّات اول XMM / YMM بازگرداننده می‌شود. قرارداد ثبّاتهای Borland. ارزیابی آرگومان‌ها از چپ به راست، سه آرگومان را از طریق EAX, EDX, ECX منتقل می‌کند. آرگومان‌های باقی مانده در پشته از چپ به راست قرارداده می‌شوند. این قرارداد فراخوانیِ پیش فرضِ کامپایلر ۳۲ بیتی دلفی است، جایی که به عنوان ثبّات شناخته می‌شود. GCC این قرارداد فراخوانی را با گزینه "regparm =
GCC این قرارداد فراخوانی را با گزینه "regparm = ۳ پشتیبانی می" کند. این به وسیلهٔ هسته لینوکس روی i386 از نسخه ۲٫۶٫۲۰ (منتشر شده در فوریه ۲۰۰۷) استفاده می‌شود. این قرارداد فراخوانی نیز توسط C ++ Builder Embarcadero استفاده می‌شود، جایی که "fastcall__" نامیده می‌شود. در این کامپایلر، "fastcall" مایکروسافت را می‌توان به عنوان "msfastcall__ استفاده کرد". قرارداد ثبّاتهای Watcom. Watcom از کلمه کلیدی "fastcall__" پشتیبانی نمی‌کند مگر این که نام مستعار آن را null کند. قرارداد فراخوانی ثبّات ممکن است توسط سوئیچ
کند. قرارداد فراخوانی ثبّات ممکن است توسط سوئیچ خط فرمان انتخاب شود. (با این حال، IDA از "fastcall__" برای یکنواخت کردن استفاده می‌کند) تا ۴ ثبّات به ترتیب به آرگومان‌های eax, edx, ebx, ecx اختصاص داده می‌شوند. آرگومان‌ها از چپ به راست به ثبّاتها اختصاص داده می‌شوند. اگر هر آرگومان نتواند به یک ثبّات تخصیص داده شود (می‌گویند خیلی بزرگ است)، آن و تمام آرگومان‌های بعدی به پشته اختصاص داده می‌شوند. آرگومان‌هایی که به پشته اختصاص داده می‌شوند از راست به چپ قرار می‌گیرد. نام‌ها با اضافه کردن پسوند _ تغییر
قرار می‌گیرد. نام‌ها با اضافه کردن پسوند _ تغییر می‌کنند. توابع متغیر بر اساس قرارداد فراخوانی به پشتهٔ Watcom سقوط می‌کنند. کامپایلر Watcom C / C ++ نیز از دستور pragma aux# که به کاربر اجازه می‌دهد که خودشان قرارداد فراخوانی خود را مشخص کنند. همان‌طور که در کتابچه راهنمای آن آمده‌است: «تعداد کمی از کاربران احتمالاً به این روش نیاز دارند، اما اگر لازم باشد، می‌تواند یک نجات دهنده باشد». قرارداد TopSpeed / Clarion / JPI. اولین چهار پارامتر عدد صحیح در ثبّاتهای، ebx, ecx و edx منتقل می‌شوند. پارامترهای
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 در دلفی با
نه یک پارامتر. هنگام ایجاد اشیاء COM در دلفی با استفاده از safecall، نیازی به نگرانی در مورد HResults وجود ندارد، زیرا استثنائات می‌توانند به عنوان نرمال مطرح شوند اما به عنوان HResults در سایر زبان‌ها دیده می‌شود. function function_name(a: DWORD): DWORD; safecall; یک نتیجه را برمی‌گرداند و استثناها را مانند یک تابع معمولی دلفی مطرح می‌کند، اما مقادیر و استثنائات را همان‌طور که بود می‌دهد: function function_name(a: DWORD; out Result: DWORD): HResult; stdcall; پاک شدن توسط فراخوانی کننده یا فراخوانی شونده.
پاک شدن توسط فراخوانی کننده یا فراخوانی شونده. قرارداد thiscall. این قرارداد فراخوانی برای فراخوانی توابع عضو غیر استاتیک C ++ استفاده می‌شود. دو نسخه اصلی از thiscall بسته به نوع کامپایلر استفاده می‌شود و اینکه آیا این تابع از یک متغیر عددی از آرگومان‌ها، استفاده می‌کند یا خیر. برای کامپایلر GCC، قرارداد thiscall تقریباً با cdecl یکسان است :تماس گیرنده پشته را پاک می‌کند، و پارامترها با ترتیب راست به چپ منتقل می‌شوند. تفاوت در اضافه کردن اشاره گر this است که آخرین چیزی است که به پشته منتقل می‌شود، به شرط
که آخرین چیزی است که به پشته منتقل می‌شود، به شرط اینکه اولین پارامتر در نمونه اولیه تابع(function prototype) باشد. در کامپایلر مایکروسافت ویژوال سی + +، اشاره گر this در ECX منتقل می‌شود و آن "فراخوانی شونده است" که "پشته را" پاک می‌کند، که منعکس کردن قرارداد stdcall مورد استفاده در C برای این کامپایلر و در توابع API ویندوز است. وقتی توابع از یک متغیر عددی از آرگومان‌ها استفاده می‌کنند، فراخوانی‌کننده است که پشته را پاک می‌کند ( cf. cdecl ). قرارداد فراخوانی thiscall فقط می‌تواند در Microsoft Visual C ++
thiscall فقط می‌تواند در Microsoft Visual C ++ 2005 به صراحت مشخص شود. در هر کامپایلر دیگر "thiscall" یک کلمه کلیدی نیست. (با این حال، disassembler‌ها، مانند IDA، باید آن را مشخص کنند؛ بنابراین IDA از کلید واژه "thiscall__" برای this استفاده می‌کند) حفظ ثبّات. بخشی دیگر از یک قرارداد فراخوانی این است که کدام یک از ثبّاتها تضمین می‌کنند که بعد از فراخوانی فرعی، مقادیر خود را حفظ کنند. ثبّاتهای ذخیره شده توسط فراخوانی کننده (فرار). با توجه به اینتل ABI که اکثریت کامپایلرها با آن مطابقت دارد، EAX, EDX و ECX
کامپایلرها با آن مطابقت دارد، EAX, EDX و ECX برای استفاده در یک فرایند یا تابع آزاد هستند و لازم نیست که حفظ شوند همان‌طور که از نامش بر می‌آید، این ثبّاتهای همه منظوره معمولاً اطلاعات موقت (بی‌ثبات) را نگه می‌دارد که می‌تواند توسط هر تابع رونویسی شود. بنابراین، این مسئولیت تماس گیرنده است که هر یک از این ثبّاتها را بر روی پشته قرار دهد، اگر مایل به بازگرداندن مقادیر خود پس از فراخوانی فرعی باشد. ثبّات‌های ذخیره شده توسط فراخوانی شده (غیرقابل تغییر). دیگر ثبّات‌ها برای نگهداری مقادیر طولانی مدت (غیرقابل
ثبّات‌ها برای نگهداری مقادیر طولانی مدت (غیرقابل تغییر) استفاده می‌شود که باید در فراخوانی‌ها حفظ شود. به عبارت دیگر، هنگامی که فراخوانی‌کننده روند فراخوانی را اجرا می‌کند، می‌تواند انتظار داشته باشد که آن ثبّاتها پس از بازگشت از فراخوانی شده، همان مقدار را نگه داشته‌اند. بنابراین، فراخوانی شده مسئول هر دو کارِ ذخیره (قراردادن در پشته در ابتدا) و بازیابی (برداشتن از پشته به ترتیب) آنها، قبل از بازگشت به تماس گیرنده، می‌شود. همان‌طور که در مورد قبلی، این تمرین فقط باید در ثبّاتی انجام شود که فراخوانی شده آن
فقط باید در ثبّاتی انجام شود که فراخوانی شده آن را تغییر می‌دهد. قراردادهای فراخوانی x86-64. قراردادهای فراخوانی x86-64 از فضای اضافی ثبّات برای انتقال آرگومان‌های بیشتر در ثبّات‌ها بهره می‌برد. همچنین تعداد قرادادهای فراخوانی ناسازگار کاهش یافته‌است. دو مورد استفادهٔ رایج وجود دارد. قرادادهای فراخوانی مایکروسافت x64. قرادادهای فراخوانی مایکروسافت x64 در Windows و pre-boot UEFI (برای حالت طولانی در x86-64) دنبال می‌شود. این با استفاده از رشته‌های RCX, RDX, R8، R9 برای چهار آرگومان عدد صحیح یا اشاره گر اول
R8، R9 برای چهار آرگومان عدد صحیح یا اشاره گر اول (به همان ترتیب) است و XMM0، XMM1، XMM2، XMM3 برای آرگومان‌های اعشاری استفاده می‌شود. آرگومان‌های اضافی به پشته (از چپ به راست) اضافه می‌شوند. مقادیر بازگشتی از نوع عدد صحیح (شبیه به x86) در RAX اگر ۶۴ بیت یا کمتر برگرداننده می‌شوند. مقادیر بازگشتی اعشاری در XMM0 بازگردانده می‌شوند. پارامترهایی که کمتر از ۶۴ بیت طول دارند، با صفر بسط داده نشده‌اند؛ بیت‌های بالا صفر نیستند. هنگام کامپایل کردن معماری x64 در یک زمینه ویندوز (چه با استفاده از ابزارهای مایکروسافت
ویندوز (چه با استفاده از ابزارهای مایکروسافت یا غیر مایکروسافت)، فقط یک قراداد فراخوانی وجود دارد - همان‌طور که در اینجا توضیح داده شده‌است، به طوری که stdcall, thiscall, cdecl, fastcall و … در حال حاضر همه یکی و یکسان هستند. در قراداد فراخوانی مایکروسافت x64، مسئولیت تماس گیرنده است که دقیقاً قبل از فراخوانی تابع (صرف نظر از تعداد واقعی پارامترهای مورد استفاده) ۳۲ بایت از فضای سایه(shadow space) را در پشته اختصاص داده و از پشته را بعد از فراخوانی بردارد. فضای سایه برای ریختن RCX, RDX, R8، و R9، استفاده
فضای سایه برای ریختن RCX, RDX, R8، و R9، استفاده می‌شود اما باید تمام توابع، حتی آن‌هایی که با کمتر از چهار پارامتر هستند، را در دسترس بسازد. ثبّاتهای RAX, RCX, RDX, R8، R9، R10، R11 فرار هستند (ذخیره شده توسط فراخوانی کننده).&lt;ref name="Caller/Callee Saved Registers"&gt;&lt;/ref&gt; ثبّاتهای RBX, RBP, RDI, RSI, RSP, R12، R13، R14 و R15 به عنوان غیر فرار (ذخیره شده توسط فراخوانی شده) محسوب می‌شوند. به عنوان مثال، یک تابع که ۵ آرگومان عدد صحیح می‌گیرد، اولین تا چهارم را در ثبّاتها می‌گیرد، و پنجم در بالای
تا چهارم را در ثبّاتها می‌گیرد، و پنجم در بالای فضای سایه قرار می‌دهد؛ بنابراین هنگامی که تابع فراخوانی شده وارد می‌شود، پشته از (به ترتیب صعودی) آدرس برگشتی، و سپس فضای سایه (۳۲ بایت) و پارامتر پنجم تشکیل می‌شود. در x86-64 ویژوال استودیو ۲۰۰۸ اعداد اعشاری را در XMM6 و XMM7 (و همچنین XMM8 از طریق XMM15) ذخیره می‌کند. به این ترتیب، برای x86-64، تابع زبان اسمبلیِ نوشته شده توسط کاربر باید XMM6 و XMM7 را حفظ کند (در مقایسه با x86 که در آن نیازی نیست تابع زبان اسمبلیِ نوشته شده توسط کاربر XMM6 و XMM7 را حفظ
اسمبلیِ نوشته شده توسط کاربر XMM6 و XMM7 را حفظ کند). به عبارت دیگر، تابع زبان اسمبلیِ نوشته شده توسط کاربر باید برای ذخیره / بازگرداندن XMM6 و XMM7 قبل / بعد از تابع در هنگام حمل از x86 به x86-64 به روز شود. مایکروسافت با شروع از ویژوال استودیو ۲۰۱۳، قرارداد فراخوانی vectorcall__ را معرفی کرد که قرارداد x64 را گسترش می‌دهد. سیستم V AMD64 ABI. قرارداد فراخوانی 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 ذخیره می‌شوند. مقادیر
تا ۱۲۸ بیت در RAX و RDX ذخیره می‌شوند. مقادیر بازگشتی اعشاری به‌طور مشابه در XMM0 و XMM1 ذخیره می‌شود. . اگر فراخوانی شده مایل به استفاده از ثبّاتهای RBX, RBP، و R12-R15 باشد، باید قبل از بازگشت کنترل به دست تماس گیرنده، مقادیر اصلی خود را بازگردانی کند. در صورت تمایل فراخوانی‌کننده به حفظ مقادیر خود، تمام ثبّاتهای دیگر باید توسط تماس گیرنده ذخیره شوند. برای توابع گره برگ (توابع که هیچ تابع دیگری را فراخوانی نمی‌کند)، یک فضای ۱۲۸ بایت فقط در زیر اشاره گر پشته تابع ذخیره می‌شود. فضا به نام منطقه قرمز نامیده
تابع ذخیره می‌شود. فضا به نام منطقه قرمز نامیده می‌شود. این منطقه توسط هر سیگنال یا مدیریت کنندگان وقفه (interrupt handlers) خراب نخواهد شد. کامپایلرها می‌توانند از این منطقه برای ذخیره متغیرهای محلی استفاده کنند. کامپایلرها ممکن است برخی از دستورالعمل‌ها را در شروع عملیات (تنظیم RSP, RBP) با استفاده از این منطقه حذف کنند. با این حال، سایر توابع می‌توانند این منطقه را خراب کنند؛ بنابراین، این منطقه فقط باید برای توابع گره برگ استفاده شود. codice_1 و codice_2 پرچمِ codice_3 را برای غیرفعال کردن بهینه‌سازی
پرچمِ codice_3 را برای غیرفعال کردن بهینه‌سازی قرمز منطقه ارائه دادند. اگر فراخوانی شده یک تابع varadic باشد، سپس تعداد آرگومان‌های اعشاری که به تابع در ثبّاتهای برداری منتقل می‌شود، باید توسط فراخوانی‌کننده در ثبّات AL ارائه شود. برخلاف قرارداد فراخوانی مایکروسافت، فضای سایه ارائه نشد؛ در ورودی تابع، آدرس بازگشتی مجاورِ عدد صحیح هفتم در پشته است. فهرست قراردادهای فراخوانی معماری x86. این لیستی از قراردادهای فراخوانی x86 است. این قراردادها عمدتاً برای کامپایلرهای C / C ++ (به ویژه بخش ۶۴ بیتی در زیر) تعریف
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 ()&lt;templatestyles
Uses editors parameter ()&lt;templatestyles src="Module:Citation/CS1/en/styles.css"&gt;&lt;/templatestyles&gt;&lt;/ref&gt;
کامپایلر گنو برای جاوا (به انگلیسی: GNU) (GCJ) یک کامپایلر رایگان برای زبان برنامه‌نویسی جاوا است. برای بیش از ده سال بخشی از مجموعه کامپایلر گنو بود اما از سال ۲۰۱۷ دیگر حفظ نخواهد شد و بخشی از انتشارات آینده نخواهد بود. GCJ کد منبع جاوا را به بایت کد ماشین مجازی جاوا یا به کد ماشین برای تعدادی از معماری‌های پردازنده کامپایل می‌کند. همچنین می‌تواند فایل‌های کلاس و JARهای کامل را که حاوی بایت کد هستند به کد ماشین کامپایل کند. تاریخچه. منبع اصلی کتابخانه‌های زمان اجرای GCJ از پروژه GNU Classpath است، اما بین
اجرای GCJ از پروژه GNU Classpath است، اما بین کتابخانه‌های codice_1 تفاوت کدی وجود دارد. GCJ 4.3 از کامپایلر Eclipse برای جاوا به عنوان یک جلو-عقب (به انگلیسی: back-end) استفاده می‌کند. در سال ۲۰۰۷، برای پیاده‌سازی پشتیبانی برای دو API گرافیکی در جاوا Classpath GNU: AWT و Swing، کارهای زیادی انجام شد. پشتیبانی نرم‌افزاری برای AWT هنوز در حال توسعه است. "زمانی که پشتیبانی از AWT کار بکند، پشتیبانی از Swing می‌تواند مورد توجه قرار گیرد. حداقل یک پیاده سازی نرم افزاری جزئی رایگان از Swing وجود دارد که ممکن
نرم افزاری جزئی رایگان از Swing وجود دارد که ممکن است قابل استفاده باشد. ". GNU CLASSPATH حتی به وضعیت جاوا ۱٫۲ هم تکمیل نشد و اکنون به نظر می‌رسد به‌طور کامل رها شده است. از سال ۲۰۱۵، هیچ پیشرفت جدیدی از GCJ اعلام نشده و محصول در حالت نگهداری بود. GCJ در تاریخ ۳۰ سپتامبر ۲۰۱۶ از تنه GCC حذف شد. اطلاعیه حذف آن همزمان با انتشار GCC 7.1، که شامل آن نیست، داده شد. GCJ به عنوان بخشی از GCC 6 باقی مانده است. کارایی. تابع کامپایل در GCJ هنگام کامپایل کد جاوا به کد ماشین باید زمان شروع سریعتری نسبت به بایت کد
کد ماشین باید زمان شروع سریعتری نسبت به بایت کد معادل اجرا شده در JVM داشته باشد رابط بومی کامپایل شده (CNI). رابط بومی کامپایل شده (به انگلیسی: Compiled Native Interface) ، که قبلا "رابط بومی سیگنوس (به انگلیسی: Cygnus Native Interface)" نام گذاری شده بود، یک فریم ورک نرم‌افزاری (به انگلیسی: ) برای GCJ است که اجازه می‌دهد تا کد جاوا برنامه‌های بومی و کتابخامه‌های زبان ++C را فراخوانی کند یا توسط آنها فراخوانده شود. برای پاسخ، می‌شود و به نام‌های، برنامه‌های بومی (برنامه‌های خاص به یک پلت فرم سخت‌افزار و
بومی (برنامه‌های خاص به یک پلت فرم سخت‌افزار و سیستم عامل) و کتابخانه‌ها در C ++ نوشته شده است. CNI بسیار شبیه فریم ورک JNI (رابط بومی جاوا) است که به عنوان یک استاندارد با ماشین‌های مجازی جاوا می‌آید. مقایسه استفاده از زبان. نویسندگان CNI مدعی مزایای زیادی نسبت به JNI هستند: CNI به کلاسهای Java بستگی دارد که به عنوان کلاس‌های C ++ ظاهر می‌شوند. به عنوان مثال، با توجه به کلاس جاوا زیر، public class Int public int i; public static Int zero = new Int(0); می‌توان از کلاس استفاده کرد: Int *mult(Int *p, int k)
از کلاس استفاده کرد: Int *mult(Int *p, int k) if (k == 0) return Int::zero; // Static member access. return new Int(p-&gt;i * k);
کپسول آندوسکوپی یک روش برای ضبط تصاویر داخلی دستگاه گوارش به منظور مقاصد تشخیصی در حوزه پزشکی است. کپسول (مانند یک قرص رادیویی) مشابه با یک کپسول دارویی استاندارد است، اگر چه کمی بزرگ‌تر است و دارای یک دوربین کوچک و مجموعه ای از ال‌ئی‌دیهایی است که توسط یک باتری تغذیه شده‌اند. پس از آنکه بیمار کپسول را فرو ببرد، این کپسول از مسیر دستگاه گوارش عبور می‌کند و در هر ثانیه تعدادی عکس برداری انجام می‌دهد سپس تصاویر به صورت بی‌سیم به یک آرایه گیرنده متصل به یک دستگاه پرتابل ضبط کننده که توسط بیمار قابل حمل است
پرتابل ضبط کننده که توسط بیمار قابل حمل است منتقل می‌شود. استفاده عمده از کپسول آندوسکوپی به معاینه و مشاهده مناطق روده کوچک مربوط می‌شود. نکته مهم این است که این نواحی توسط انواع دیگر آندوسکوپی مانند کولونوسکوپی یا ازوفاگوگاسترودئودنوسکوپی (EGD)دیده نمی‌شود. استفاده‌های پزشکی. اوسوفاژوگاسترودوداندوسکوپی ( Esophagogastroduodenoscopy یا EGِD)، یک دوربین متصل به یک لوله انعطاف‌پذیر طولانی است که برای مشاهده قسمت فوقانی دستگاه گوارش، یعنی مری، معده و آغاز قسمت ابتدایی روده کوچک به نام دوازدهه به کار می‌رود.
ابتدایی روده کوچک به نام دوازدهه به کار می‌رود. همچنین به وسیله یک کولونوسکوپ وارد شده از طریق رکتوم (مقعد) می‌توان کولون (روده بزرگ) و قسمت دیستال روده کوچک و همچنین ترمینال ایلئوم را مشاهده کرد. با این حال این دو نوع آندوسکوپی نمی‌تواند اکثر بخش‌های میانی روده کوچک را نمایان سازد. کپسول آندوسکوپی همچنین برای بررسی قسمت‌هایی از دستگاه گوارش مورد استفاده قرار می‌گیرد که نمی‌تواند با سایر انواع آندوسکوپی دیده شود. این روش تصویربرداری وقتی که بیمار در روده کوچک خود مشکوک به بیماری است مفید واقع می‌شود و