+1! إن صدأ Avr المدمج في المترجم المناسب سيكون مفيدًا للغاية. يكاد يكون خاليًا من الأخطاء الآن.

ليست خالية تماما من الحشرات :)

سوف أقوم بتحديث الوصف ليشمل بعض المعلومات حول حالة أخطاء الكتابة الخلفية

تقريبا على الرغم من 😄. فقط زوجين للذهاب

بشكل عام ، نحن نرحب تمامًا بالمنصات المنبع في الصدأ / الصدأ طالما أنها لا تضع عبء الصيانة علينا! بعض الأفكار المحددة مما تفكر فيه:

• تلتزم LLVM بقطف الكرز في كثير من الأحيان بشكل جيد تمامًا ، وأعتقد أنكم مررتم بهذه العملية عدة مرات بالفعل :)
• الجوهر المفقود في compiler-rt أمر جيد من جانبنا ، لديك خيار تنفيذها في Rust وكذلك من خلال مشروع compiler-builtins.
• يبدو التصحيح الذي لديك جيدًا ، على الرغم من أنني أعتقد أننا نرغب في العمل أكثر من خلال مختلف #[cfg] في libcore. هل تم استبعاد هذه العناصر بسبب "أخطاء في LLVM" أم لأنها غير مدعومة في الأساس على الإطلاق على AVR؟ من الأفضل القيام بالأول من خلال "إصلاح LLVM" بطريقة ما بينما الأخير يجعل الأمور أكثر تعقيدًا.

بشكل عام ، لدينا حاليًا جميع الأنظمة الأساسية بنفس الواجهة الموحدة لـ libcore / libstd ، ولكن ليس من الواضح ما إذا كان سيظل صحيحًا مع استمرارنا في اختيار المزيد من الأنظمة الأساسية.

تبدو الرقعة التي لديك جيدة جدًا ، على الرغم من أنني أعتقد أننا نرغب في العمل أكثر من خلال مختلف # [cfg] في libcore. هل تم استبعاد هذه العناصر بسبب "أخطاء في LLVM" أم لأنها غير مدعومة في الأساس على الإطلاق على AVR؟

إنه بسبب الخلل في LLVM.

السؤال الوحيد في ذهني هو دعم الأنواع i128 / u128 - أعتقد أنه بالنسبة لـ AVR ، هذه ليست مفيدة حقًا. تم التعليق حاليًا على دعم i128 في libcore بسبب خطأ ، ولكن قد تكون هناك أخطاء أخرى غير مكتشفة نظرًا لأنه ليس مسار كود تم اختباره جيدًا ، ويمارس حقًا مخصص السجل باعتباره AVR فقط يحتوي على 32 بايت من سجلات الأغراض العامة.

لا يزال من المحتمل جدًا أن نحصل على i128 للعمل على AVR ، على الرغم من ذلك ، لا أعرف الكثير من المشكلات المحددة التي تسببها في الواجهة الخلفية.

أعتقد أن أفضل طريقة للمضي قدمًا هي اقتراح التصحيح لترجمة libcore الحقيقية مرة واحدة دون تعديل ، أو على الأقل بدون الكثير.

أعتقد أن أفضل طريقة للمضي قدمًا هي اقتراح التصحيح الحقيقي بمجرد أن يقوم libcore بالتجميع دون تعديل ، أو على الأقل بدون الكثير.

تبدو معقولة بالنسبة لي!

السؤال الوحيد الذي يدور في ذهني هو دعم أنواع i128 / u128 - أعتقد أنه بالنسبة لـ AVR ، هذه ليست مفيدة حقًا.

خوفي الرئيسي من عدم دعم i128 على AVR هو أنه سيكون له تأثير مخيف على اعتماد أعداد صحيحة 128 بت من أجل التوافق مع AVR أو الأنظمة الأساسية المضمنة الأخرى. على سبيل المثال ، إذا كانت هناك مكتبة تستخدم أعدادًا صحيحة من 128 بت ، فإن مستخدمي AVR الذين سيرغبون في استخدامها سيقدمون مشكلات لإسقاط الاستخدام. هذا قد يجعل الأعداد الصحيحة 128 بت غير "آمنة" لاستخدامها في كود Rust الذي يسعى جاهداً ليكون محمولاً ، وهو ما لا أرغب في حدوثه.

تأثير مخيف على اعتماد أعداد صحيحة من 128 بت من أجل التوافق مع AVR أو الأنظمة الأساسية المضمنة الأخرى

لا أعتقد أنها صفقة ضخمة للغاية هنا. تحتوي الأجهزة الصغيرة المدمجة بالفعل على قيود عملاقة (لا يوجد stdin / stdout ، بشكل عام لا يوجد مخصص ، وما إلى ذلك) مما يجعل من الصعب جدًا إسقاط مكتبة عشوائية. لقد علمت مؤخرًا أن برنامج AVR GCC double هو في الواقع اسم مستعار لـ float ! لا أعرف ما إذا كنا سنحتفظ بهذه الغرابة أم لا ، لكنها ستؤثر على الصناديق بأكثر من i128 .

أعتقد أنه سيكون لدينا دائمًا ميزات خاصة تُستخدم لصنع صندوق مناسب للتضمين ، تمامًا كما نفعل مع عدم وجود الأمراض المنقولة بالاتصال الجنسي.

لا يوجد stdin / stdout ، وعمومًا لا يوجد مخصص ، وما إلى ذلك.

أنت تصف النظام البيئي #![no_std] . هناك مكتبات تستهدف هذا النظام البيئي. والقاعدة العامة لهذا النظام البيئي هي أن تأخذ libcore كمعطى ، والذي يتضمن أيضًا i128 . كل هدف لا يدعم i128 له تأثير مخيف أكبر داخل هذا النظام البيئي ، لأن "حصة السوق" للهدف المضمن تكون أكبر داخل المجموعة الفرعية من نظام Rust البيئي بأكمله حيث لا تعتبر عائلة x86 لاعبًا ملائمًا للغاية .

لا أعرف ما إذا كنا سنحتفظ بهذه الغرابة أم لا ، لكنها ستؤثر على الصناديق أكثر من i128.

مثير للاهتمام! أوافق على أنه إذا كان لدينا اسم مستعار f64 إلى f32 (أو لم نوفره) ، فسيؤثر ذلك على النظام البيئي أكثر. ومع ذلك ، إذا كان بإمكاننا السعي لتحقيق الاتساق ، فلماذا لا نفعل ذلك؟ من الممكن بالتأكيد بالنسبة لنا تنفيذ i128 .

من الممكن بالتأكيد بالنسبة لنا تنفيذ i128.

بالتأكيد ، وأدركت أنني لم أذكر بوضوح أنني أعتقد أنه تنفيذ i128 لـ AVR . ومع ذلك ، فإن أي رمز يستخدم في الواقع i128 على AVR سيكون في عالم من الألم.

ومع ذلك ، إذا كان بإمكاننا السعي لتحقيق الاتساق ، فلماذا لا نفعل ذلك؟

