برمجة مترجم و نظام تشغيل معا

لم ارى نظام تشغيل يبداء تطويرة على نفسة (شى منطقى) .

اعتقد ان بداية تطويرة تكون على منصة اخرى مكتملة ويترجم بمترجم مكتمل يعمل مع نظام تشغيل مبنى ويعمل .

اقتباس

مثلا مترجم لغة السى يحتاج على الأقل لدوال حجز و تحرير الذاكره و اللتان بدورهما تستخدما دوال حجز و تحرير الذاكره بنظام التشغيل

بداية, يقوم صناع نظام التشغيل بكتابة النواة على أي نظام تشغيل باستخدام مترجم معين. يقومون بترجمة النواة cross-compile لمنصة معينة. هذه هي الفكرة ببساطة. النواة نفسها يمكن أن تحتوي على kernel memory manager و جميع الاحتياجات الضرورية لعمل abstractions في النواة نفسها. ستجد مثلاً أن معظم دوال مكتبة C القياسية موجودة في Linux kernel. القضية أنه يجب أن تملك مترجم يستطيع ترجمة الـ source code للمنصة التي تريد النواة أن تعمل عليها. عندما تستقر النواة, تقوم بعمل ترجمة cross-compile "للمترجم نفسه". لا تقم بالخلط بين عملية الترجمة و الربط. عملية الترجمة هي عملية إنتاج كود. هذا الكود بعد ذلك يمكن أن تقوم بعمل إطار له ليعمل في أي بيئة أي نظام تشغيل(بالطبع الكود مترجم لمعالج معين فقط). خلال عملية الربط, يمكن على سبيل المثال, أن تقوم بعمل format للـ executable format لكي يقوم الـ loader بقبول البرنامج. لاحظ أن المترجم الذي تمت عمل cross-compile له سيتم عمل linking له حسب شروط النظام الجديد.

بمجرد حصولك على أول نسخة مترجمة من المترجم على النواة, يمكن بعد ذلك التطوير على النظام.

تحياتي...

معذره أخى خالد لم أفهم الشرح جيدا.

اقتباس

القضية أنه يجب أن تملك مترجم يستطيع ترجمة الـ source code للمنصة التي تريد النواة أن تعمل عليها

هل تقصد وجود back-end يستطيع انتاج الـ object code لمنصه معينه ؟

إن أفترضت أنك تقصد هذا فحتى الـ object code الناتج يأخذ هيئة معينه فمثلا داخل ويندوز يأخذ هيئة PE-COFF اما فى الـ linux يأخذ ELF و داخل ماكنتوش يكون Mach-o و هكذا و بالتالى حتى الـ object code الناتج لابد من تعديل الـ linker ليتناسب معه حتى يمكن إنتاج الملف التنفيذى الجديد الخاص بنظام التشغيل.

اقتباس

عندما تستقر النواة, تقوم بعمل ترجمة cross-compile "للمترجم نفسه"

إيه المقصود بـ cross-compile للمترجم من النواه؟

أهلاً محمد,

حتى يكون الكلام واضحاً, معلوماتي ضحلة في المجال و لكن مالدي لا أكثر و لا أقل :)

اقتباس

هل تقصد وجود back-end يستطيع انتاج الـ object code لمنصه معينه ؟

أي مترجم محترم, سيقسم عملية إنتاج الكود إلى خطوتين. الخطوة الأولى سيتم فيها إنتاج Intermediate Code و الخطوة الثانية هي إنتاج Platform-Specific Code. يعتمد تعريفك للـ back-end حينها على أي قسم تقصد. غالباً, المترجم له بضعة platform-specific back-ends. مترجم كـ GCC يعمل تقريباً في كل مكان! المترجم نفسه المكتوب بـ C, كلما أراد شخص استخدامه على منصة مستحدثة يقوم بكتابة الـ back-end فقط و الباقي جاهز للعمل. كيف يقوم هؤلاء بنقل gcc للعمل على أنظمتهم؟

بداية, ستقوم بكتابة back-end لتحويل الـ Intermediate Code إلى لغة Assembly الخاصة بمنصتك, أو بالتحويل مباشرة إلى binary representation إذا لم يكن هناك Assembler و هذا نادر الحدوث. ثم تقوم بكتابة الكود الذي تريده بلغة مثل C, و تقوم بترجمته إلى كود يعمل على منصتك. في هذه الحالة, سيقوم gcc بإنتاج object files باستخدام الـ back-end التي قمنا بكتابتها في البداية. هذه الـ object files ليست إلا وصفاً للكود الناتج, بمعنى أنها Intermediate Format و يمكنك تخيلها على أنها ملف XML يصف لك بداية الكود و نهايته, و بكل تأكيد الكود نفسه و ماهي البيانات التي يتضمنها الكود و ماهي القيم الثابتة و كم حجم الذاكرة التي يحتاجها الكود ضمنياً و خلافه من المعلومات الـ static بالإضافة طبعاً لمعلومات حول الدوال التي تم مناداتها و ليست موجودة في الـ module نفسه. الخطوة التالية, هي كيف نقوم بتشغيل ذلك الكود على المنصة التي نريدها؟

