كتابة البرامج الثابتة:التجمع أو مستوى عال؟
https://stackoverflow.com/questions/452139
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
متعلق ب:
إذا كنت تكتب رمزًا لـ a متحكم هل هناك فرق حقيقي إذا كنت تكتب بلغة التجميع أو لغة C أو أي لغة أخرى عالية المستوى؟إذا كتبت كود C، كيف يمكنك تجميعه؟
شكرًا
المحلول
عدة تعليقات:
1) بالتأكيد لا التجميع ما لم تكن قيود الأداء أو التحسين تبرر ذلك.المقاييس التالية تمر عبر السقف مع التجميع:
- الوقت لترميزه
- الوقت لتصحيح ذلك
- الوقت لاختباره
- الوقت لتوثيقها
- حان الوقت لتعرف (بعد عام واحد) ما كنت تفعله عندما قمت بترميزه
- فرص ارتكاب الخطأ
2) أفضّل أن يكون C++ بدلاً من C لتغليف مساحة الاسم الخاصة به وتسهيله وقت الترجمة الممارسات الموجهة للكائنات.لدى لغة C الكثير من الفرص للمتغيرات العامة وتصادمات مساحة الاسم.(سيكون استخدام Java في الوقت الفعلي أمرًا رائعًا ولكن من وجهة نظري فإن متطلباتها لا تزال مرتفعة جدًا)
أو بالأحرى مجموعة فرعية من C++:استبعاد الاستثناءات، والوظائف الافتراضية، وتحديد نوع وقت التشغيل، وكذلك تخصيص الذاكرة الديناميكية في معظم الحالات - بشكل أساسي أي شيء يتم تركه غير محدد في وقت الترجمة، لأنه سيتطلب عادةً الكثير من الموارد الإضافية أثناء وقت التشغيل.هذا هو "سخام" C++.
لقد استخدمت كلاً من مجمعي TI وIAR لـ C++، ولوحدات التحكم الدقيقة TMS320 وMSP430 (على التوالي) ومع إعدادات التحسين المناسبة، فإنهم يقومون بعمل رائع في تقليل الحمل الذي قد تتوقعه من C++.(خاصة إذا كنت تساعدها عن طريق الاستخدام الحكيم لل inline الكلمة الرئيسية)
لقد استخدمت أيضًا قوالب لبعض فوائد وقت الترجمة الخاصة بها والتي تعزز إعادة استخدام التعليمات البرمجية بشكل جيد:على سبيل المثالكتابة ملف كود مصدر واحد للتعامل مع CRCs 8 بت و16 بت و32 بت؛و تعدد الأشكال في وقت الترجمة للسماح لك بتحديد السلوك المعتاد للفصل الدراسي، ثم إعادة استخدامه مع تجاوز بعض وظائفه.مرة أخرى، كان لدى مترجم TI حمل منخفض للغاية مع إعدادات التحسين المناسبة.
لقد كنت أبحث عن مترجم C++ لـ Microchip PICs؛الشركة الوحيدة التي وجدتها تنتج واحدة هي IAR.لقد كان ($$$ عائقًا ولكنني آمل أن أشتري نسخة في وقت ما) تعد برامج التحويل البرمجي Microchip C18/C30 جيدة جدًا ولكنها لغة C وليست C++.
3) تحذير محدد حول تحسين المترجم:يمكن/سوف يجعل تصحيح الأخطاء أمرًا صعبًا للغاية؛غالبًا ما يكون من المستحيل اتباع خطوة واحدة عبر كود C/C++ المحسّن وقد تعرض نوافذ الساعة الخاصة بك متغيرات ليس لها علاقة بما تعتقد أنه يجب أن تحتوي عليه مع التعليمات البرمجية غير المحسنة.(سيحذرك مصحح الأخطاء الجيد من أن متغيرًا معينًا قد تم تحسينه من الوجود أو في سجل بدلاً من موقع الذاكرة.العديد من مصححات الأخطاء لا تفعل ذلك.>:(
كما سيسمح لك المترجم الجيد باختيار/اختيار التحسين على مستوى الوظيفة من خلال #pragmas.تتيح لك العناصر التي استخدمتها فقط تحديد التحسين على مستوى الملف.
4) ربط رمز C بالتجميع:وهذا عادة ما يكون صعبا.أسهل طريقة هي إنشاء وظيفة كعب روتين تحتوي على التوقيع الذي تريده على سبيل المثال. uint16_t foo(uint16_t a, uint32_t b) {return 0; }, ، أين uint16_t = اختصار غير موقع، وعادةً ما نجعل عدد البتات واضحًا.ثم قم بتجميعه وتحرير التجميع الذي ينتجه (فقط تأكد من ترك أجزاء البدء/الخروج من الكود) و احرص عدم ضرب أي سجلات دون استعادتها بعد الانتهاء.
عادةً ما يواجه التجميع المضمن مشكلات إلا إذا كنت تفعل شيئًا ما جداً بسيطة مثل تمكين/تعطيل المقاطعات.
النهج الذي يعجبني أكثر هو بناء جملة المترجم/"ASM الممتد".يعتمد مترجم لغة C الخاص بشركة Microchip على مترجم GNU C ويحتوي على "ASM الموسعة" والذي يتيح لك ترميز أجزاء التجميع المضمنة ولكن يمكنك إعطائها الكثير من التلميحات لإخبارها بالسجلات/المتغيرات التي تشير إليها وسوف تتعامل مع جميع عمليات حفظ/استعادة السجلات للتأكد من أن رمز التجميع الخاص بك "يعمل بشكل جيد" مع C .لا يدعم مترجم TI الخاص بـ TMS320 DSP هذه البرامج؛لديها مجموعة محدودة من الجوهرية التي لها بعض الاستخدام.
لقد استخدمت التجميع لتحسين بعض أكواد حلقة التحكم التي يتم تنفيذها بشكل متكرر، أو لحساب sin() وcos() وarctan().لكن بخلاف ذلك سأبقى بعيدًا عن التجمع وألتزم بلغة عالية المستوى.
نصائح أخرى
توفر معظم الشركات المصنعة لوحدات التحكم الدقيقة نوعًا من المترجم المتقاطع حيث يمكنك تجميع التعليمات البرمجية على جهاز الكمبيوتر الخاص بك ثم نقلها إلى وحدة التحكم الدقيقة.
لماذا ج؟
من مميزات لغة C أن الكود الخاص بك سيكون أسهل في النقل إلى وحدات التحكم الدقيقة الأخرى في المستقبل.لقد أظهر تاريخ الحوسبة أن التعليمات البرمجية عادةً ما تدوم أكثر من تطبيقات الأجهزة.
الميزة الثانية هي هياكل التحكم (إذا، ل، بينما) التي تجعل التعليمات البرمجية أكثر قابلية للقراءة والصيانة.
لماذا لغة التجميع؟
يمكنك تسليم التحسينات الحرفية.
الحكم
كما هو الحال غالبًا مع هذا النوع من الأسئلة، تعتمد المفاضلات بشكل كبير على الاستخدام المحدد.
كن على علم أنه من الممكن في كثير من الأحيان المزج بين الاثنين عن طريق إجراء استدعاءات التجميع داخل كود C، حتى تتمكن من العثور على التوازن المناسب لمشروعك.
محددة لأجهزة الموافقة المسبقة عن علم
هو - هي يبدو أنه ليس لديك خيار دول مجلس التعاون الخليجي مع معظم أجهزة الموافقة المسبقة عن علم.من ناحية أخرى، كما أشار أحد المعلقين، فإن برنامج التحويل البرمجي Microchip C30 لـ 16 بت PIC24 وdsPIC33 هو gcc.
الموافقة المسبقة عن علم أيضًا غير مدعومة من قبل SDCC.
معلومات جديدة:وفقًا للتعليق، لدى SDCC دعم عملي للموافقة المسبقة عن علم.
هناك بعض المصادر المفتوحة الأخرى خيارات, ، لكن ليس لدي خبرة معهم.
من المحتمل أن يكون الخيار الأفضل هو البرمجة بلغة C، وفي الحالات القليلة جدًا التي تحتاج فيها إلى التحسين اليدوي ويمكنك القيام بعمل أفضل من المترجم، يجب عليك ترميز التجميع في ملفات C الخاصة بك.
يعد ترميز التجميع شيئًا من الماضي بالنسبة لأجهزة الكمبيوتر، ولكنه وثيق الصلة جدًا بالجزء المضمن.
يختلف تجميع الكتابة في الجزء المضمن عن تجميع الكتابة على أجهزة الكمبيوتر.يعد مترجمو أجهزة الكمبيوتر الشخصية "أفضل من البشر" في إنشاء تعليمات محسنة.غالبًا ما تحتوي الأنظمة المضمنة على بنيات غريبة، كما أن المترجمات المُحسّنة الخاصة بها ليست ناضجة تقريبًا مثل المترجمات المُحسّنة للكمبيوتر الشخصي.
إحدى المشكلات التي واجهتها أثناء كتابة التجميع لوحدة التحكم الدقيقة هي الحاجة إلى ذلك جداً كن حذرًا بشأن كيفية وضع التعليمات البرمجية الخاصة بك.إن وجود جدول انتقال يتجاوز حدود الذاكرة، والتسبب في انتقال التعليمات البرمجية الخاصة بك إلى أماكن غريبة حقًا هو أمر مزعج إلى حد ما.الترميز في لغة C، يقوم المترجم بتغطية تلك القاعدة لك.
سأذهب بالتأكيد مع C.إنه أسرع ويخلق برامج أكثر موثوقية.الجمعية ليس لديها سوى القليل لتقدمه وفي مناسبات نادرة.ضع في اعتبارك أنه في C:
- ستتمكن بسهولة من نقل التعليمات البرمجية من الأنظمة الأساسية الموجودة، حتى من أجهزة الكمبيوتر الشخصية.
- يمكنك التطوير بلغة عالية المستوى دون المساس بسرعة التنفيذ أو حجم الكود.بشرط توافر مترجم عالي الجودة (هناك العديد من الاختيارات لـ PIC18)، فمن المرجح أن يكون ذلك أفضل مع لغة C مقارنة بالتجميع المصنوع يدويًا.
- من الأسهل بكثير تصحيح التعليمات البرمجية واختبارها وصيانتها.ينتج C رمزًا أكثر موثوقية.
شيء آخر له علاقة على وجه التحديد بـ PIC18.لن تضطر إلى التعامل مع بنية الموافقة المسبقة عن علم (PIC) غير البديهية وأشياء مثل بنوك الذاكرة.
لقد كانت لدي تجربة جيدة مع IAR المترجمين C لـ 8051 في الماضي.
لقد كان نهجي الأخير دائمًا هو: -
اكتبه بلغة C باستخدام مترجم تحسين جيد، وعندها فقط إذا كانت هناك مشكلة في الحجم أو السرعة، ففكر في إعادة كتابة أجزاء معينة في المجمع.
ومع ذلك، منذ أن اتخذت هذا النهج لم أفعل ذلك أبدًا ضروري لكتابة سطر واحد من المجمع ...
الذهاب ل ج!
لقد عملت لدى شركة تصنيع CE كبيرة.آخر مرة رأيت فيها التجميع كان حوالي عام 1996 في بعض إجراءات خدمات المقاطعة الصغيرة لخوارزميات فك تشفير RC5 وRC6 وضبط التلفزيون.بعد ذلك، يتم استخدام c وC++ دائمًا (الفئات المستخدمة فقط، ولا توجد stl أو استثناءات أو rtti).لدي تجارب جيدة مع مترجم KEIL القديم لـ 8051 ومع مترجم Greenhills (MIPS) ومجموعة أدوات VxWorks (المعتمدة على PowerPC).
كما يقول رودي، اكتب أولاً بلغة C، وقم بتحسين التجميع لاحقًا (إذا لزم الأمر).
يمكن أن يكون التجميع أسرع في كثير من الحالات؛عندما تكون على سطح المكتب، يميل المترجمون إلى التحسين إلى درجة أن التجميع اليدوي نادرًا ما يكون ضروريًا، ولكن في عالم جامعة كاليفورنيا، غالبًا ما يكون ذلك ضروريًا.أيضًا، إذا كنت بحاجة إلى كتابة إجراءات معالجة المقاطعة وأشياء من هذا القبيل، فغالبًا لا يمكنك القيام بذلك في لغة C.
أما بالنسبة للتجميع، فابحث في Google عن مترجم C لهدفك.
بالتأكيد C، إلا عندما
ذاكرة البرنامج محدودة للغاية.لنفترض أنه بعد التحسين اليدوي المضني لتعليمات التجميع الخاصة بك، فإنك تمكنت من ملاءمة برنامجك في 1024 بايت من Flash، مع 0 بايت متبقي.في هذه الحالة لن يكون أي مترجم C مفيدًا.
تريد أن يكون لديك التحكم المطلق في التوقيت.إذا كان أي قدر من زمن انتقال المقاطعة طويلاً جدًا، فسيتعين عليك الاعتماد على المجمّع.
المشكلة هذه الأيام هي أن المضمن يمكن أن يكون أي شيء بدءًا من ATTiny المزود بـ 6 دبابيس وبضعة بايت من ذاكرة الوصول العشوائي (RAM) إلى SBC متعدد النواة الذي يشغل نظام تشغيل مضمنًا من شأنه أن يضع أجهزة الكمبيوتر المكتبية الخاصة ببعض الأشخاص في حالة من العار.
على هذا النحو، فإن اختيار بيئة اللغة/التطوير يجب أن يأخذ في الاعتبار مدى الكفاءة التي تحتاجها مقابل مدى تعقيد النظام.
أولاً - تعمل لغة C في كل مكان وتتدرج بشكل جيد، وكلما تقدمت في المستوى الأعلى كلما انتهى بك الأمر إلى الاتصال بالمكتبات الخارجية وما إلى ذلك.للتعامل مع التعقيد.
بالنسبة للميكرو الصغيرة جدًا (قياس الفلاش/ذاكرة الوصول العشوائي بالبايت) فمن الأفضل استخدام ASM، وعندما تصل إلى نطاق كيلو بايت، يمكن استخدام لغة C أو أي من اللغات التقليدية الأخرى لأنك لا تحتاج إلى حساب كل بايت.بمجرد أن يكون لديك ميغابايت للعب بها، سيكون لديك القدرة، ومن المحتمل بشكل متزايد، الحاجة إلى استخدام نظام RTOS للعناية بكل شيء وتقليل وقت التطوير.بحلول الوقت الذي يكون لديك فيه جهاز، يمكنك تشغيل نظام تشغيل كامل عليه، وربما يمكنك تجريد نفسك من الجهاز وكتابة كل شيء في خلية مبطنة مثل Java أو شيء من هذا القبيل دون القلق كثيرًا بشأن مدى الإسراف الشديد في كل ذلك وكيف لم يعد مبرمجًا حقيقيًا بعد الآن;)
الاستثناء لما سبق هو عندما تحتاج إلى كل الأداء الذي يمكنك استخراجه من الأجهزة، وعند هذه النقطة قد تحتاج إلى إسقاط مستوى أو اثنين للحفاظ على كفاءة الأمور.
هذا هو بيت القصيد إذا كنت تستخدم لغة C، فيمكنك تحسينها لاحقًا، ولن أستخدم أي شيء آخر غير لغة C أو المجمّع (ليس لغة C++، وما إلى ذلك).
المفتاح هو مجموعة تعليمات المتحكم الدقيق إذا كنت تستخدم الموافقة المسبقة عن علم أو حتى 8051 سأستخدم المجمع فقط.إذا كان برنامجًا صديقًا للمترجم مثل الذراع أو avr أو msp430، فاستخدم لغة C لحفظ بعض الكتابة ولكن من المحتمل أن يكون لديك بعض الإجراءات في المجمع لأسباب مختلفة.وبالمثل، ربما ترغب في تجنب مكتبة C، فحتى مكتبة newlib يمكن أن تكون ضخمة جدًا، فاقترض التعليمات البرمجية أو الأفكار منها ولكن لا تقم فقط بربط واحدة بها.أوه، لنعد إلى السؤال، انظر إلى برامج التحويل البرمجي المتوفرة للغة C للهدف، ومرة أخرى، لن تواجه أية مشكلات.من المحتمل أن يكون MSP على ما يرام أيضًا.فقط لأن Keil أو Iar سيبيعان لك مترجمًا لا يعني أنه يجب عليك شرائه أو استخدامه، فإن الناتج المدفوع مقابل المترجمين المجانيين يمكن أن يكون مروعًا.يجب أن تكون على دراية جيدة بالـ asm على أي حال وأن تفحص المخرجات (ربما يتعين عليك كتابة أداة تفكيك للقيام بذلك).
خلاصة القول (خلاصة أخرى)، لا توجد إجابة عالمية (حسنًا، تجنب أي شيء أعلى من C فهو إجابة عالمية) يعتمد الأمر دائمًا على النظام الأساسي، وما هي مواردك، وما هي مهمتك، وما هي متطلبات الأداء، وما هي متطلبات قابلية النقل؟ هي (إذا كانت مضمنة حقًا في وحدة تحكم دقيقة، فإن الكثير منها بحكم التعريف غير محمول) ما هي المترجمات، ومصححات الأخطاء، وjtag، وما إلى ذلك المتاحة، حتى بقدر ما يمكن أن يكون نظام التشغيل المضيف الذي تقوم بتطويره عاملاً كبيرًا.
هناك وقت آخر قد تكون فيه الكتابة في التجميع ضرورية:إذا كنت بحاجة إلى إجراء بعض اختبارات ذاكرة الوصول العشوائي ذات المستوى المنخفض أو ما شابه ذلك، الأمر الذي يتطلب تحكمًا مطلقًا في مكان تخزين البيانات.
على سبيل المثال، البرامج التي تؤكد سيل-2 (مستوى سلامة السلامة) وما فوق قد يتطلب إجراء فحوصات مستمرة على ذاكرة الوصول العشوائي (RAM)، من أجل اكتشاف أي تلف محتمل في البيانات.لا يمكن تغيير منطقة ذاكرة الوصول العشوائي (RAM) التي تقوم بفحصها أثناء فحصها، وبالتالي فإن كتابة الاختبار في المجمّع يسمح لك بالتأكد من صحة ذلك، على سبيل المثال عن طريق تخزين أي متغيرات محلية في سجلات محددة أو في منطقة أخرى من ذاكرة الوصول العشوائي (RAM) .وهذا سيكون صعبا، إن لم يكن مستحيلا، في C.
يمكن أيضًا كتابة كود بدء التشغيل الذي يقوم بصفر ذاكرة الوصول العشوائي (RAM) وتهيئة المتغيرات الثابتة غير الصفرية في المجمّع لنفس المكتوب، على الرغم من توفير هذا النوع من التعليمات البرمجية عادةً.
إذا كنت تكتب تعليمات برمجية تعتمد بشكل كبير على الأجهزة الطرفية الخاصة بالجهاز، ولا توفر سلسلة الأدوات التي تستخدمها العناصر الجوهرية اللازمة لاستخدامها بكفاءة (مثل برنامج التحويل البرمجي Freescale DSP563CC السيئ)، فاستخدم التجميع.
بالإضافة إلى ذلك، أعتقد أن القواعد غير المكتوبة لاستخدام التجميع مقابل استخدام التجميع.اللغات عالية المستوى هي تقريبًا نفس اللغات المستخدمة في تطوير برامج سطح المكتب:حافظ على نظافة التعليمات البرمجية وقابليتها للصيانة وتحسين التعليمات البرمجية الساخنة باستخدام لغة الآلة.
تعتبر التعليمات البرمجية بلغة المجمع سريعة جدًا وصغيرة الحجم، ولكن التعليمات البرمجية المكتوبة بلغة المجمع ليست تعليمات برمجية قابلة لإعادة الاستخدام.تعد ميزة إعادة الاستخدام للكود ميزة أكثر أهمية لتصميم البرامج.على سبيل المثال، إذا كان لديك رمز مشروع مجمع لمعالج x86، فيمكن استخدامه فقط لمعالج x86، وليس لمعالج ARM.ولكن إذا كان لديك رمز مشروع C/C++ لمعالج x86، فيمكنك استخدام هذا الرمز لمعالج ARM.لذلك، فمن الأفضل تجنب المجمع لتطوير البرمجيات.
إنه لأمر سيء للغاية أن أحداً لم يذكر Forth أو Scheme حتى الآن.يمكن أن يكون كلاهما مناسبًا للبيئات الصغيرة، ويمكن أن يوفر مكاسب إنتاجية مذهلة.
عادي C أو باسكال، Modula2.ولكن نظرًا لتوفر المترجم فهذا يعني أن C.
تعتبر الإضافات في C++ وما شابهها مثيرة للاهتمام فقط لأسباب تتعلق بالأسلوب، نظرًا لأن التخصيص الديناميكي وحجم البرنامج عادة ما يكونان محدودين للغاية.
كما يمكن أن يكون وقت التشغيل الأكثر تعقيدًا أمرًا مؤلمًا إذا أصبحت تطبيقاتك ضيقة.
يمكن أن يكون المجمع مفيدًا أيضًا، ولكن فقط إذا كنت تبيع كميات هائلة حقًا، والبرامج الثابتة الأصغر تعني شريحة أصغر وأرخص (فلاش أقل) وحجم البرنامج يمكن التحكم فيه (اقرأ:هناك احتمال أن تحصل عليه خاليًا من الأخطاء في الوقت المناسب)
