Rust: دعم الحقول بت لـ C interop

يبدو لا مفر منه. أفضل تجربة المسار الكلي أولاً.

لا يبدو أنه أمر لا مفر منه بالنسبة لي ... أشعر أنه يمكننا الحصول على ما يرام باستخدام uints والإخفاء الصريح. بعض وحدات الماكرو لدعم وحدات البت ستكون جيدة بالطبع. أظن أن تخطيط bitfields يتم بالكامل في clang ، وليس LLVM ، على الرغم من أنني قد أكون مخطئًا ، مما يجعل هذا الأمر صعبًا للغاية بالنسبة لنا لدعمه.

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

تتجنب نواة Linux (والعديد من المكتبات) حقول البت بشكل عام ، لأن إنشاء كود المترجم غير موثوق. يتم ترك المحاذاة والترتيب والتخطيط للتنفيذ ، لذا سيتعين علينا دعم عناصر ABI مختلفة: http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html

نعم ، أنا بخير لتجنب هذا.

هل هذا يعني أنه للقيام بذلك في Servo ، يتعين علينا استخدام C shims للحصول على / تعيين كل حقل لتجنب هذه المشكلات؟

لقد عثرت للتو على هذه المشكلة أثناء القراءة عن Rust. كنت أشعر بالفضول بشأن bitfields لأنني أقوم بالكثير من تطوير كود C / C ++ المضمّن ونستخدم حقول بت للتعبير عن حالة الجهاز المتصل بـ UART. الدولة كبيرة جدًا ولكنها ليست سيئة للغاية بفضل bitfields. من السهل جدًا تحديد القيم المنطقية ، وبعض الأعداد الصحيحة الصغيرة والتعدادات على أنها منفردة إلى عدد قليل من البتات نظرًا لقيود الذاكرة المنخفضة. لست متأكدًا مما إذا كان Rust يطمح للتشغيل على جهاز بنطاق ذاكرة 4KB - 16KB لكنني لن أستخدم Rust إذا تطلب مني استخدام وحدات الماكرو للحصول على إشارات بت واحد. تسمح Bitfields بتعليمات برمجية عالية المستوى حيث تقوم وحدات الماكرو بعمل سخام غير قابل للقراءة. عند الحاجة إلى توافق محاذاة ABI / محدد ، قد تكون وحدات الماكرو بالطبع هي الخيار الوحيد. ربما تستخدم مشاريع مثل Servo أو محركات Javascript المستقبلية في Rust داخليًا حقول بت لحفظ الذاكرة في حالات محددة.

RushPL : وحدات ماكرو الصدأ ليست مثل وحدات ماكرو سي. إنها ليست بديلاً نصيًا ، ولكنها تتلاعب بالأشجار المميزة من خلال مطابقة النمط (وحدات الماكرو التعريفي) أو كود Rust (وحدات الماكرو الإجرائية). في بعض الحالات ، يمكن توفير بناء جملة أفضل بدونها ، لكن Rust يستخدم بالفعل وحدات الماكرو بشكل مكثف لأشياء مثل سلاسل التنسيق التي تم فحصها من النوع ( std::fmt ).

حسنًا ، سيظل يتضمن توفير أرقام بت محددة ، أليس كذلك؟ (ومن ثم جعل خطأ الكود عرضة)
let some_state = int_from_bits!(object.state, 3, 5) // 5 bit number from bit 3
ضد
let some_state = object.some_state // compiler does all the magic as it should be

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

نفس الشيء الذي يمكنك القيام به باستخدام C أو C ++ إذا لم تكن تستخدم bitfields ولكن هل يعد إنشاء الكود إجابة جيدة؟ يمكن للمرء أن يتخطى الأدوية الجنيسة الداعمة وبدلاً من ذلك يُنشئ كل الأكواد لأنواع مختلفة. على أي حال ، فقط سنتان من منظور شخص يهتم بحجم هياكل البيانات وسهولة استخدام الحقول المضمنة.

انظر: RFC: حقول البت ومطابقة البت
https://github.com/rust-lang/rfcs/pull/29

هل يعالج الماكرو bitflags! هذه المشكلة؟

https://github.com/mozilla/rust/pull/13072

قد يكون من الحكمة إغلاق هذه المشكلة في كلتا الحالتين ، نظرًا للاستجابة الفاترة والمتطلبات الغامضة.

تم نقل هذه المشكلة إلى RFCs repo: rust-lang / rfcs # 314