إما أن تكون المنصة embedded, و تقوم بنقل البرنامج باستخدام serial port مع hardwired logic أو code-in-rom أو أي طريقة لوضع البرنامج في ذاكرة الحاسب و من ثم تقوم بأمر المعالج لكي يقوم ببدء العمل. في هذه المرحلة, نحن لا نتكلم عن كيفية حصول هذا الأمر, و لكن ماذا يحصل بشكل عام. قد تكون المواصفات الخاصة بالمنصة تقتضي أن البرنامج يجب أن يبدأ من عنوان معين في الذاكرة, و أن العناوين الفلانية تستخدم كـ Mapped IO ports و أن هناك register معين لحمل كذا. الطريقة التي قمنا باستخدامها لنقل الكود لا تهم كثيراً, و لكن الذي حصل في هذه النقطة هو أننا قمنا بأخذ الـ object file و حولناه إلى الصيغة التي نريدها, أو بعنى أصح إلى executable بدلاً من description. في منصات أقوى, كالحاسبات الشخصية, أنظمة التشغيل تتضمن loader و هذا الجزء من نظام التشغيل يتطلب format معين للكود لكي يعمل و هذه نفس الفكرة السابقة غير أننا قمنا بتحويل الـ object files عن طريق برنامج آخر بدلاً من hardware أو code مطبوع في rom.

اقتباس

إيه المقصود بـ cross-compile للمترجم من النواه؟

ما قلته هو:

اقتباس

عندما تستقر النواة, تقوم بعمل ترجمة cross-compile "للمترجم نفسه"

بمعنى, أنك لو كنت تعمل على embedded system فأنت لن تحتاج إلى مترجم يعمل على المنصة نفسها. لأن المنصة ربما تقوم بتشغيل ساعة يد, و في هذه الحالة المنصة ليست معدة للتطوير عليها أصلاً(هناك تفاصيل كثيرة عن كيفية القيام بـ remote-debugging). و لكن في حالة نظام كـ linux, فالأمر مختلف لأنك تحتاج إلى أن تطور برامجك على النظام نفسه في أغلب الأحوال. لذلك بمجرد استقرار النظام و صلاحيته و اكتمال أجزاءه, تقوم بترجمة source code المترجم باستخدام نفس المترجم. بالطبع لابد أن تكون كتبت المترجم نفسه بلغة portable كلغة C و و لا تنسى كتابة loader لنظام تشغيلك! عندما ترجمنا المترجم نفسه, نتج لنا object files هذه الـ object files يمكن أن نقوم بتحويلها إلى الـ format الخاص بالـ loader الذي يعمل في نظامك إما يدوياً أو عن طريق cross-linker! بمجرد حصولنا على نسخة تعمل من المترجم و الـ linker على النظام الجديد, أصبح بإمكاننا الترجمة و الربط على النظام نفسه.

نقاش جميل,

تحياتي...

اقتباس

يعتمد تعريفك للـ back-end حينها على أي قسم تقصد.

كما قلت انت إنتاج Platform-Specific Code.

من كلامك استنتج أن بناء كود نظام التشغيل يتلخص فى عدة خطوات اذكرها كالتالى: (بإفتراض ان نظام التشغيل موجهه لـ x86 و المترجم المستخدم هو مترجم انتل)

1 - يتم بناء كود نظام التشغيل بإستخدام مترجم انتل لإنتاج الـ Object Code - الـ OpCodes

2 - يتم اعداد الـ linker الخاص بنظام التشغيل الجديد و يتم تمرير الـ object code له لينتج الملفات التنفيذيه لنظام التشغيل.

3 - يتم إعداد كود الـ boot sector و يتم وضعه فى المكان المخصص له حتى يستطيع استدعاء نظام التشغيل ليقوم بتحميل الـ executable loader و من ثم يبدء عمله.

4 - يتم بناء كود المترجم بإستخدام مترجم انتل للحصول على الـ object code و من ثم تمريره للـ linker للحصول على النسخه التنفيذيه من المترجم و الذى سيقوم الـ linker بعمل resolve للدوال المستخدمه به لما يناسبها داخل الكرنل.

5 - الأن يمكن ترجمة كود نظام التشغيل الجديد بإستخدام المترجم من داخل نظام التشغيل الجديد.

أليس كذلك؟

استطعت اختصار الموضوع و شرحه أفضل مني يا أخ محمد :lol:

طبعا الموضوع قديم جدا

لكن بصراحة جميع مواضيع الاخ محمد علاء تعجبني شخصيا واحبها جدا (قد يكون بسبب حبي الكبير لمحمد ) :lol: :lol: او يمكن ان يكون هذا الامر لانه الوحيد تقريبا فى المنتدي التى اهتماماته مشابهة لي

المهم أننى حقا أبحث فى هذا الامر بشكل جدي

بغض النظر أننى لم اجد جوابا او حلا شافيا لآنني احتاج الامر بشكل عملي واحيانا اضطر الى قراءة عشرات الصفحات وفى النهاية لا اخرج الا بمعلومة بسيطة واحيانا لا توجد من الاساس :lol:

لكن لم اتعمق كثيرا فى كتابة الكثير من انظمة التشغيل وتجاربي ليست كتجارب مثلا من يعمل فى تطوير الانظمة فى الشركات الكبري

لكن هذا الامر يعتمد بشكل كبير على الخبرة

فهذا حدث بالضبط تقريبا مع تطور C و Unix : فقد تم استحداثهما جنبا إلى جنب. كما أنه من قام بالتطوير اكتسبوا خبرة في كتابة نظام التشغيل ، وعلموا ما أرادوا من المترجم الذين يريدون كتابته. كما تحسنت بيئة مترجم وrun-time، وجدوا انهم يريدون الميزات الجديدة في نظام تشغيل.

لذا فأنه من الممتع احيانا قراءة تاريخ تطور اليونكس فان به الكثير من الحديث عن هذا الامر

وانا مضطر للخوض فى هذا الامر حاليا وسوف ابدأ بدراسة BCPL b

فلغة السى بنيت اعتمادا على الكثير من خصائصها

وتحياتى لكم وان عرفت اى جديد بخصوص الموضوع سأذكره ان شاء الله