یک پردازنده پایپ‌لاین‌شده چگونه استثناها را مدیریت می‌کند

هر دستوری آن‌طور که انتظار می‌رود اجرا نمی‌شود — برخی شرایط خطایی مانند یک opcode نامعتبر یا سرریز محاسباتی را فعال می‌کنند که پردازنده باید با امنیت به آن‌ها پاسخ دهد. این مقاله توضیح می‌دهد استثناها چه هستند، یک پردازنده پایپ‌لاین‌شده چگونه آن‌ها را بدون خراب کردن وضعیت برنامه تشخیص داده و مدیریت می‌کند، و چرا استثناها مشابه خطرهای کنترلی رفتار می‌شوند.

استثناهامدیریت استثناتشخیص استثنا در پایپ‌لاین

~3 min read · Updated Sep 6, 2026

استثنا چیست

یک Exception (که بسته به منبعش گاهی Interrupt نیز نامیده می‌شود) یک رویداد غیرمنتظره در حین اجرای دستور است که جریان معمولی یک برنامه نمی‌تواند به‌تنهایی آن را مدیریت کند، مانند تلاش برای اجرای دستوری با یک opcode نامعتبر، سرریز محاسباتی، یا تلاش برای دسترسی به یک آدرس حافظه که برنامه اجازه دسترسی به آن را ندارد.

چرا استثناها را نمی‌توان به‌سادگی نادیده گرفت

ادامه اجرای معمولی پس از یک شرط استثنایی رفتار نادرست یا نامشخصی تولید می‌کند. در عوض، پردازنده باید دستور خطاساز را متوقف کند، اطلاعات کافی درباره آنچه در آن لحظه در حال رخ دادن بود را حفظ کند، و کنترل را به یک قطعه نرم‌افزاری خاص به نام Exception Handler منتقل کند، که تصمیم می‌گیرد چگونه پاسخ دهد، چه به معنای خاتمه دادن به برنامه خطاساز باشد چه تلاش برای نوعی بازیابی.

تشخیص استثناها در یک طرح پایپ‌لاین‌شده

در یک پردازنده پایپ‌لاین‌شده، چند دستور به‌طور هم‌زمان در حال پیشرفت هستند، و دستورات مختلف می‌توانند در مراحل مختلف پایپ‌لاین استثنا فعال کنند. یک opcode نامعتبر معمولاً در حین decode تشخیص داده می‌شود، در حالی که سرریز محاسباتی فقط در حین مرحله execute تشخیص داده می‌شود، و یک نقض دسترسی حافظه ممکن است فقط در حین مرحله دسترسی به حافظه تشخیص داده شود.

به همین دلیل، پایپ‌لاین باید همراه با هر دستور در حین حرکت آن به جلو ردیابی کند که آیا هر شرط استثنایی را فعال کرده یا نه، بدون اینکه بلافاصله کل پایپ‌لاین را در لحظه‌ای که شرط برای اولین‌بار تشخیص داده می‌شود متوقف کند.

شباهت با خطرهای کنترلی

مدیریت یک استثنا شباهت زیادی به مدیریت یک شاخه پیش‌بینی‌نادرست‌شده دارد، که پیش‌تر در این مجموعه پوشش داده شد: دستوراتی که پس از دستور استثناساز واکشی شده‌اند، اما در واقع نباید اجرا شوند، باید از پایپ‌لاین تخلیه شوند، و کنترل باید به مکان دیگری بپرد، در این مورد، آدرس exception handler به‌جای یک مقصد شاخه.

دستور استثناساز:      IF ID EX MEM WB
دستورات بعدی:             IF ID [پس از تشخیص استثنا تخلیه می‌شوند]
Exception handler:                     IF [به‌جای آن واکشی می‌شود]

حفظ اطلاعات کافی برای بازیابی

پیش از انتقال کنترل به exception handler، پردازنده باید ثبت کند کدام دستور مسئله را ایجاد کرده، معمولاً با ذخیره آدرس آن در یک رجیستر اختصاصی، تا handler، یا سیستم‌عاملی که به آن متکی است، بتواند تصمیم بگیرد بعداً چه کاری انجام دهد: خاتمه دادن به برنامه، تلاش مجدد برای دستور پس از رفع مسئله زیربنایی، یا انجام برخی اقدامات اصلاحی دیگر.

چرا مدیریت درست استثنا اهمیت دارد