الاتساق مع ما هو السؤال. المطابقة مع دول مجلس التعاون الخليجي ( f64 == f32 ) أو مع كل هدف صدأ آخر ( f64 ! = f32 )؟

أنت تصف النظام البيئي #! [no_std].

نعم ، وهذا هو السبب في أنني قلت "الميزات الخاصة التي يتم استخدامها لإنشاء صندوق مناسب للدمج ، تمامًا كما نفعل مع عدم وجود الأمراض المنقولة بالاتصال الجنسي." 😇

مشكلة أكبر كانت في صميم ذهني منذ أن حصلنا في الأصل على التصحيح 16 بت usize هو أنه ، بشكل أساسي ، يميل مبرمجو Rust and Rust إلى افتراض أن usize هو "الأصلي" حجم السجل. AFAIK ، هذا صحيح لجميع المنصات الأخرى التي تستهدف Rust ، ولكن ليس لـ AVR.

الاتساق مع ما هو السؤال. التوافق مع GCC (f64 == f32) أو مع كل هدف صدأ آخر (f64! = f32)؟

يشير الاسم f64 حرفياً إلى أنه يحتوي على 64 بت. إذا لم تلتزم بالاسم ، فسيصبح بلا معنى تمامًا كما هو الحال في C.

نقاط جيدة هنا ، أستطيع أن أرى القلق حول الأعداد الصحيحة 128 بت. أعتقد بالتأكيد أنه يجب دعمهم ، على الرغم من أنه لا ينبغي لنا تشجيع استخدامها. أكره أن أرى الصناديق تضطر إلى إضافة أعلام ميزة لأشياء مثل السمات الضمنية على أنواع i128 . لا ينبغي أن تكون هذه مشكلة حقًا لأنه يجب قطع جميع عناصر i128 غير المستخدمة بواسطة الرابط.

مشكلة f32 / 64 مثيرة للاهتمام. اهتمامي الرئيسي بجعل f64 في الواقع 64 بت هو أنه يعني أن C FFI يمكن أن يكون هشًا للغاية. إذا كان المطورون لا يعرفون أن AVR-GCC تستخدم مضاعفات 32 بت ، فيمكن للمكالمات عبر FFI قراءة الذاكرة غير المهيأة أو segfault.

أتخيل أنه يمكننا حل هذا بشكل أو بآخر من خلال توقع أن يستخدم المستخدمون أنواعًا من الصندوق libc بدلاً من ذلك. يمكننا إضافة وظائف خاصة بـ AVR لتعيين c_double إلى f32 . أعتقد أننا يمكن أن نتوقع بشكل معقول من الناس استخدام الصندوق libc في روابط FFI الخاصة بهم.

شيء يجب تذكره للدمج ، تحتاج إلى تحديث النوع c_int المستخدم في توقيع main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

تحرير: فتح مشكلة لهذا لأنه يؤثر على MSP430 أيضًا: https://github.com/rust-lang/rust/issues/44934

المستخدمة في التوقيع الرئيسي

mattico ربما كنت أفعل الأشياء بطريقة غريبة ، لكن لم يستخدم أي من التعليمات البرمجية الخاصة بي Rust main :

#[no_mangle]
pub extern fn main() {

والأهم من ذلك ، لا يمكننا العودة حقًا لأنه لا يوجد شيء نعود إليه . كل برنامج يحتاج إلى العمل إلى الأبد.

mattico لا يزال

أوه ، بالتأكيد ، أنا لا أعرف أن main سيؤثر علينا على الإطلاق.

shepmaster حتى في الأنظمة الأساسية غير المضمنة ، لا يهم حجم argc رئيسي نظرًا لأننا كنا قد أخطأنا طوال هذا الوقت ولم يلاحظ أحد إلا عند فحص IR. قد يكون هناك بعض أنظمة RTOS التي تستخدم نقطة دخول رئيسية قياسية لعملياتها؟ بغض النظر ، من السهل إصلاحه.

ربما استغرق الأمر نفس القدر من الوقت لإرسال إصلاح كما فعلت لكتابة هذا ، الآن بعد أن أفكر في الأمر 😄

هل هي فقط قضايا libcore التي تمنع هذا الدمج؟ فقط لكي نعرف أين يجب تركيز الجهود.

المشكلات الوحيدة التي واجهتها من libcore هي أخطاء رابط غريبة سببها لا أعرف ماذا وأيضًا أخطاء تحويل بتات 32 بت (مفقودة جوهرية على ما أعتقد). لا أعرف ما إذا كان هؤلاء يمنعون الدمج أم لا.

chocol4te: هل هي فقط مشكلات libcore التي تمنع هذا الدمج؟ فقط لكي نعرف أين يجب تركيز الجهود.

نعم - كل العمل المطلوب هنا يجب أن يتم داخل LLVM .

Restioson: المشكلات الوحيدة التي واجهتها من libcore هي أخطاء رابط غريبة سببها لا أعرف ماذا وأيضًا أخطاء تحويل بتات 32 بت (مفقودة جوهرية على ما أعتقد).

هذا لأنه تم التعليق على كل الكود الذي يجعل خنق الواجهة الخلفية لـ AVR :)

Restioson: لا أعرف ما إذا كان هؤلاء يمنعون الدمج.

ليس بشكل مباشر ، ولكن سيكون من الجيد أن يتم الإصلاح قبل دمج الواجهة الخلفية. هناك نوعان من الأخطاء المزعجة حقًا مثل هذه والتي يجب أن نفكر في إصلاحها قبل أن ندمج ، ولكن قد لا يؤديان بالضرورة إلى تعطيلها.

تم دمج dylanmckay LLVM6 https://github.com/rust-lang/rust/pull/47828 - ماذا يعني ذلك بالنسبة إلى RFC هذا؟

kellerkindt كافة المشكلات المدرجة في "المشكلات الحالية في

أنا شخصيا ما زلت أؤيد

أعتقد أن أفضل طريقة للمضي قدمًا هي اقتراح التصحيح الحقيقي بمجرد أن يقوم libcore بالتجميع دون تعديل ، أو على الأقل بدون الكثير.

على الرغم من أن الحاجة إلى تجنب إعادة التأسيس الإضافي أمر جيد.

أتساءل عن الحالة الحالية لـ Rust on AVR ، بعد مرور نصف عام على التطوير. أدير مجموعة صغيرة من مشاريع Arduino في بلدتي ، وسأحب أن أتمكن من استخدام Rust بدلاً من ذلك.

حسنًا ، أخبار جيدة!

أعتقد أن أفضل طريقة للمضي قدمًا هي اقتراح التصحيح الحقيقي بمجرد أن يقوم libcore بالتجميع دون تعديل ، أو على الأقل بدون الكثير.

هذا هو الحال الآن!

لا تحتوي شوكة avr-rust الحالية على أي تعديلات على libcore .

التعديلات المطلوبة لدعم AVR من Stock Rus هي:

