Payamvdn/NorthPersian_fa_wiki huggingface dataset:
ند. ثبّات های EAX, ECX و EDX برای استفاده درون تابع تعیین می شوند. مقادیر بازگشتی در ثبّات EAX ذخیره می شوند. stdcall استاندارد برای مایکروسافت 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 مربوط منتقل می شوند. به طور مشابه برای IA-32، حداکثر تا ۶ ثبّاتها XMM / YMM به صورت تکراری برای آرگومان ها از نوع بردار از چپ به راست بدون در نظر گرفتن موقعیت قرار می گیرد. علاوه بر این، vectorcall__ پشتیبانی کردن از انتقال مجموعه ای از مقادیر همگن بردار (HVA) را اضافه کرد، که از نوع ترکیبی است که شامل بیش از چهار نوع بردار یکسان است، با استفاده از شش ثبّات یکسان. هنگامی که ثبّاتها برای آرگومان های برداری اختصاص داده می شوند، ثبّاتهای استفاده نشده به آرگومان های HVA از چپ به راست بدون توجه به موقعیت اختصاص داده می شوند. نتیجه نوع برداری و مقادیر HVA با استفاده از چهار ثبّات اول XMM / YMM بازگرداننده می شود. قرارداد ثبّاتهای Borland. ارزیابی آرگومان ها از چپ به راست، سه آرگومان را از طریق EAX, EDX, ECX منتقل می کند. آرگومان های باقی مانده در پشته از چپ به راست قرارداده می شوند. این قرارداد فراخوانیِ پیش فرضِ کامپایلر ۳۲ بیتی دلفی است، جایی که به عنوان ثبّات شناخته می شود. GCC این قرارداد فراخوانی را با گزینه "regparm = ۳ پشتیبانی می" کند.
این به وسیلهٔ هسته لینوکس روی i386 از نسخه ۲٫۶٫۲۰ (منتشر شده در فوریه ۲۰۰۷) استفاده می شود. این قرارداد فراخوانی نیز توسط C ++ Builder Embarcadero استفاده می شود، جایی که "fastcall__" نامیده می شود. در این کامپایلر، "fastcall" مایکروسافت را می توان به عنوان "msfastcall__ استفاده کرد". قرارداد ثبّاتهای Watcom. Watcom از کلمه کلیدی "fastcall__" پشتیبانی نمی کند مگر این که نام مستعار آن را null کند. قرارداد فراخوانی ثبّات ممکن است توسط سوئیچ خط فرمان انتخاب شود. (با این حال، IDA از "fastcall__" برای یکنواخت کردن استفاده می کند) تا ۴ ثبّات به ترتیب به آرگومان های eax, edx, ebx, ecx اختصاص داده می شوند. آرگومان ها از چپ به راست به ثبّاتها اختصاص داده می شوند. اگر هر آرگومان نتواند به یک ثبّات تخصیص داده شود (می گویند خیلی بزرگ است)، آن و تمام آرگومان های بعدی به پشته اختصاص داده می شوند. آرگومان هایی که به پشته اختصاص داده می شوند از راست به چپ قرار می گیرد. نام ها با اضافه کردن پسوند _ تغییر می کنند. توابع متغیر بر اساس قرارداد فراخوانی به پشتهٔ Watcom سقوط می کنند. کامپایلر Watcom C / C ++ نیز از دستور pragma a
ux# که به کاربر اجازه می دهد که خودشان قرارداد فراخوانی خود را مشخص کنند. همان طور که در کتابچه راهنمای آن آمده است: «تعداد کمی از کاربران احتمالاً به این روش نیاز دارند، اما اگر لازم باشد، می تواند یک نجات دهنده باشد». قرارداد TopSpeed / Clarion / JPI. اولین چهار پارامتر عدد صحیح در ثبّاتهای، 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; پاک شدن توسط فراخوانی کننده یا فراخوانی شونده. قرارداد thiscall. این قرارداد فراخوانی برای فراخوانی توابع عضو غیر استاتیک 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. قراردادهای فراخوانی x86-64 از فضای اضافی ثبّات برای انتقال آرگومان های بیشتر در ثبّات ها بهره می برد. همچنین تعداد قرادادهای فراخوانی ناسازگار کاهش یافته است. دو مورد استفادهٔ رایج وجود دارد. قرادادهای فراخوانی مایکروسافت x64. قرادادهای فراخوانی مایکروسافت 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 فرار هستند (ذخیره شده توسط فراخوانی کننده).&lt;ref name="Caller/Callee Saved Registers"&gt;&lt;/ref&gt; ثبّاتهای RBX, RBP, RD
I, 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 را گسترش می دهد. سیستم V AMD64 ABI. قرارداد فراخوانی System V AMD64 ABI در Solaris، Linux، FreeBS
D، 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. این لیستی از قراردادهای فراخوانی 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 ()&lt;templatestyles src="Module:Citation/CS1/en/styles.css"&gt;&lt;/templatestyles&gt;&lt;/ref&gt;
کامپایلر گنو برای جاوا (به انگلیسی: GNU) (GCJ) یک کامپایلر رایگان برای زبان برنامه نویسی جاوا است. برای بیش از ده سال بخشی از مجموعه کامپایلر گنو بود اما از سال ۲۰۱۷ دیگر حفظ نخواهد شد و بخشی از انتشارات آینده نخواهد بود. GCJ کد منبع جاوا را به بایت کد ماشین مجازی جاوا یا به کد ماشین برای تعدادی از معماری های پردازنده کامپایل می کند. همچنین می تواند فایل های کلاس و JARهای کامل را که حاوی بایت کد هستند به کد ماشین کامپایل کند. تاریخچه. منبع اصلی کتابخانه های زمان اجرای GCJ از پروژه GNU Classpath است، اما بین کتابخانه های codice_1 تفاوت کدی وجود دارد. GCJ 4.3 از کامپایلر Eclipse برای جاوا به عنوان یک جلو-عقب (به انگلیسی: back-end) استفاده می کند. در سال ۲۰۰۷، برای پیاده سازی پشتیبانی برای دو API گرافیکی در جاوا Classpath GNU: AWT و Swing، کارهای زیادی انجام شد. پشتیبانی نرم افزاری برای AWT هنوز در حال توسعه است. "زمانی که پشتیبانی از AWT کار بکند، پشتیبانی از 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) if (k == 0) return Int::zero; // Static member access. return new Int(p-&gt;i * k);
کپسول آندوسکوپی یک روش برای ضبط تصاویر داخلی دستگاه گوارش به منظور مقاصد تشخیصی در حوزه پزشکی است. کپسول (مانند یک قرص رادیویی) مشابه با یک کپسول دارویی استاندارد است، اگر چه کمی بزرگ تر است و دارای یک دوربین کوچک و مجموعه ای از ال ئی دیهایی است که توسط یک باتری تغذیه شده اند. پس از آنکه بیمار کپسول را فرو ببرد، این کپسول از مسیر دستگاه گوارش عبور می کند و در هر ثانیه تعدادی عکس برداری انجام می دهد سپس تصاویر به صورت بی سیم به یک آرایه گیرنده متصل به یک دستگاه پرتابل ضبط کننده که توسط بیمار قابل حمل است منتقل می شود. استفاده عمده از کپسول آندوسکوپی به معاینه و مشاهده مناطق روده کوچک مربوط می شود. نکته مهم این است که این نواحی توسط انواع دیگر آندوسکوپی مانند کولونوسکوپی یا ازوفاگوگاسترودئودنوسکوپی (EGD)دیده نمی شود. استفاده های پزشکی. اوسوفاژوگاسترودوداندوسکوپی ( Esophagogastroduodenoscopy یا EGِD)، یک دوربین متصل به یک لوله انعطاف پذیر طولانی است که برای مشاهده قسمت فوقانی دستگاه گوارش، یعنی مری، معده و آغاز قسمت ابتدایی روده کوچک به نام دوازدهه به کار می رود. همچنین به وسیله یک کولونوسکوپ وارد شده از طریق رک
توم (مقعد) می توان کولون (روده بزرگ) و قسمت دیستال روده کوچک و همچنین ترمینال ایلئوم را مشاهده کرد. با این حال این دو نوع آندوسکوپی نمی تواند اکثر بخش های میانی روده کوچک را نمایان سازد. کپسول آندوسکوپی همچنین برای بررسی قسمت هایی از دستگاه گوارش مورد استفاده قرار می گیرد که نمی تواند با سایر انواع آندوسکوپی دیده شود. این روش تصویربرداری وقتی که بیمار در روده کوچک خود مشکوک به بیماری است مفید واقع می شود و همچنین می تواند گاهی اوقات برای پیدا کردن محل خونریزی گوارشی یا علت درد ناگهانی شکم مانند بیماری کرون استفاده شود. با این حال، بر خلاف EGD یا کولونوسکوپی، نمی توان این روش را برای درمان آسیب شناسی (پاتولوژی) مورد استفاده قرار داد. دلایل متداول برای استفاده از کپسول آندوسکوپی عبارتند از تشخیص خونریزی غیرقابل توضیح، کمبود آهن یا درد شکمی، جستجو برای پولیپ، زخم و تومور روده کوچک و تشخیص بیماری التهابی روده. تصاویری که توسط دوربین مینیاتوری در طول یک جلسه جمع آوری می شوند، به صورت بی سیم به یک گیرنده خارجی که توسط بیمار پوشیده شده است، فرستاده می شود. این ارتباط بی سیم به واسطه هریک از باندهای مناسب فرکانسی صور
ت می گیرد. سپس تصاویر جمع آوری شده برای نمایش، بررسی و تشخیص به یک کامپیوتر منتقل می شوند. از یک سیگنال فرکانس رادیویی به منظور تعیین مکان دقیق کپسول و ردیابی آن به طور زنده و لحظه ای در داخل بدن و دستگاه گوارش استفاده می شود. هنوز مشخص نیست که آیا کپسول آندوسکوپی می تواند جایگزینی برای گاستروسکوپی در مورد افرادی که بیماری سیروز دارند، محسوب شود یا خیر. تحقیقات به طور ویژه، ارتقا و افزایش مکانیسم های ارزیابی درمانی و سیستم های مکان یابی و کنترل حرکت را هدف قرار داده است تا برنامه های کاربردی جدیدی به این تکنولوژی ملحق شود. به عنوان مثال، انتقال دارو را فعال کنند. انتقال انرژی بی سیم نیز به عنوان راهی برای ارائه یک منبع انرژی مستمر برای کپسول مورد بررسی قرار گرفته است. سازندگان. از سال ۲۰۱۵ تعدادی از تولیدکنندگان وجود دارد. این تکنولوژی در ابتدا توسط گابی ایدان(Gabi Iddan) و پل سعین(Paul Swain)، با اولین قرص در سال ۱۹۹۷ فروخته شد؛ Iddan شرکت گیون ایمجین را تأسیس کرد و توانست تصویب FDA را در سال 2001 بگیرد. اثرات جانبی. کپسول آندوسکوپی به عنوان یک روش بسیار امن برای تعیین علت نامعلوم خونریزی دستگاه گوارش در نظر
گرفته می شود. کپسول معمولاً در طی ۲۴–۴۸ ساعت با مدفوع دفع می شود. گزارش شده است که باقی ماندن کپسول در بدن تقریباً چهار و نیم سال با وجود هیچ گونه علامتی در بدن بیمار می تواند ادامه داشته باشد. با این وجود، خطر انسداد روده را می توان با اشعه ایکس بر روی نواحی شکم تشخیص داد و کپسول باقی مانده را به کمک جراحی یا آندوسکوپی (به کمک گیره ها و بازوهای تعبیه شده) از بدن شخص خارج سازند. در بررسی روی ۲۲۸۴۰ مورد، کپسول در ۱٫۴٪ مورد از موارد استفاده متأسفانه در بدن شخص باقی مانده و به طور طبیعی خارج نشد. بیماری کرون یک علت شایع در ایجاد این اشکال است؛ اکثر کپسول های باقی مانده به وسیله جراحی بیرون آورده شدند.
ثبات پرچم ها(FLAG register)، یک ثبات وضعیت در ریزپردازنده ها اینتل x86 است که شامل وضعیت فعلی پردازنده است. این ثبات از 16 بیتی است..جانشینان آن ثبات های EFLAGS و RFLAGS که به ترتیب 32 بیتی و 64 بیتی هستند. ثبات های گسترده تر قابلیت سازگاری با نسخه های پیشین خودشان را حفظ کرده اند. بیت های ثابت که در موقعیت بیتی 1، 3 و 5 و پرچم های سربار(carry)، برابری(parity)، تنظیم(adjust)، صفر(zero) و علامت(sign) از معماری پیشین 8080 و 8085 به ارث برده است. پرچم تنظیم به عنوان بیت سربار کمکی به در 8080 و بیت نیمه-سربار(half-carry) در معماری Zilog Z80 استفاده میشد. پرچم ها. توجه: ستون mask در جدول، AND bitmask است تا (به عنوان مقدار هگزادسیمال ) پرچم(ها) در مقدار ثبات پرچم ها پیدا کند. کاربرد. تمام ثبات های پرچم ها حاوی کدهای وضعیت هستند، بیت های پرچم که نتایج یک دستورالعمل زبان ماشین را تحت تاثیر دستورالعمل دیگری قرار میدهند. دستورالعمل های ریاضی و منطقی برخی یا همه پرچم ها را تنظیم می کنند و دستورالعمل های پرش شرطی بر اساس مقدار پرچم های خاصی عملیات را انجام می دهند. به عنوان مثال، codice_1 (Jump if Zero)، codice_2 (Jump
if Carry) و codice_3 (Jump if Overflow) به پرچم های خاصی بستگی دارند. سایر پرش های شرطی ترکیبی از چندین پرچم را آزمایش میکند. ثبات های پرچم ها را می توانند از پشته یا به پشته انتقال داده شوند. این بخشی از کار صرفه جویی و بازگرداندن جزئیات پردازنده است، در صورتی که یک روال مانند یک روال سرویس وقفه که تغییرات آن در ثبات ها نباید توسط کد فراخوانی دیده شود. در اینجا دستورالعمل مربوطه وجود دارد: در حالت 64 بیتی، PUSHF / POPF و PUSHFQ / POPFQ موجود هستند، اما در صورتی که PUSHFD / POPFD وجود ندارند. توانایی وارد یا خارج کردن(push and pop) ثبات های پرچم ها اجازه میدهد که یک برنامه، اطلاعات در پرچم ها را به صورتی که عملیات های زبان ماشین وجود ندارند، دستکاری کند. به عنوان مثال، دستورالعمل های codice_4 و codice_5 به ترتیب پرچم مسیر (DF) را صفر و یک می کنند. اما دستورالعملی برای برعکس کردن(complement) DF وجود ندارد. این را می توان با کد اسمبلی زیر بدست آورد: pushf ; Use the stack to transfer the FLAGS pop ax ; ...into the AX register push ax ; and copy them back onto the stack for storage xor ax, 400h ; Toggle (compleme
nt) DF only; other bits are unchanged push ax ; Use the stack again to move the modified value popf ; ...into the FLAGS register popf ; Restore the original value of the FLAGS با دستکاری کردن ثبات پرچم ها، یک برنامه می تواند مدل پردازنده نصب شده را تعیین کند. به عنوان مثال، پرچم تنظیم(alignment) تنها می تواند در 486 و بالاتر تغییر کند. اگر برنامه تلاش کند تا این پرچم را تغییر دهد و حس کند که تغییر ادامه نیافته است، پردازنده پیش از 486 است. دستورالعمل CPUID، با استفاده از اینتل پنتیوم ، مدل پردازنده را گزارش می دهد. با این حال، روش فوق برای تشخیص بین مدل های قبلی مفید است.
حافظه دفتر یادداشت ()، همچنین به عنوان دفتر یادداشت (scratchpad)، رم (حافظه) دفتر یادداشت یا حافظه محلی در اصطلاحات کامپیوتر، یک حافظه داخلی سرعت بالا است که برای نگداری موقت محاسبات، داده ها، و عملیات دیگر در حال اجرا استفاده می شود. با اشاره به یک ریزپردازنده (واحد پردازش مرکزی) ,scratchpad به یک مدار حافظه مخصوص با سرعت بالا که برای نگهداری اطلاعات کوچک برای بازیابی سریع استفاده می شود، اشاره دارد. این حافظه شبیه از لحاظ اندازه و استفاده به یک دفتر یادداشت در زندگی است: یک مجموعه از کاغذها برای یادداشت های اولیه، طرح ها یا نوشته ها، و غیره. این حافظه را می توان شبیه به حافظه نهان L1 در نظر گرفت که در آن، نزدیکترین حافظه ای است به واحد محاسبه و منطق پس از ثبات های پردازنده و با دستورالعمل های صریح و اختصاصی برای انتقال داده ها به حافظه اصلی یا از حافظه اصلی، که اغلب مبتنی بر استفاده از انتقال داده DMA است. در مقایسه با یک سیستم که از حافظه های نهان(cache) استفاده می کند، یک سیستم با این حافظه ها(scratchpad)، یک سیستم با تاخیرهای حافظه دسترسی غیریکپارچه است، زیرا تاخیرهای دسترسی به انواع مختلف این حافظه و حا
فظه اصلی تفاوت دارد. یک تفاوت دیگر که یک سیستم از حافظه های نهان استفاده می کند، این است که این حافظه معمولاً یک کپی از داده ها را ندارد که در حافظه اصلی ذخیره شده اند. Scratchpadها برای ساده سازی منطق ذخیره سازی نهان(caching) استفاده می شوند و برای تضمین اینکه یک واحد می تواند بدون درگیری حافظه اصلی در یک سیستم با استفاده از پردازنده های چندگانه کار کند، به خصوص در سیستم چند پردازنده ای سیستم بر تراشه() که برای سیستم های نهفته هستند. آنها عمدتاً برای ذخیره سازی نتایج موقت (همان طور که در پشته CPU یافت می شوند) مناسب می باشند و معمولاً نیازی به درخواست دادن به حافظه اصلی نیستند. با این حال هنگامی که توسط DMA تغذیه می شود، می توانند به جای یک حافظه نهان برای بررسی وضعیت حافظه اصلی آهسته تر، استفاده شوند. مسائل مربوط به مکان مرجع در رابطه با کارایی استفاده می شود؛ اگر چه بعضی از سیستم ها اجازه دسترسی به DMA را برای دسترسی به مجموعه داده های مستطیلی می دهند. یکی دیگر از تفاوت این است که scratchpadها به صراحت و به صورت مستقیم توسط برنامه ها دستکاری می شود. آنها ممکن است برای برنامه های بی درنگ مفید باشند، در حالی