البحث في الموقع

ذكرنا من الفصل السابق الذاكرة الوهمية والذاكرة الحقيقية في معمارية الحاسوب من سلسلتنا مدخل لعلم الحاسوب حتى الآن أن العتاد يعمل مع نظام التشغيل لتقديم Implementation الذاكرة الوهمية، وألقينا نظرة على تفاصيل كيفية حدوث ذلك. تعتمد الذاكرة الوهمية بصورة كبيرة على معمارية العتاد، حيث يكون لكل معمارية خواصها الدقيقة، ولكن هناك عدد من العناصر الخاصة بالذاكرة الوهمية في العتاد التي سنستعرضها في هذا المقال. الوضع الحقيقي والوضع الوهمي تحتوي جميع المعالجات على مفهومٍ ما للعمل في الوضع الحقيقي Physical Mode أو الوضع الوهمي Virtual Mode، إذ يتوقع العتاد في الوضع الحقيقي أن يشير أيّ عنوان إلى عنوانٍ موجود في ذاكرة النظام الفعلية، بينما يعرف العتاد في الوضع الوهمي أنه يجب ترجمة العناوين للعثور على العنوان الحقيقي. يُشار إلى هذين الوضعين في العديد من المعالجات مثل المعالج إيتانيوم Itanium ببساطة على أنهما الوضع الحقيقي والوضع الوهمي. المعالج x86 الأكثر شيوعًا لديه الكثير من الخاصيات منذ الأيام الماضية التي تسبق الذاكرة الوهمية، حيث يُشار إلى هذين الوضعين على أنهما الوضع الفعلي Real Mode والوضع المحمي Protected Mode. كان أول معالج يطبق الوضع المحمي هو المعالج 386، ولا تزال أحدث المعالجات من عائلة x86 بإمكانها العمل في الوضع الفعلي بالرغم من عدم استخدامه. يطبّق المعالج في الوضع الفعلي شكلًا من أشكال تنظيم الذاكرة يسمى التقطيع Segmentation. مشاكل التقطيع كان التقطيع أمرًا مهمًا سابقًا، ولكن قلّلت الذاكرة الوهمية من أهميته، فللتقطيع عيوبه مثل كونه مربكًا للمبرمجين المبتدئين، لذا اُخترِعت أنظمة الذاكرة الوهمية لحل هذه المشاكل إلى حد كبير. يوجد في التقطيع عدد من المسجّلات التي تحتوي على عنوان يمثل بداية المقطع، والطريقة الوحيدة للوصول إلى عنوان في الذاكرة هي تحديده بوصفه إزاحة من أحد هذه المسجلات. يمكن تحديد حجم المقطع والحد الأقصى للإزاحة الذي يمكنك تحديده من خلال عدد البتات المتاحة للإزاحة من مسجل المقطع الأساسي. الحد الأقصى للإزاحة في المعالج x86 هو 16 بتًا أو 64 كيلوبايت فقط، مما يؤدي إلى ظهور جميع أشكال الفوضى، حيث إذا أراد شخصٌ ما استخدام عنوان يبعد أكثر من 64 كيلوبايت، فستتحول الأمور من مجرد إزعاج بسيط إلى فشل كامل عندما ينمو حجم الذاكرة إلى عدد من الميجابايتات أو الجيجابايتات. لنفترض أن أقصى إزاحة هي 32 بتًا، وبالتالي يمكن الوصول إلى فضاء العناوين بالكامل بوصفه إزاحة من مقطع عند العنوان 0x00000000 وسيكون لديك تخطيط مسطح، ولكن لا تضاهي هذه الحالة جودة الذاكرة الوهمية. السبب الوحيد لكون الإزاحة بمقدار 16 بت هو أن معالجات إنتل Intel الأصلية كانت محدودة بهذا المقدار مع محافظة الشرائح على التوافق مع الإصدارات السابقة. التقطيع Segmentation هناك ثلاثة مسجلات مقاطع في الشكل السابق تؤشّر جميعها إلى المقاطع، ويظهر حد الإزاحة الأقصى المُقيَّد بعدد البتات المتاحة في المنطقة المُظلَّلة. إذا أراد البرنامج عنوانًا خارج هذا النطاق، فيجب إعادة ضبط مسجّلات المقاطع الذي سرعان ما يصبح مصدر إزعاج كبير فيما بعد. بينما تسمح ذاكرة البرنامج الوهمية بتحديد العنوان الذي تريده ويطبّق نظام التشغيل والعتاد عملية الترجمة إلى عنوان حقيقي. مخزن الترجمة المؤقت TLB يُعَد مخزن الترجمة المؤقت Translation Lookaside Buffer -أو TLB اختصارًا- مكون المعالج الرئيسي المسؤول عن الذاكرة الوهمية، وهو ذاكرةٌ مخبئية لعمليات ترجمة الصفحة الوهمية إلى الإطار الحقيقي في المعالج. يعمل نظام التشغيل والعتاد مع بعضهما البعض لإدارة مخزن TLB أثناء تشغيل النظام. أخطاء الصفحات إذا طُلِب عنوان وهمي من العتاد باستخدام تعليمة تحميل load مثلًا للحصول على بعض البيانات، فسيبحث المعالج عن ترجمة العنوان الوهمي إلى العنوان الحقيقي في مخزن TLB الخاص به، فإن احتوى على ترجمة صالحة، فيمكن عندئذٍ دمجه مع جزء الإزاحة للانتقال مباشرةً إلى العنوان الحقيقي وإكمال التحميل. لكن إن لم يتمكّن المعالج من العثور على ترجمةٍ في مخزن TLB، فيجب على المعالج إصدار خطأ الصفحة Page Fault الذي يشبه المقاطعة، ويجب أن يعالجه نظام التشغيل، إذ يجب أن يستعرض نظام التشغيل جدول الصفحات للعثور على الترجمة الصحيحة وإدخالها في مخزن TLB عند حدوث خطأ صفحة. إن لم يتمكّن نظام التشغيل من العثور على ترجمةٍ في جدول الصفحات أو إن تحقّق نظام التشغيل من أذونات الصفحة المطلوبة ولم يُسمَح للعملية بالوصول إليها، فيجب على نظام التشغيل إنهاء العملية. إن رأيتَ مسبقًا خطأ تقطيع أو ما يُسمَّى Segfault، فهذا يعني أن نظام التشغيل ينهي العملية التي تجاوزت حدودها. بينما إن تمكّن نظام التشغيل من العثور على الترجمة وكان مخزن TLB ممتلئًا حاليًا، فيجب إزالة ترجمة قبل إدخال ترجمةٍ أخرى. ليست إزالة الترجمة التي يُحتمَل استخدامها لاحقًا أمرًا منطقيًا، إذ ستتحمل عناء العثور على المدخلة في جداول الصفحات مرةً أخرى. تستخدم مخازن TLB شيئًا يشبه خوارزمية الأقل استخدامًا مؤخرًا Least Recently Used -أو LRU اختصارًا، حيث تُخرَج أقدم ترجمة غير مُستخدمَة لإدخال ترجمة جديدة. يمكن بعد ذلك محاولة الوصول مرة أخرى وسيسير كل شيء على ما يرام، حيث يجب العثور على الترجمة في مخزن TLB وستحدث الترجمة بصورة صحيحة. العثور على جدول الصفحات لا بد أنك تساءلت عن كيفية إيجاد نظام التشغيل للذاكرة التي تحتوي على جدول الصفحات page table عندما قلنا أن نظام التشغيل يجد الترجمة في هذا الجدول. يُحتفَظ بقاعدة جدول الصفحات في مسجّل مرتبط بكل عملية، حيث يسمى هذا المسجل بالمسجل الأساسي لجدول الصفحات page-table base-register أو ما شابه ذلك. يمكن تحديد موقع المدخلة الصحيحة بوضع العنوان في هذا المسجل وإضافة رقم الصفحة إليه. أخطاء أخرى متعلقة بالصفحات هناك عيبان مهمان آخران يمكن أن يولّدهما مخزن TLB ويساعدان على إدارة الصفحات المتسخة dirty pages أي الصفحات التي جرى الوصول إليها مسبقًا، حيث تحتوي كل صفحة على سمة مُمثَّلة ببتٍ واحد تحدّد إذا جرى الوصول إلى الصفحة أي أنها أصبحت صفحة متسخة. يمكن تمييز الصفحة على أنها صفحة جرى الوصول إليها مسبقًا عند تحميل ترجمة الصفحة مبدئيًا في مخزن TLB. إذا حمّلتَ الصفحة دون وصول معلَّق، فيمكن تسمية ذلك بالتأمّل Speculation مثل تطبيق شيءٍ ما مع التوقّع بأنه سيؤتي ثماره، حيث إذا قرأت الشيفرة البرمجية من الذاكرة خطيًا مثلًا، فيمكن أن يؤدي وضع ترجمة الصفحة التالية في مخزن TLB إلى توفير الوقت وتحسين الأداء. يعمل نظام التشغيل على تصفح جميع الصفحات دوريًا ويصفّر بت الوصول ليميز الصفحات التي تكون قيد الاستخدام حاليًا من غيرها. تكون الصفحات التي لم يُعاد ضبط بت الوصول الخاص بها (بعد تصفيره) هي أفضل المرشحين للإزالة لأنها لم تُستخدَم لفترة أطول عندما تمتلئ ذاكرة النظام ويحين الوقت لنظام التشغيل لاختيار الصفحات التي ستُبدَّل إلى القرص الصلب. الصفحة المتسخة هي الصفحة التي تحتوي على بياناتٍ مكتوبةٍ عليها، وبالتالي لا تتطابق مع أيّ بيانات موجودة فعليًا على القرص الصلب. إذا بُدِّلت الصفحة من ثم كتبت فيها عملية مثلًا، فيجب تحديث نسختها الموجودة على القرص الصلب قبل تبديلها. لا تُجرَى أيّ تغييرات على الصفحة النظيفة، لذلك لا حاجة لنسخ الصفحة مرةً أخرى إلى القرص الصلب. يتشابه هذان النوعان من الصفحات من حيث أنهما يساعدان نظام التشغيل في إدارة الصفحات، حيث تحتوي الصفحة على بتين إضافيين هما: البت المتسخ Dirty Bit وبت الوصول Accessed Bit، إذ يُضبَط هذان البتان عند وضع الصفحة في مخزن TLB للإشارة إلى أن وحدة المعالجة المركزية يجب أن تصدر خطأ. يطبّق العتادُ عملية الترجمة المعتادة عندما تحاول إحدى العمليات الرجوع إلى الذاكرة، ولكنه يجري أيضًا فحصًا إضافيًا للتأكد من عدم ضبط راية الوصول. إذا كان الأمر كذلك، فسيؤدي ذلك إلى حدوث خطأ في نظام التشغيل الذي يجب أن يضبط البت ويسمح للعملية بالاستمرار. إذا اكتشف العتاد أنه يكتب في صفحةٍ يكون بتها المتسخ غير مضبوط، فسيؤدي ذلك إلى حدوث خطأ في نظام التشغيل لتمييز الصفحة بوصفها متسخة. إدارة مخزن TLB يمكننا القول أن مخزن TLB يستخدمه العتاد ولكن تديره البرمجيات، فالأمر متروك لنظام التشغيل لتحميل المدخلات الصحيحة إلى مخزن TLB ولإزالة المدخلات القديمة منه. تفريغ مخزن TLB تُسمَّى عملية إزالة المدخلات من مخزن TLB باسم التفريغ Flushing. يُعَد تحديث مخزن TLB جزءًا مهمًا من الحفاظ على فضاءات عناوين العمليات منفصلة، لأن كل عملية يمكن أن تستخدم العنوان الوهمي نفسه دون تحديث مخزن TLB، وهذا يعني أن العملية يمكن أن تكتب فوق ذاكرة العمليات الأخرى، بينما تريد في حالة الخيوط Threads مشاركة فضاء العناوين، وبالتالي لا يُفرَّغ مخزن TLB عند التبديل بين الخيوط في العملية نفسها. يُفرَّغ مخزن TLB بالكامل في بعض المعالجات في كل مرة يوجد فيها تبديل سياق، ويمكن أن يكون ذلك مرهقًا للغاية، لأنه يعني أن العملية الجديدة يجب أن تمر عبر المراحل كاملةً من أخذ خطأ الصفحة ثم العثور على الصفحة في جداول الصفحات وإدخال الترجمة. بينما تطبّق المعالجات الأخرى معرّف فضاء عناوين إضافي Address Space ID -أو ASID اختصارًا- يُضاف إلى كل ترجمة في مخزن TLB لجعلها فريدة، وبالتالي يحصل كل فضاء عناوين -أو كل عملية حيث تريد الخيوط مشاركة فضاء العناوين نفسه- على معرّفها الخاص الذي يُخزَّن مع الترجمات في مخزن TLB، أي ليس هناك داعٍ لتفريغ مخزن TLB عند تبديل السياق، لأن العملية التالية سيكون لها معرّف فضاء عناوين مختلف، وسيختلف معرّف فضاء العناوين وستختلف الترجمة إلى الصفحة الحقيقية حتى إن طلبت العملية العنوان الوهمي نفسه. يقلل هذا النظام من عملية التفريغ ويزيد من أداء النظام، ولكنه يتطلب مزيدًا من عتاد TLB ليحتفظ ببتات معرّف ASID. يمكن تنفيذ ذلك من خلال وجود مسجل إضافي بوصفه جزءًا من حالة العملية التي تتضمن معرّف ASID. ينظر مخزن TLB إلى هذا المسجّل عند ترجمة الصفحة الوهمية إلى الصفحة الحقيقية، وسيطابق فقط المدخلات التي لها معرّف ASID الخاص بالعملية التي تكون قيد التشغيل حاليًا. يحدّد حجم هذا المسجل رقم معرّفات ASID المتاحة وبالتالي له تأثير على الأداء. مخزن TLB المحمل برمجيا وعتاديا يُعَد التحكم في مخزن TLB من اختصاص نظام التشغيل، ولكنها ليست القصة كاملة، إذ تشرح العملية الموضَّحة في فقرة "أخطاء الصفحات" خطأ الصفحة الذي يُرفَع إلى نظام التشغيل، ويمر على جدول الصفحات للعثور على ترجمة الصفحة الوهمية إلى الحقيقية وتثبيتها في مخزن TLB. يمكن أن يسمَّى ذلك بمخزن TLB المُحمَّل برمجيًا Software-loaded TLB، وهناك بديل آخر هو مخزن TLB المُحمَّل عتاديًا Hardware-loaded TLB. تحدد معمارية المعالج تخطيطًا معينًا لمعلومات جدول الصفحات في مخزن TLB المُحمَّل عتاديًا، ويجب اتباعها حتى ترجمة العنوان الوهمي. سيمر المعالج تلقائيًا على جداول الصفحات لتحميل مدخلة الترجمة الصحيحة استجابةً للوصول إلى عنوان وهمي غير موجود في مخزن TLB، وسيرفع المعالج استثناءً ليعالج نظام التشغيل مدخلة الترجمة غير الموجودة في مخزن TLB. يوفّر التنفيذ المُقدَّم للمرور على جدول الصفحات في العتاد المتخصص مزايا السرعة عند البحث عن الترجمات، ولكنه يزيل المرونة عن مطبّقي أنظمة التشغيل الذين يرغبون في تنفيذ مخططات بديلة لجداول الصفحات. يمكن تصنيف جميع المعماريات على نطاق واسع ضمن هاتين المنهجيتين السابقتين، وسنطّلع تاليًا على بعض المعماريات الشائعة ودعم الذاكرة الوهمية. دعم العتاد للذاكرة الوهمية يوفّر عتاد المعالج جدول بحث يربط العناوين الوهمية بالعناوين الحقيقية، حيث تحدد معماريات المعالجات طرقًا مختلفة لإدارة مخزن TLB مع مزايا وعيوب مختلفة. يشار إلى جزء المعالج الذي يتعامل مع الذاكرة الوهمية باسم وحدة إدارة الذاكرة Memory Management Unit أو MMU اختصارًا. معالج إيتانيوم توفر وحدة MMU في معالج إيتانيوم ميزات متعددة لنظام التشغيل للتعامل مع الذاكرة الوهمية سنوضحها فيما يلي. فضاءات العناوين Address spaces شرحنا سابقًا مفهوم معرّف فضاء العناوين لتقليل تكلفة تفريغ مخزن TLB عند تبديل السياق، ولكن يستخدم المبرمجون في أغلب الأحيان الخيوط Threads للسماح لسياقات التنفيذ بمشاركة فضاء العناوين، حيث تحتوي جميع الخيوط على معرّف ASID نفسه، وبالتالي يتشاركون بمدخلات مخزن TLB، مما يؤدي إلى زيادة الأداء. لكن يمنع معرّف ASID واحد مخزن TLB من فرض الحماية، حيث تصبح المشاركة متمثلة بنهج "الكل أو لا شيء"، إذ يجب أن تتخلى الخيوط عن الحماية من بعضها البعض لمشاركة بعض البايتات. رسم توضيحي للمناطق ومفاتيح الحماية في معالج إيتانيوم تدرس وحدة MMU في معالج إيتانيوم المشاكل السابقة وتوفر القدرة على مشاركة فضاء العناوين ومدخلات الترجمة بدقة أقل بكثير مع الحفاظ على الحماية داخل العتاد. يقسم معالج إيتانيوم فضاء العناوين المؤلف من 64 بتًا إلى 8 مناطق كما هو موضَّح في الشكل السابق. تحتوي كل عملية على ثمانية مسجلات مناطق بحجم 24 بتًا بوصفها جزءًا من حالتها، ويحتوي كل منها على معرّف منطقة Region ID -أو RID اختصارًا- لكل منطقة من المناطق الثمانية الخاصة بفضاء عناوين العملية. تُوسَم ترجمات مخزن TLB بمعرّف RID، وبالتالي لن تتطابق إلا إذا احتوت العملية على معرّف RID نفسه كما هو موضَّح في الشكل التالي: رسم توضيحي لترجمة مخزن TLB في معالج إيتانيوم لا تُحتسَب البتات الثلاثة الأولى (بتات المنطقة) في ترجمة العنوان الوهمي، لذلك إذا كانت هناك عمليتان تشتركان في معرّف RID أي تحتفظان بالقيمة نفسها في أحد مسجلات المنطقة الخاصة بهما، فسيكون لديهما اسم بديل لتلك المنطقة. إذا احتوت العملية A على معرّف RID قيمته 0x100 في مسجل المنطقة 3 واحتوت العملية B معرّف RID نفسه الذي قيمته 0x100 في مسجّل المنطقة 5، فستُسمَّى المنطقة 3 من العملية A باسم بديل هو process-B, region 5. تعني هذه المشاركة المحدودة أن كلتا العمليتين تتلقيان فوائد مدخلات مخزن TLB المشتركة دون الحاجة إلى منح إذن الوصول إلى كامل فضاء العناوين. مفاتيح الحماية Protection Keys تُوسَم كل مدخلة من مخزن TLB في معالج إيتانيوم بمفتاح حماية للسماح بمشاركة أكثر دقة. تحتوي كل عملية على عدد إضافي من مسجلات مفاتيح الحماية يحدده نظام التشغيل. تُوسَم كل صفحة بمفتاح فريد ويمنح نظام التشغيل العمليات المسموح بها للوصول إلى الصفحات التي تستخدم هذا المفتاح عند مشاركة سلسلة من الصفحات مثل شيفرة برمجية لمكتبة نظام مشتركة. يفحص مخزن TLB المفتاح المرتبط بمدخلة الترجمة مقابل المفاتيح التي تحتفظ بها العملية في مسجلات مفتاح الحماية الخاصة بها عند الإشارة إلى صفحة ما، مما يسمح بالوصول إليها في حالة وجود المفتاح أو يؤدي إلى رفع خطأ حماية لنظام التشغيل. يمكن للمفتاح فرض الأذونات أيضًا، إذ يمكن أن تحتوي إحدى العمليات مثلًا على مفتاح يمنح أذونات الكتابة ويمكن أن تحتوي عملية أخرى على مفتاح للقراءة فقط، مما يسمح بمشاركة مدخلات الترجمة بدقة وفي نطاق أوسع بكثير وصولًا إلى مستوى الصفحة الواحدة، ويؤدي ذلك إلى تحسينات محتملة كبيرة في أداء مخزن TLB. أداة إيتانيوم العتادية للمرور على جدول الصفحات Itanium Hardware Page-Table Walker يؤدي تبديل السياق إلى نظام التشغيل عند حل خطأ في مخزن TLB إلى إضافة عبء كبير إلى مسار معالجة الخطأ، إذ يواجه معالج إيتانيوم ذلك العبء من خلال السماح بخيار استخدام العتاد المُدمَج لقراءة جدول الصفحات وتحميل ترجمات الصفحة الوهمية إلى الصفحة الحقيقية في مخزن TLB تلقائيًا. تتجنب أداة المرور على جدول الصفحات العتادية Hardware Page-table Walker -أو HPW اختصارًا- عمليات الانتقال المكلفة إلى نظام التشغيل، ولكنه يتطلب أن تكون الترجمات بصيغة ثابتة ومناسبة للعتاد لتفهمه. يُشار إلى أداة HPW الخاصة بمعالج إيتانيوم في توثيق إنتل على أنها أداة مُعمَّاة وهميًا للمرور على جدول الصفحات Virtually Hashed Page-table Walker أو VHPT walker اختصارًا. يمنح معالج إيتانيوم المطورين خيارين من تقديمات HPW الحصرية تبادليًا، إذ يعتمد أحدهما على جدول الصفحات الخطي الوهمي ويعتمد الآخر على جدول التعمية Hash Table. تجدر الإشارة إلى أنه يمكن العمل بدون أداة عتادية للمرور على جدول الصفحات، حيث يحل نظام التشغيل كل خطأ TLB ويصبح المعالج معمارية محمَّلة برمجيًا، ولكن يُعَد تأثير تعطيل HPW على الأداء كبيرًا جدًا دون الحصول على أيّ فائدة. جدول الصفحات الخطي الوهمي Virtual Linear Page-Table يشار إلى تقديم جدول الصفحات الخطي الوهمي في التوثيقات على أنه الصيغة القصيرة لجدول الصفحات المُعمَّاة وهميًا Short Format Virtually Hashed Page-table -أو SF-VHPT اختصارًا، وهو نموذج HPW الافتراضي الذي يستخدمه لينكس على معالج إيتانيوم. الحل المعتاد هو استخدام جدول صفحات متعدد المستويات أو هرمي، حيث تُستخدَم البتات التي تتكون من رقم الصفحة الوهمية بوصفها فهرسًا إلى مستويات وسيطة من جدول الصفحات. لا توجد مناطق فضاء عناوين وهمية فارغة في جدول الصفحات الهرمي. تُهدَر مساحة صغيرة نسبيًا في الحِمل الإضافي بالنسبة للحالة الواقعية لفضاء العناوين المُجمَّعة Clustered بإحكام والمملوءة بصورة ضئيلة بالمقارنة مع جدول الصفحات الخطي، ولكن العيب الرئيسي هو مراجع الذاكرة المتعددة المطلوبة للبحث. رسم توضيحي لجدول صفحات هرمي يأخذ الجدول الخطي الذي حجمه 512 جيبي بايت GiB مع فضاء عناوين 64 بتًا ما مقداره 0.003% فقط من 16 إكسابايت المتاحة، وبالتالي يمكن إنشاء جدول صفحات خطي وهمي Virtual Linear Page-table -أو VLPT اختصارًا- في منطقة متجاورة من فضاء العناوين الوهمية. يستخدم العتاد عند حدوث خطأ في مخزن TLB رقم الصفحة الوهمية للإزاحة عن قاعدة جدول الصفحات تمامًا كما هو الحال بالنسبة لجدول صفحات خطي حقيقي. إذا كانت هذه المدخلة صحيحة، فستُقرَأ الترجمة وتُدرَج مباشرةً في مخزن TLB، ولكن يكون عنوان مدخلة الترجمة في حد ذاتها عنوانًا وهميًا باستخدام جدول VLPT، وبالتالي هناك احتمال أن تكون الصفحة الوهمية التي توجد بها غير موجودة في مخزن TLB، وسيُرفَع خطأ متداخل Nested Fault إلى نظام التشغيل في هذه الحالة. يجب على البرمجيات بعد ذلك تصحيح هذا الخطأ عن طريق ربط الصفحة التي تحتوي على مدخلة الترجمة مع جدول VLPT. تقديم جدول VHPT بصيغة قصيرة في معالج إيتانيوم يمكن جعل هذه العملية مباشرةً إذا احتفظ نظام التشغيل بجدول صفحات هرمي، حيث تحتوي الصفحة التي تمثل ورقة من جدول صفحات هرمي على مدخلات ترجمة لمنطقة متجاورة وهميًا من العناوين، وبالتالي يمكن ربطها باستخدام مخزن TLB لإنشاء جدول VLPT كما هو موضح في الشكل السابق. صيغ مدخلة PTE في معالج إيتانيوم تحدث ميزة جدول VLPT الرئيسية عندما يطلب أحد التطبيقات وصولًا متكررًا أو متواصلًا إلى الذاكرة. ضع في حساباتك أن الخطأ الأول في عملية المرور على الذاكرة المتجاورة وهميًا سيؤدي إلى ربط صفحة مليئة بمدخلات الترجمة مع جدول الصفحات الخطي الوهمي. سيتطلب الوصول اللاحق إلى الصفحة الوهمية التالية تحميلَ مدخلة الترجمة التالية في مخزن TLB، والتي تتوفر الآن في جدول VLPT، وبالتالي تُحمَّل بسرعة كبيرة دون استدعاء نظام التشغيل. سيكون ذلك ميزةً عند الاستفادة من تكلفة الخطأ المتداخل الأولي على عمليات مرور HPW الناجحة اللاحقة. العيب الرئيسي هو أن جدول VLPT يتطلب الآن مدخلات مخزن TLB، مما يؤدي إلى زيادة الضغط عليه. يتطلب كل فضاء عناوين جدول صفحاتٍ خاص به، لذلك تصبح التكلفة أكبر كلما أصبح النظام أكثر نشاطًا، ولكن يجب أن تكون أيّ زيادة في أخطاء الوصول إلى مخزن TLB أكبر من الفائدة الحاصلة عند انخفاض تكاليف إعادة الملء من أداة المرور العتادية الفعالة. لاحظ أن الحالة السيئة يمكن أن تتخطى مدخلات بمقدارٍ يساوي نتيجة قسمة حجم الصفحة page_size على حجم الترجمة translation_size، مما يتسبب في حدوث أخطاء متداخلة ومتكررة، ولكنه يُعَد نمط وصول غير مُحتمَل. تتوقع أداة المرور العتادية hardware walker أن تكون مدخلات الترجمة بصيغة معينة كما هو موضح على يسار الشكل السابق، حيث يتطلب جدول VLPT ترجمات بصيغة قصيرة مؤلَّفة من 8 بايتات. إذا استخدم نظام التشغيل جدول الصفحات الخاص به بوصفه دعمًا لجدول VLPT كما في الشكل "تقديم جدول VHPT بصيغة قصيرة في معالج إيتانيوم"، فيجب أن تستخدم هذه صيغة الترجمة القصيرة. تتجاهل المعمارية عددًا محدودًا من البتات في هذه الصيغة وبالتالي تكون متاحة لتستخدمها البرمجيات مع عدم احتمال حدوث تعديلات كبيرة. يعتمد جدول الصفحات الخطي linear page-table على فكرة حجم الصفحة الثابت، ويُعَد دعم أحجام الصفحات المتعددة مشكلةً لأنه يعني أن ترجمة صفحة وهمية معينة لم تَعُد عند إزاحة ثابتة، ولكن يمكن حل هذه المشكلة من خلال احتواء كل منطقة من المناطق الثمانية في فضاء العناوين -كما هو موضّح في الشكل "رسم توضيحي للمناطق ومفاتيح الحماية في معالج إيتانيوم"- على جدول VLPT منفصل يربط عناوين تلك المنطقة فقط. يمكن إعطاء حجم الصفحة الوهمية لكل منطقة، حيث تُخصَّص منطقة واحدة لصفحات أكبر (باستخدام مخزن HugeTLB في لينكس) ولكن لا يمكن استخدام أحجام صفحات متعددة ضمن المنطقة الواحدة. جدول التعمية الوهمي Virtual Hash Table يمكن أن يكون استخدام مدخلات مخزن TLB لمحاولة تقليل تكاليف إعادة تعبئته -كما هو الحال مع جدول SF-VHPT- مقايضة فعّالة أو يمكن ألّا يكون كذلك. يطبّق معالج إيتانيوم جدول صفحات مُعمَّى hashed page-table مع إمكانية خفض تكاليف مخزن TLB، حيث يعمّي المعالج في هذا المخطط عنوانًا وهميًا للعثور على إزاحة في جدول مجاور. يُعَد جدول الصفحات الخطي الذي ناقشناه سابقًا جدول صفحات مُعمَّى باستخدام تعمية Hash مثالية لن ينتج عنها تضاربٌ أبدًا، ولكن يتطلب ذلك مقايضة غير عملية لمناطق ضخمة من الذاكرة الحقيقية المتجاورة. يزيد تقييد متطلبات الذاكرة لجدول الصفحات من احتمال حدوث تضاربات عند تعمية عنوانين وهميين إلى الإزاحة نفسها. تتطلب الترجمات المتضاربة مؤشر سلسلة Chain Pointer لإنشاء قائمة مترابطة من المدخلات البديلة الممكنة. يتطلب تمييز المدخلة الصحيحة في القائمة المترابطة وسمًا Tag مشتقًا من العنوان الوهمي الوارد. تؤدي المعلومات الإضافية المطلوبة لكل مدخلة ترجمة إلى ظهور اسم بديل بصيغة جدول VHPT الطويلة -أو LF-VHPT اختصارًا. تنمو مدخلات الترجمة إلى 32 بايتًا كما هو موضح على الجانب الأيمن من الشكل "صيغ مدخلة PTE في معالج إيتانيوم". الميزة الرئيسية لهذه الطريقة هي أن جدول التعمية العام يمكن تثبيته باستخدام مدخلة TLB واحدة. تشترك جميع العمليات في الجدول، لذا يجب أن ينمو حجمه بطريقة أفضل من صيغة SF-VHPT، إذ تتطلب كل عملية أعدادًا متزايدة من مدخلات صفحات جدول VLPT في مخزن TLB. لكن تكون المدخلات الأكبر أقل ملاءمة للذاكرة المخبئية، إذ يمكننا ملاءمة أربعة مدخلات ذات صيغة قصيرة بحجم 8 بايتات مع كل مدخلة ذات صيغة طويلة بحجم 32 بايت. يمكن أن تساعد الذواكر المخبئية الكبيرة جدًا الموجودة على معالج إيتانيوم في تخفيف هذا التأثير. تتمثل إحدى مزايا صيغة SF-VHPT في أن نظام التشغيل يمكنه الاحتفاظ بالترجمات في جدول صفحات هرمي، ويمكنه ربط الصفحات الورقية في هذه البنية الهرمية مباشرةً مع جدول VLPT مع الاحتفاظ بصيغة الترجمة العتادية. بينما يجب على نظام التشغيل باستخدام صيغة LF-VHPT إما استخدام جدول التعمية بوصفه مصدرًا أساسيًا لمدخلات الترجمة أو الاحتفاظ بجدول التعمية بوصفه ذاكرة مخبئية لمعلومات الترجمة الخاصة به. يُعَد الاحتفاظ بجدول التعمية بصيغة LF-VHPT بوصفه ذاكرة مخبئية دون المستوى الأمثل إلى حد ما بسبب زيادة الحِمل في مسارات الأخطاء الأساسية في الوقت المناسب، ولكن تُكتسَب الفوائد من الجدول الذي يتطلب مدخلة واحدة فقط في مخزن TLB. ترجمة -وبتصرُّف- للقسمين Hardware Support و Hardware support for virtual memory من فصل Virtual Memory من كتاب Computer Science from the Bottom Up لصاحبه Ian Wienand. اقرأ أيضًا المقال التالي: كيف تنشئ ملفا قابلا للتنفيذ Executable File من شيفرة برمجية مصدرية المقال السابق: دعم عتاد الحاسوب للذاكرة الوهمية  Virtual Memory نظرة عميقة على تسلسل الذواكر الهرمي والذاكرة المخبئية في معمارية الحاسوب تعرف على نظام العد الثنائي Binary أساس الحوسبة