• يتم الإعلان عن وظائف تهيئة الواجهة الخلفية AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} واستدعائها.
• تمت إضافة الحد الأدنى الأساسي لمواصفات هدف avr avr-unknown-unknown . يمثل هذا النموذج السلوك الافتراضي لـ avr-gcc في البناء لأدنى قاسم مشترك ما لم يتم تحديده صراحةً. بخلاف avr-gcc الذي يدعم صراحة الوسيطة -mmcu=<avr mcu name> ، لم تتم إضافة أي وسيطة سطر أوامر خاصة بـ AVR لـ AVR. هذا يعني أنه يجب كتابة ملف JSON لمواصفات الهدف المخصص لكل مشروع. هذا هو الحال بالنسبة للعديد من مشاريع Rust المدمجة.
• في الشوكة ، يتم دائمًا تجميع الواجهة الخلفية AVR LLVM وربطها في عملية دفع Rust الافتراضية وإضافتها إلى ملف config.toml.example . هل يجب تضمين AVR في Rust المنبع افتراضيًا ، أم يجب أن يكون مشتركًا أيضًا؟
• تمت إضافة منطق محدد AVR إلى المترجم عند الاقتضاء لجميع الأهداف الجديدة
• تمت إضافة اصطلاح الاتصال "avr-interrupt" . هذا يتيح extern "avr-interrupt" fn my_isr_handler() { .. } . ربما يحتاج هذا إلى المرور بعملية RFC حتى يستقر ، لكن قد أكون مخطئًا.
• دعم التجميع الشرطي على وحدة المعالجة المركزية ، تمت إضافة la #[cfg(target_cpu = "...")] . يمكن العثور على التنفيذ هنا . يعد تنفيذ هذا مستقلاً عن الهدف ، وبالتالي فهو يعمل على التجميع الشرطي المستند إلى وحدة المعالجة المركزية للبنيات الأخرى أيضًا ، مثل ARM. يسمح هذا للصندوق ruduino بتضمين وحدة نمطية خاصة بالجهاز بشكل مشروط والتي تعرض جميع IOs والتسجيلات والوحدات النمطية المدعومة في السيليكون. هذا بالتأكيد يحتاج إلى المرور بعملية RFC قبل المنبع.

ربما حان الوقت لإرسال RFC إلى LLVM-dev فيما يتعلق بترقية الواجهة الخلفية إلى حالة غير تجريبية.

يمكنك رؤية المجموعة الكاملة من التغييرات من المنبع Rust إلى avr-rust هنا .

لا يزال هناك زوجان من تصحيحات LLVM من الشهرين الماضيين اخترناهما في الوقت الحالي ، لكن جهود Rust الأولية لفصل نسخة emscripten من LLVM عن إصدار LLVM المستخدمة لجميع الأهداف الأخرى جعلت من السهل حقًا إحضارها هذه التغييرات من rust-lang/llvm repo ، حيث يتم تحديثها الآن بشكل منتظم.

<4 تصحيحات LLVM المنتقاة من الكرز والتي لدينا قيد المراجعة حاليًا في LLVM المنبع ، ولذا بمجرد أن يجد المراجع وقتًا كافيًا ، ستطفو هذه التصحيحات تلقائيًا في Rust المنبع. يحتوي Upstream Rust أيضًا على تصحيحات خاصة بالصدأ محددة الهدف ، وبالتالي فإن تصحيحات LLVM المنتقاة من الكرز ربما لا تكون في الحقيقة مانعًا لدمج avr-rust upstream

أي تحديث عن حالة الصدأ على AVR؟

مهتم أيضًا بمعرفة! في الوقت الحالي ، قمت بتبديل القرصنة على الحبة الزرقاء STM32 ، لكنني بالتأكيد أرغب في العودة إلى اردوينو بمجرد أن يكون دعم avr في الصدأ جاهزًا.

نحن أيضًا نحب slowtec استخدام Rust لمشاريعنا AVR وبالطبع

Bump ، أود أن أرى الدعم رسميًا. سأحاول استخدام الشوكة لمشروع.