توانایی یک سیستم‌عامل برای گرفتن خطاهای برنامه‌نویسی، اجرای حفاظت حافظه بین برنامه‌های مختلف در حال اجرا، و پشتیبانی از ویژگی‌هایی مانند حافظه مجازی، همگی مستقیماً به تشخیص درست شرایط استثنایی توسط پردازنده و انتقال قابل‌اعتماد کنترل به نرم‌افزار مدیریت‌کننده بستگی دارند، به‌جای تولید بی‌سروصدای نتایج نادرست یا کرش کردن بدون مسیر بازیابی کنترل‌شده.

Written & researched by Dr. Shahin Siami

Related Articles

تصورات غلط رایج درباره محاسبات موازی و درس‌های نهایی کتاب

پس از پوشش هر چیزی از موازی‌سازی سطح رشته تا محاسبات در مقیاس انبار، ارزش دارد تصورات غلط پایداری درباره سیستم‌های موازی که حتی مهندسان باتجربه هم گاهی به آن‌ها دارند را اصلاح کنیم. این مقاله به مغالطات رایج درباره مقیاس‌پذیری و سخت‌افزار موازی می‌پردازد، سپس فصل پردازش موازی را با پیوند دادن مسیر کامل از یک دستور منفرد تا یک ساختمان پر از ماشین‌های همکار به پایان می‌رساند.

Continue

واقعیت‌های عملی: بنچمارک CPU در مقابل GPU و ضرب ماتریس چندپردازنده‌ای

مقایسه منصفانه یک CPU و یک GPU نیازمند مدلی است که هم توان عملیاتی محاسباتی و هم محدودیت‌های پهنای باند حافظه را با هم در نظر بگیرد. این مقاله مدل roofline مورد استفاده برای مقایسه سخت‌افزار واقعی مانند Intel Core i7 و NVIDIA Tesla GPU را معرفی می‌کند، سپس نشان می‌دهد ضرب ماتریس چگونه در سراسر چند پردازنده تسریع می‌شود، به‌عنوان کاربرد عملی نهایی مفاهیم موازی این فصل.

Continue

بنچمارک کردن چندپردازنده‌ها و مدل‌سازی کارایی موازی

سنجش کارایی یک سیستم موازی نیازمند ابزارها و سنجه‌های متفاوتی نسبت به سنجش یک پردازنده تک‌هسته‌ای است. این مقاله بنچمارک‌های تخصصی مورد استفاده برای ارزیابی سیستم‌های چندپردازنده را پوشش می‌دهد، توضیح می‌دهد چگونه رفتار مقیاس‌پذیری را با افزودن پردازنده‌های بیشتر مدل‌سازی کنیم، و قانون آمدال را در زمینه سنجش کارایی دنیای واقعی بازبینی می‌کند.

Continue

شبکه‌سازی کلاستر: ارتباط با دنیای بیرون

یک کلاستر از ماشین‌ها فقط زمانی مفید است که بتواند به‌طور کارآمد هم داخلی و هم با دنیای بیرون ارتباط برقرار کند. این مقاله لایه‌های شبکه‌سازی درگیر در ارتباط کلاستر، مبادلات بین تأخیر و پهنای باند در مقیاس، و اینکه کلاسترها چگونه به شبکه‌های خارجی و کاربران متصل می‌شوند را پوشش می‌دهد.

Continue

کلاسترها، کامپیوترهای در مقیاس انبار، و توپولوژی‌های شبکه

فراتر از یک تراشه واحد، موازی‌سازی به کل ساختمان‌های پر از کامپیوترهای مستقلی که با هم کار می‌کنند گسترش می‌یابد. این مقاله گذار از چندپردازنده‌سازی حافظه مشترک به کلاسترهایی از ماشین‌های جداگانه را توضیح می‌دهد، مفهوم محاسبات در مقیاس انبار را معرفی می‌کند، و توپولوژی‌های شبکه که این ماشین‌های مستقل را به‌طور کارآمد متصل می‌کنند را پوشش می‌دهد.

Continue

مقدمه‌ای بر GPU: موازی‌سازی عظیم برای بارهای کاری سنگین از نظر داده

یک GPU ایده SIMD که پیش‌تر در این مجموعه پوشش داده شد را به یک مقیاس افراطی می‌برد، و هزاران رشته سبک را به‌طور هم‌زمان اجرا می‌کند تا حجم عظیمی از داده مستقل را پردازش کند. این مقاله توضیح می‌دهد چرا GPU ها از نظر معماری این‌قدر با CPU متفاوت‌اند، مدل اجرای رشته آن‌ها چگونه کار می‌کند، و چه نوع بارهای کاری بیشترین بهره را از این طراحی می‌برند.

Continue