تحديث: في الوقت الحالي ، نقوم بترقية الشوكة إلى إصدار أحدث من Rust (avr-rust / rust # 137). هناك نوعان من الأخطاء التي اكتشفناها.

خطأ LLVM: نفدت السجلات أثناء تخصيص السجل

تم إصلاح هذا في جذع LLVM في مشروع llvm / llvm @ 45eb4c7e55341c0b83a21dedecc092e273795eda. أنا أختار هذا جيدًا في شوكة LLVM الآن. كان هذا الخطأ تاريخيًا أكبر نقطة مؤلمة في الواجهة الخلفية ، حيث نشأ في معظم الأكواد ذات المؤشر الثقيل.

خطأ LLVM: لا يمكن تحديد: t2: i16 = addrspacecast [1 -> 0] undef: i16
t1: i16 = undef
في الوظيفة: _ZN4core3ptr87_ $ LT $ impl $ u20 $ core..fmt..Debug $ u20 $ مقابل $ u20 $ unsafe $ u20 $ fn $ LP $ A $ RP $$ u20 $. $ GT $$ u20 $ Ret $ GT 3 دولارات أمريكية

هذا هو واحد يصعب إصلاحه. وهو ناتج عن سوء معالجة الصدأ لمؤشرات الوظيفة في معماريات هارفارد حيث توجد مساحتان منفصلتان لعنوان المؤشر للوصول إلى الذاكرة الرئيسية وذاكرة البرنامج.

أفضل تفسير لذلك هو @ ecstatic-morse

المشكلة الأساسية هي أن * const T لها دائمًا مسافة إضافية (0). أعتقد أن القوالب الصريحة (ptr as * const T) يجب أن تحافظ على مساحة العنوان لمدخلاتها هنا.

تم الكشف عن الخطأ بواسطة تنفيذ std::fmt::Debug للوظائف ومؤشرات الوظائف. يصدر الصدأ إشارة مرجعية للمؤشر بنوع المؤشر المستهدف addrspace(0)* i16 ، باستخدام إجراءات LLVM التي ستدرج ضمنًا مقطعًا بت (iN -> iM bits) أو مساحة عنوان إذا لزم الأمر. في حالة مؤشرات الوظائف ، يجب أن يقوم Rust بترميز مؤشر addrspace(1)* i16 ، بحيث لا يضطر LLVM إلى تعيين ( addrspacecast ) مؤشرات PROGMEM لمؤشرات RAM مهمة مستحيلة لأنه لا يوجد تخطيط للذاكرة ومساحات العنوان لا تتداخل.

هذا الخطأ هو الحاجز الرئيسي.

آمل أن يسحب Rust المنبع من LLVM master (AFAICT ، إنه إلى حد كبير في الإصدار 8.0) حتى نتمكن من إزالة مجموعة من اختيارات الكرز.

لقد حصلت مؤخرًا على اختبارات https://github.com/dylanmckay/avr-compiler-integration-tests/ التي نجحت باستخدام محاكي AVR ، وهو أمر رائع لأنه لا توجد مجموعة اختبار أخرى تقوم بالفعل بتنفيذ مجموعة AVR بواسطة LLVM. لقد قمت بإعداد GitLab runner لتشغيل اختبارات لكل التزام AVR-Rust (عبر مرآة مستودع GitLab) ، ولكنه ليس مفيدًا للغاية لأن GitLab لا يدعم CI يبني على طلبات السحب ، حيث يتم استضافة الكود الفعلي في مستودع متشعب.

شكرا للتحديث dylanmckay. نحن جميعًا نقدر الجهد الذي بذلته في هذا الأمر.

لقد قمنا الآن بترقية fork ontop الخاص بـ Rust base rust-lang / rust @ fb7cca33f ، يتم تجميع برنامج blink بنجاح.

هل توقفت هذه القضية؟

هل لديك أي تحديثات على هذا؟ هل لا يزال العلاقات العامة متوقفة بسبب مشكلة مساحة العنوان؟

مرحبًا dylanmckay ، آسف على التنصت بهذا .. هل هناك أي تحديث بشأن المشكلة؟

مرحبًا بكم جميعًا ، إليك بعض التعليقات مني

إصلاحات قطف الكرز

تم تحديث جميع العناصر الثابتة المطلوبة تقريبًا للحصول على عمل libcore إلى LLVM Master وهي موجودة حاليًا في rust-lang / llvm fork. بالأمس بدأت في PR لتحديث AVR fork إلى 1.39.0 (avr-rust / rust # 155) ، كان علي فقط اختيار إصلاح واحد لم يكن موجودًا بالفعل - avr-rust / llvm @ 4350776601bc671e6e055bfbe32add34b70d2635.

لا يمكن ترجمة libcore بدون تعديل

لم نعد بحاجة إلى شوكة libcore مخصصة لاستخدام AVR. يوجد حاليًا تعديل واحد فقط على libcore في شوكة avr-rust - avr-rust / rust @ 44240ac59c5949b8a9fd191f5cd666d0206fbe85 -

نحن نعتمد على xargo لتجميع ثنائيات AVR-Rust - سيصبح هذا أسهل مع استمرار مبادرات الشحن

أي عمليات على مؤشرات الوظائف بخلاف ذاكرة الوصول العشوائي للوصول إلى "الاتصال" ، وليس ذاكرة البرنامج (avr-rust # 68)

تم إصلاح هذا.

تولد التحولات 32 بت استدعاءات إلى روتين compiler-rt غير موجود (avr-llvm / llvm # 163)

هذه لا تزال قضية مؤلمة. أظن أن أفضل حل هو كتابة كود تخفيض مخصص في الواجهة الخلفية LLVM AVR يقلل من هذه التحولات إلى التجميع الخالص ، ويزيل أي اعتماد على ABI على compiler-rt أو libgcc. لست متأكدًا من حجم حجم الشفرة الذي تم إنشاؤه ، فقد لا تكون فكرة جيدة.

أسئلة قبل المنبع

RFCs واتفاقيات الاتصال غير المستقرة

لقد نشرت هذا التعليق في الموضوع

تمت إضافة اصطلاح الاستدعاء "avr-interrupt". هذا يسمح "avr-interrupt" خارجي fn my_isr_handler () {..}. ربما يحتاج هذا إلى المرور بعملية RFC حتى يستقر ، لكن قد أكون مخطئًا.

هل يمكن إضافة اصطلاحات استدعاء غير مستقرة دون المرور بعملية RFC؟

حاليًا ، لدينا "avr-interrupt" و "avr-non-blocking-interrupt" تحت بوابة الميزة #![feature(abi_avr_interrupt)] . هل يمكن رفعها على أنها اصطلاحات استدعاء غير مستقرة ، انتظارًا لاستقرار RFC في المستقبل؟

Buildbots

يتطلب تحميل خلفية LLVM إعداد روبوت بناء مخصص يقوم بإجراء اختبارات لتلك الواجهة الخلفية وصيانتها. هل هذا هو الحال مع Rust؟ كيف نتأكد من تشغيل مجموعة الاختبار في وضع AVR مع كل دفعة؟ ماذا فعلت الخلفيات الأخرى (مثل WASM)؟

توزيع

هل يعني "دمج شوكة avr-rust upstream" دمج الشوكتين في واحد ، ولكن لا يزال يتطلب إنشاءًا من المصدر؟ ربما من الممكن أن يتم توزيع الواجهة الخلفية ، لكن ليلاً فقط؟ ماذا فعلت الخلفيات الأخرى؟

بخلاف ذلك ، فإن بقع avr-rust المحددة رقيقة جدًا ، دون أي اختراقات في الوقت الحاضر.

يمكن رؤية مجموعة التصحيح الكاملة هنا https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support

يمكن العثور على مجموعة التصحيح الخاصة بإعادة تثبيت الإصدار 1.39.0 من برنامج ويب WIP (والتي تكون متطابقة في الغالب) هنا https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support-1.39.0-4560ea788c . يجب دمج هذا في avr-rust / master في الأيام القليلة القادمة.

لا يمكنني التفكير في أي شيء محدد يمنع ذلك - ربما حان الوقت لإرسال التصحيحات ومعرفة كيف ستسير الأمور؟

https://github.com/rust-lang/rust/issues/44036

لقد ذكرت هذه المشكلة أعلاه ، لكنني لا أعتقد أنها تمنع تدفق واجهة AVR الخلفية. يجب أن نكون قادرين على الحصول على نسخة عملية ومفيدة من rustc باستخدام AVR بدونها. أنا متأكد من أن هناك حلولاً بديلة واختراقات يمكننا القيام بها. اكتشاف الجهاز في صناديق AVR في هذه الأثناء بعد دمج الواجهة الخلفية افتراضيًا ، وقبل أن تصل واجهة برمجة التطبيقات (API) لاستعلام وحدة المعالجة المركزية المستهدفة الرسمية إلى Rust الرسمي.

لقد عاش! شكرا لتحديث dylanmckay @ ، تقدم مثير.

عمل عظيم dylanmckay! شكرا لإبقائنا على اطلاع.

قليلا خارج الموضوع ، ولكن: هل سيكون rustc for avr قادرًا على عمل FFI مع مكتبات C؟
هناك الكثير من المكتبات الناضجة المتاحة بالفعل لـ avr ولكنها مكتوبة بلغة C / C ++.
سيكون من الرائع أن تكون قادرًا على إنشاء بعض الأغلفة ذات نمط الصدأ لهم وإعادة استخدامها في مشاريعنا الخاصة بالصدأ avr.

يمكن أن يؤدي الصدأ بالفعل إلى تأثير FFI مع C بشكل عام.

نعم وهذا رائع حقًا! السؤال هو: هل يترجم إلى الصدأ؟

طالما أن C ABI الخاص بـ LLVM لـ AVR يتطابق مع مثيله في دول مجلس التعاون الخليجي ، فيجب أن يعمل

هل يمكن إضافة اصطلاحات استدعاء غير مستقرة دون المرور بعملية RFC؟

تصويتي هو نعم ، لأن التغيير لدعم اصطلاحات استدعاء AVR هو في الأساس مجرد منحهم اسمًا وتعيينهم إلى رقم LLVM. ليست هناك حاجة لتغييرات التعليمات البرمجية الأساسية لأن لدينا بالفعل دعم للاتفاقيات غير المستقرة.

يتطلب تحميل خلفية LLVM إعداد روبوت بناء مخصص يقوم بإجراء اختبارات لتلك الواجهة الخلفية وصيانتها. هل هذا هو الحال مع Rust؟ كيف نتأكد من تشغيل مجموعة الاختبار في وضع AVR مع كل دفعة؟ ماذا فعلت الخلفيات الأخرى (مثل WASM)؟

نظام طبقات Rust غير محدد بعض الشيء ، لكنني أعتقد أن الشيء الصحيح هو دمج الكود الخاص بـ AVR . بعد ذلك سيكون AVR من المستوى 3 ، مما يعني أنه لا يتم بناؤه أو اختباره تلقائيًا ، بل يتم تعليقه في الكود. على أقل تقدير ، هذا يعني أن هذه الملفات سيتم تحديثها باستمرار مع تغييرات المترجم.

هل يعني "دمج شوكة avr-rust upstream" دمج الشوكتين في واحد ، ولكن لا يزال يتطلب إنشاءًا من المصدر؟

على حد علمي ، سيكون تقديم الالتزام كعلاقات عامة. ستموت الشوكة المخصصة بشكل فعال / تصبح مكانًا لتتبع التفاصيل الخاصة بـ AVR حتى تصبح هدفًا أكثر استخدامًا.

ربما حان الوقت لإرسال تصحيحات

اعتقد ذلك.

edvorg جدا على موضوع IMO

قليلا خارج الموضوع ، ولكن: هل سيكون rustc for avr قادرًا على عمل FFI مع مكتبات C؟
هناك الكثير من المكتبات الناضجة المتاحة بالفعل لـ avr ولكنها مكتوبة بلغة C / C ++.

نعم .. في الغالب. تم تصميم اصطلاح استدعاء AVR الذي تم تنفيذه بواسطة الواجهة الخلفية AVR لمطابقة AVR-GCC (موثقة هنا ). هناك بعض المراوغات ، لكن تصحيح LLVM D68524 الذي أحتاج إلى مراجعته يجب أن

ستتمكن دائمًا مكالمات Rust من استدعاء وظائف Rust أو avr-clang المترجمة بشكل صحيح (حيث تستخدم avr-clang C نفس extern "C" تطبيق اصطلاح استدعاء مثل واجهة Rust الأمامية) ، والتشغيل البيني مع AVR-GCC _should_ work ، خاصة بالنسبة لتوقيعات الوظائف البسيطة ، ولكن يمكن أن تختنق في بعض الأحيان (راجع وصف D68524 لمزيد من التفاصيل).

أي تحديث على هذا ؟
فضولي فقط.

تم إرسال الطلب لجعل خلفية LLVM AVR خلفية رسمية - https://reviews.llvm.org/D75099

dylanmckay إذا تم قبوله ، ما هي

dylanmckay إذا تم قبوله ، ما هي

من الناحية الفنية ، سيعمل Rust مع الخلفيات الرسمية والتجريبية. لقد قمت بترقية # 69478 لتنشيط الجزء الأكبر من الواجهة الخلفية.

لست متأكدًا مما إذا كان دمج AVR كهدف من المستوى 3 يعتمد على أن تصبح AVR خلفية LLVM رسمية - نرحب بالأفكار.

بالتفكير في الأمر ، يمكن تعيين تمييز LLVM الرسمي مقابل التجريبي على نظام طبقات Rust ، حيث يحتوي Rust على ثلاثة مستويات و LLVM به اثنان. تتوافق الخلفية الرسمية لـ LLVM مع مزيج من المستويين 1 و 2 - بشكل أساسي ، مضمنة في مجموعات الاختبار والإصدارات الرسمية. الخلفية التجريبية LLVM ، بقدر ما أستطيع أن أقول ، هي نفس المعنى مثل الخلفية Rust Tier 3 ؛ مضمن في شجرة المصدر ، غير مدرج في الإصدارات افتراضيًا ، لا يتم تضمينه في اختبارات CI الافتراضية ، إلخ.

ثم أفترض أن الأجزاء الوحيدة المتبقية لإغلاق هذه المشكلة ستكون تلك التي تظهر في مراجعة الكود # 69478.

tl ؛ dr ستصبح الواجهة الخلفية لـ AVR هدفًا علويًا من المستوى 3 في rust-lang / rust # 69478 إذا تم دمجها ، وبالتالي قتل الشوكة.

الاختلاف الوحيد بين شوكة avr-rust / rust و # 69478 هو علامة target_cpu cfg الموجودة في مفترق AVR ولكن ليس في المنبع. لقد تركت ذلك من العلاقات العامة الأولية.

ما هي القطع المتبقية

أنا متأكد تمامًا من أنه لا يزال هناك عدد من أخطاء التوفيق بين أنواع مختلفة من التعليمات البرمجية ، لذلك لا يزال هناك المزيد من الأشخاص لتجربة الأشياء وتقليل الأخطاء وإصلاحها.

سيؤدي الحصول على حرارة عالية إلى خفض المستوى لجعل الأشخاص يجربون الأشياء ، حيث يمكنهم فقط الحصول على Rust العادي كل ليلة بدلاً من تجميع الشوكة القديمة عادةً.

بمجرد تطويره كهدف من المستوى 3 ، هل سيعمل تطوير AVR مع ميزة الشحن -Z build-std ، أم سيتطلب xargo؟ هل يحتوي LLD الذي يشحن مع Rust على دعم AVR ، أو هل ستكون روابط gnu مطلوبة؟

هل سيعمل تطوير AVR مع ميزة الشحن -Z build-std ، أم أنها ستتطلب xargo؟ هل يحتوي LLD الذي يشحن مع Rust على دعم AVR ، أو هل ستكون روابط gnu مطلوبة؟

لا أستطيع أن أقول إن هذه لن تنجح ، لكن كل ما فعلته استخدم روابط Xargo و GNU.

يصعب إعداد روابط GNU على Windows ويتطلب xargo أداة أخرى لتثبيتها ، ولهذا أسأل.

هل يحتوي LLD الذي يشحن مع Rust على دعم AVR ، أو هل ستكون روابط gnu مطلوبة؟

لا يحتوي LLD إلا على دعم أساسي جدًا لربط AVR ، ولا يمكنه ربط أي برامج حقيقية حتى الآن. لذلك ، سيكون مطلوبًا avr-ld .

ثت يسأل لماذا ايم.

لا تخطئ ، أعتقد أيضًا أن هذا هو الهدف النهائي الصحيح ، فقد لا يكون الوضع الحالي للعالم. بصراحة ، سأكون سعيدًا بتخفيض النفقات العامة وانخفاضها. دمجها هو مجرد الخطوة الأولى نحو ذلك.

تم الآن تمكين الواجهة الخلفية لـ AVR كهدف رسمي لـ LLVM: يحتوي tada: LLVM master على دعم AVR افتراضيًا الآن. سيكون إصدار LLVM الأول الذي يتضمن AVR افتراضيًا هو LLVM 11 في غضون 6 أشهر تقريبًا.

لطيف! شكرا لكل الجهد الذي تبذله في هذا.

رائع جدا!

تهانينا dylanmckay على هذا الإنجاز الرائع. المجتمع يشكرك على عملك في هذا.

لقد كنت أتابع هذه المشكلة منذ فترة ، وبينما أعلم أن هذا في الغالب خارج عن الموضوع ، فأنا مهتم بما يعنيه هذا بالنسبة للمستخدم العادي وليس من المصدر ... هل هي عملية معقدة للحصول على Arduino Uno وتشغيله مع Rust الأصلي باستخدام هذا؟ أنا مهتم أكثر بهذا لأن Rust لديه حماية كافية ومن المحتمل أنه لا يمكنني التسبب في ما يقرب من العديد من لحظات oops xP

@ Jimmio92 مما يمكنني إذا سارت الأمور على ما يرام.

_{ومع ذلك ، فإن تجربتي الشخصية مع LLVM هي أنه في كثير من الأحيان لا يحب شيئًا ما على نظامك (على الأقل بالتأكيد على macOS - إنه أسهل على Linux وبالتأكيد لا تحلم بفعل ذلك على Windows) ، لذلك ينتهي بك الأمر حتمًا إلى تدليك مسارات التثبيت والمكتبات المخصصة حتى تنجح أو تستسلم.}

ما تعنيه الأخبار (الممتازة) أعلاه هو هذا فقط: يستهدف مطورو LLVM الآن / يدعمون AVR رسميًا (؟) ، وسيشمل الإصدار التالي من LLVM دعم AVR. لا يوجد ما يقوله أن Rust الآن يدعم أو سيدعم AVR على المدى القصير. إذا نظرت إلى المشكلات والتعليقات المذكورة أعلاه ، يمكنك أن ترى أن الأمر سيستغرق الكثير من العمل حتى يعمل دعم AVR "يعمل فقط" مع مجموعة أدوات Rust.

هل هناك عملية / مثال يمكنني النظر فيه في اختيار إصلاحات AVR من LLVM Master إلى مفترق Rust LLVM؟

أيضًا ، هل لا يزال Rust يتتبع ماجستير LLVM؟ من مظهره ، فإنه يتتبع الإصدار الحالي بالإضافة إلى بعض الإصلاحات المنتقاة من الكرز. هل لا يزال يتم قبول PRs لتحديث إصدار LLVM لإتقانه؟

تضمين التغريدة

أيضًا ، هل لا يزال Rust يتتبع ماجستير LLVM؟

كما لاحظت أنه يتتبع الإصدارات الآن.

هل لا يزال يتم قبول PRs لتحديث إصدار LLVM لإتقانه؟

لا أعتقد ذلك ولكن ccnikic

dylanmckay ، هناك مجموعة من الإصلاحات على مفترق LLVM الخاص بـ Rust مقارنة https://github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05

هل هناك عملية / مثال يمكنني النظر فيه في اختيار إصلاحات AVR من LLVM Master إلى مفترق Rust LLVM؟

تتوفر تعليمات هنا: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

أيضًا ، هل لا يزال Rust يتتبع ماجستير LLVM؟ من مظهره ، فإنه يتتبع الإصدار الحالي بالإضافة إلى بعض الإصلاحات المنتقاة من الكرز. هل لا يزال يتم قبول PRs لتحديث إصدار LLVM لإتقانه؟

يتتبع Rust حاليًا إصدارات LLVM ، لأن هذا يسمح للأشخاص بأداء LTO عبر اللغات بسهولة مع إصدار clang المقابل. لذا فإن الإجابة الافتراضية هنا هي على الأرجح "لا".

ومع ذلك ، كانت هناك بعض المناقشات حول التحديث إلى LLVM master للتخفيف من انحدارات وقت الترجمة LLVM 10. أنا أعمل حاليًا على ذلك لأغراض التقييم. أعتقد أنه من الأكثر أمانًا افتراض عدم حدوث ذلك ، وإرسال اختيارات الكرز مقابل مفترق LLVM 10 الخاص بنا (هل هناك الكثير منهم؟)

تم دمج الشوكة! سوف أكتب تحديث مناسب بعد ظهر هذا اليوم

https://github.com/rust-lang/rust/pull/69478

سوف أكتب تحديث مناسب بعد ظهر هذا اليوم

أنا مهتم بالتحديث المذكور. أين تخطط لنشره @ dylanmckay (لذلك أعرف أين أنظر: قليلاً

لقد كنت أنتظر بفارغ الصبر هذه الإضافة إلى نظام Rust البيئي لسنوات حتى الآن! ومع ذلك ، تبدو محاولاتي الساذجة لاستخدام هذا على الماجستير معيبة.

لقد قمت ببناء الصدأ الرئيسي باستخدام ./x.py build القياسي ، المرتبط كـ toolchain master ، ثم حاولت إنشاء مثال avr-rust / blink (بعد تحديث src/main.rs لاستخدام llvm_asm! ):

RUST_TARGET_PATH=`pwd`
XARGO_RUST_SRC=/home/nixpulvis/Projects/rust

rustup run master xargo build --target avr-atmega328p --release

هذا فشل مع:

error: no matching package named `core` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `sysroot v0.0.0 (/tmp/xargo.oXlxlujoXvXJ)`
error: `"cargo" "build" "--release" "--manifest-path" "/tmp/xargo.oXlxlujoXvXJ/Cargo.toml" "--target" "avr-atmega328p" "-p" "core"` failed with exit code: Some(101)
note: run with `RUST_BACKTRACE=1` for a backtrace

أفترض أن هناك تهيئة لا تزال مطلوبة وأنا في عداد المفقودين.

nixpulvis راجع https://github.com/rust-lang/rust/issues/44052#issuecomment -591396417

لا أتوقع أن يعمل الكثير من أي شيء الآن لأن libcore جزء مما أخطأ في ترجمته.

تم دمج شوكة AVR rustc في اتجاه المنبع.

شوكة المنبع غير قابلة للاستخدام بشكل عام حتى الآن. هناك بعض الأشياء التي يجب أن تحدث أولاً.

إصلاحات AVR LLVM المنبع التي لم يكن Rust بحاجة إلى قطف الكرز

للإجابة على سؤال nikic ، هناك 20 التزامًا من LLVM كحد أقصى يجب انتقاؤها بعناية.

لقد كنت أستخدم برنامجًا نصيًا لاختيار الكرز تلقائيًا _all_ يلتزم AVR من LLVM المنبع إلى مفترق محلي.
هذه مطرقة كبيرة وستكون هناك إصلاحات منتقاة بالكرز وغير ضرورية - هناك إصلاحات LLVM في المنبع يجب سحبها إلى المنبع Rust قبل أن تصبح الواجهة الخلفية قابلة للاستخدام. سوف يحتاجون إلى تصفيتها واختيار الكرز حتى يصل الصدأ في المنبع.

تجميع برنامج وميض AVR LED من فرع Rust الرئيسي المنبع

نظرًا لاستمرار جهود المنبع لبضعة أشهر حتى الآن ، فإن شوكة avr-rust المصب
لا يزال على إصدار قديم بشكل خاص من Rust. منذ ذلك الحين كان هناك تغيير واحد على الأقل في صدأ المنبع الذي يتطلب التعميم لدعم AVR دون الاصطدام بأخطاء تأكيد LLVM. لقد فتحت طلب السحب # 73270 لإصلاحه.

لست متأكدًا مما إذا كانت هناك تغييرات أخرى في صدأ المنبع والتي تحتاج إلى تغييرات لـ AVR - على الأرجح لا.

بمجرد تشغيل برنامج blink ، سأقوم بنشر تحديث آخر لأنه في هذه المرحلة ، يجب أن يكون دعم AVR المنبع جاهزًا للاستخدام / التجريب.

أين يجب أن يحدث اتصال AVR / يتم نشره

wezm أنت تطرح نقطة جيدة - ليس هناك بالضرورة قناة اتصال "مباركة" للتحديثات. لقد عملت هذه التذكرة بشكل جيد ، لكنها ستغلق حتماً قريباً.

تعد قناة AVR-Rust Gitter الخيار الأكثر طبيعية الموجودة. تعجبني فكرة القائمة البريدية (لكني لا أحب فكرة استضافة خادم بريد إن أمكن). تحتوي قناة Gitter بالفعل على مناقشة ، لذا ربما يكون شيء مثل قائمة بريدية مفيدًا.
ربما يكون إنشاء مدونة أمرًا جيدًا لمركزية الإعلانات / التحديثات. أرغب في الحصول على "وسيط رسمي" حتى لا يفوت الأشخاص الذين يريدون تحديثات غير رسمية. أفترض أن المدونة تتطلب فحصًا مستمرًا للمنشورات الجديدة ، بينما تقوم القائمة البريدية بالإشعار بطبيعتها
كل من هو مهتم. نرحب بالاقتراحات.

أسئلة مفتوحة

• هل يجب نقل إصدارات GitHub على شوكة avr-rust إلى مستودع Rust المنبع؟
  ** بغض النظر عن ذلك ، يجب طرح مشكلات جديدة في المستودع الأولي - يجب إنهاء أداة تعقب المشكلات القديمة.
  
  
  
  • أين يجب أن تعيش تعليمات تجميع Rust باستخدام AVR؟
  
  

أهم الأشياء للمستقبل (اقرأ: الأولويات)

• تغليف وتوزيع ثنائيات AVR Rust. يمكن أن يكون تجميع Rust مشكلة كبيرة للمستخدم العادي ،
  يبدو أن العديد من التوزيعات تواجه مشكلات من وقت لآخر في مسارات عمل معينة. تم الإبلاغ عن خطأ العديد من أخطاء OOM كـ
  البق المترجم. عائق الدخول مرتفع بشكل غير ضروري ويجب أن يكون أقل - ما عليك سوى التنزيل والانطلاق.
  تتبعها https://github.com/avr-rust/rust/issues/162
• بناء قائمة بالتكوينات "المدعومة" ، أو على الأقل المختبرة. نحتاج إلى جدول (rustc version, Xargo version) لذا
  التي تتغير إلى واجهات برمجة تطبيقات Rust الخاصة التي تعتمد عليها Xargo لا تكسر سلسلة أدوات AVR Rust عند الترقية.
  Xargo في وضع الصيانة - يبدو أن cargo-xbuild محدودة للغاية (لقد جربتها قبل بضعة أسابيع ، ولا أتذكر السبب) ،
  قد نحتاج إلى تفرع Xargo. ربما يكون من الأفضل إضافة الأدوات مباشرة إلى Cargo (هناك مشكلة تتبع لهذا).
• إعداد نوع من الصفحة الرئيسية للمشروع ، بما في ذلك روابط للتنزيل
• اختبار التكامل (على AVR مقلد / مقلد ، عند كل التزام)

في الوقت الحالي ، سأتأكد من إعادة نشر التحديثات في مشكلة GitHub هذه ، حتى يمكن العثور على وسيط أفضل. سوف أنشرهم في Gitter أيضا.

ربما يكون إنشاء مدونة أمرًا جيدًا لمركزية الإعلانات / التحديثات. أرغب في الحصول على "وسيط رسمي" حتى لا يفوت الأشخاص الذين يريدون تحديثات غير رسمية. أفترض أن المدونة تتطلب فحصًا مستمرًا للمنشورات الجديدة ، بينما تقوم القائمة البريدية بالإشعار بطبيعتها
كل من هو مهتم. نرحب بالاقتراحات.

أفضّل شخصيًا بشكل كبير لصالح المدونة (مع موجز RSS). أعتقد أن المدونات تظهر عادةً بشكل أفضل في نتائج محرك البحث ويكون الارتباط بها أفضل من روابط القائمة البريدية. يحل موجز RSS جانب التدقيق / الإخطار.

لست متأكدًا بنسبة 100٪ من أنه أفضل مكان لذلك ، ولكن هناك مدونة WG المضمنة. قد تكون قناة اتصال منخفضة الجهد.

https://rust-embedded.github.io/blog/

ربما أيضا حساب تويتر؟ يمكن استخدامه لمشاركة منشورات مدونة جديدة (للبقاء على اطلاع دائم).

أعتقد أن مجموعة العمل المدمجة ستسعد بتقديم المساعدة هنا. لدينا حساب على Twitterrustembedded ويمكننا بالتأكيد تضمين الأخبار المتعلقة بـ AVR في النشرة الإخبارية أيضًا.

لقد قمت أيضًا بإنشاء ملصق O-AVR منذ فترة ، لذا لا تتردد في استخدام متعقب مشكلة الصدأ للمشكلات الخاصة بـ AVR أيضًا (ولكن ضع في اعتبارك أن هناك 1.5 ألف شخص يشاهدون الريبو). بالإضافة إلى ذلك ، قد ترغب في التنسيق على Rust-lang Zulip ، حيث توجد معظم فرق Rust. نحن أيضًا بصدد تكثيف "المجموعات المستهدفة" التي تركز على أهداف محددة من الصدأ (مثل Windows أو Arm) ، وقد يكون AVR مناسبًا لذلك أيضًا. لا تتردد في التواصل مع Zulip من أجل هذا.

تحديث.

هناك شيئان متبقيان قبل أن يمكن تجميع libcore لـ AVR على مخزون rust-lang / الفرع الرئيسي:

1. هناك طلب سحب واحد يعمل على إصلاح سلسلة من أخطاء "مساحة العنوان غير صالحة" على AVR ، فيما يتعلق بكيفية وضع علامات على مؤشرات الوظائف لبنى هارفارد على أنها addrspace(1) مقارنة بأهداف Von-Neumann التي لا بأس بها مع Rust الافتراضي الحالي من addrspace(0) . rust-lang / rust # 73270 - يخضع حاليًا لمراجعة الكود.

~ 2. هناك خطأ آخر يمنع مثال blink من العمل - avr-rust / rust # 92. هناك تصحيح لم يتم تحديثه بعد والذي سيعمل على إصلاحه - https://reviews.llvm.org/D68524. سيتم تحديث هذا ثم اختيار الكرز في شوكة Rust's LLVM قريبًا بمجرد أن يمر مقابل اختبارات الوحدة والتكامل. ~ تم دمجه في المنبع LLVM

بمجرد الانتهاء من هذين الأمرين ، سيتمكن هدف Rust AVR من تجميع كود AVR إلى نفس مستوى شوكة avr-rust / rust الحالية ، ويمكننا بعد ذلك بدء عملية تحديث المثال blink ، arduino قفص ، وثائق ، أدلة ، لفرع المنبع. ثم يجب أن يكون فرع المنبع جاهزًا للاستخدام التجريبي.

واحد آخر TODO:

1. ~ أضف سباكة AVR لبناء جملة التجميع المضمن الجديد في Rust المنبع ~
   
   
   
   • ~ بمجرد دعم بناء جملة التجميع المضمن الجديد ، يجب تحديث صندوق Arduino لاستخدامه
     
     بمجرد تحديث صندوق Arduino ، قم بتحديث صندوق الوميض إلى الإصدار الجديد. ~ يمكننا استخدام الماكرو القديم عبر llvm_asm! في الوقت الحالي لأنه لا يزال موجودًا ليلاً.
   
   
2. تصحيحات تصحيح Cherry-pick AVR (معظمها Ayke's) من LLVM Master إلى شوكة Rust LLVM المنبع (تحرير: PR: https://github.com/rust-lang/llvm-project/pull/66)

إليك الفرع الذي يحتوي على كل شيء: https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. هذا الفرع كافٍ لتجميع libcore.

تم إنشاؤه من المنبع rust-lang/master ولكنه يتضمن أيضًا تصحيح LLVM D68524 الذي لم يتم

تحديث : فتح طلب سحب يتضمن جميع إصلاحات LLVM المنبع.

فيما يلي قائمة شاملة بالأعمال المتبقية قبل تجميع برنامج وميض LED وتشغيله بنجاح.

العمل المتبقي

• [x] صدأ الأرض PR rust-lang / rust # 73270 . يعمل طلب السحب هذا على إصلاح سلسلة من أخطاء "عنوان الفضاء يلقي غير صالحة" على AVR ، فيما يتعلق بكيفية وضع علامات على مؤشرات الوظائف لبنى هارفارد على أنها addrspace (1) مقارنة بأهداف Von-Neumann التي تتوافق مع Rust الافتراضي الحالي لـ addrspace (0) . هو حاليا في مراجعة التعليمات البرمجية.
• [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . يؤدي هذا إلى سحب جميع إصلاحات AVR المطلوبة من LLVM المنبع إلى مفترق Rust's LLVM. في النهاية ، كان هناك ~ 17 ~ 16 إصلاحًا لل LLVM التي يجب انتقاؤها بالكرز.
• [x] Land Rust PR rust-lang / rust # 73658 الذي يقوم بتحديث إصدار الوحدة الفرعية LLVM . مستندات مترجم Rust لديها تعليمات للقيام بذلك. هو حاليا في مراجعة التعليمات البرمجية .
• [x] صدأ الأرض PR ~ الصدأ لانج / الصدأ # 74625 ~ الصدأ-لانج / الصدأ # 74631 . في 79a42e37084d0 ، بدأ Rust بتمرير الوسيطة --eh-frame-hdr للرابط دون قيد أو شرط. لا يدعم رابط AVR-GCC هذه العلامة ولذا تتم إضافة حالة خاصة لتجنب تجاوزها لـ AVR ، على غرار الاستبعادات الحالية لنظام التشغيل Windows. سولاريس و UEFI.

ربما يكون من الأفضل إضافة الأدوات مباشرة إلى Cargo (هناك مشكلة تتبع لهذا).

أفترض أن هذه هي المشكلة الصحيحة: rust-lang / cargo # 4959.

cargo build -Z build-std=core بشكل جيد في حالات AVR الخاصة بي.

shepmaster الذي يبدو أنه

أثناء عملية استخدام -Z build-std=core كنت بحاجة إلى توفير ثلاثية مستهدفة ، لذلك قمت بتشغيل rustc +master --print target-list | grep avr ، ووجدت avr-unknown-unknown . لكن يبدو أن المشكلة المؤرشفة avr-llvm / llvm # 35 تجعلها تبدو وكأنها يجب أن تكون في الحقيقة avr-atmel-none (وهو الأمر الأكثر منطقية بالنسبة لي على أي حال). هل هناك شيء يحتاج إلى التحديث هنا ، أم أني أفقد شيئًا ما؟

avr-unknown-unknown صحيح.

أسئلة مفتوحة

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

لا أعتقد أن هذا مهم للغاية من جانب المستخدم. كان هذا سهلاً بما يكفي للعثور عليه من خلال ddg و / أو هذا الأسبوع في الصدأ.
كل ما يسهل على المطورين.

أسئلة مفتوحة

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

لا أعتقد أن هذا مهم للغاية من جانب المستخدم. كان هذا سهلاً بما يكفي للعثور عليه من خلال ddg و / أو هذا الأسبوع في الصدأ.
كل ما يسهل على المطورين.

أعتقد أن التعليمات الخاصة بتجميع Rust باستخدام AVR يجب أن تكون بطريقة ما في https://docs.rust-embedded.org/

حسنًا ، وقت التحديث.

جميع التصحيحات المطلوبة لـ AVR موجودة في مترجم Rust الليلي الحالي اعتبارًا من rustc 1.47.0-nightly (0820e54a8 2020-07-23) . يمكن الآن لمجمع Rust الليلي ، بدون تعديل ، تجميع مثال وميض LED بنجاح وإنشاء ملف AVR ELF.

• تم إنشاء صفحة هبوط مركزية جديدة للمشروع على https://avr-rust.com/
• كتاب جديد - تم إنشاء دليل AVR-Rust ، واستضافته على صفحات GitHub على book.avr-rust.com.
• تم إهمال مستودع شوكة avr-rust / rust. لم يتم أرشفة المستودع بعد نظرًا لوجود مشكلات حالية يجب ترحيلها قبل أن يتم إقفالها وإغلاقها بشكل دائم.
• لم يعد Xargo مطلوبًا - فالعلامة -Z build-std في Rust تستبدل الحاجة إليه على AVR. لم تعد هناك حاجة لشوكة البضائع - ستعمل الشحنات الأولية.

يمكن الآن اعتبار برنامج التحويل البرمجي Rust الليلي القناة الموصى بها لـ Rust مع دعم AVR.

أنا أغلق هذا العدد الآن - لقد فعلنا ذلك!

يمكن العثور على خطوات الإبلاغ عن الأخطاء في دليل AVR .

يعد دليل AVR ومثال وميض على https://github.com/avr-rust/blink أفضل الموارد لبدء استخدام الهدف.

شكر عميق وعميق لكل من ناقش المشروع ودعمه من خلال جهود التنقيب والإنتاج هذه - إنه موضع تقدير كبير.

FIN

واو واو واو.

شكرًا لكل من ساهم في هذا - كنت أتطلع إلى يومنا هذا منذ الأبد!

Dylan McKay قبل نقل الصدأ إلى avr

و بعد

شكرا لك على كل العمل الشاق يا رجل! :-) خذ قسطا جيدا من الراحة!