2 คะแนน โดย GN⁺ 2023-12-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความคืบหน้าในการพัฒนาคอมไพเลอร์ Rust ที่อิงกับ GCC

  • gccrs ซึ่งเป็นโครงการคอมไพเลอร์ Rust ที่อิงกับ GCC เริ่มต้นในปี 2014 และมีเป้าหมายเพื่อสร้างคอมไพเลอร์ Rust ภายใน GNU Compiler Collection (GCC)
  • เป้าหมายของ gccrs คือการถูกรวมอยู่ในรีลีส GCC 13 แต่ทำไม่สำเร็จ และปัจจุบันตั้งเป้าให้ถูกรวมใน GCC 14 (คาดว่าจะออกช่วงกลางปี 2024)
  • gccrs กำหนดเป้าหมายที่ Rust เวอร์ชัน 1.49 ซึ่งเป็นเวอร์ชันสุดท้ายก่อนมีการนำ const generics เข้ามา
  • หนึ่งในหลักการสำคัญของโครงการ gccrs คือไม่สร้าง "superset" ของ Rust แต่จำลองผลลัพธ์ของ rustc ให้เหมือนเดิมทุกประการ
  • ไลบรารีมาตรฐานของ Rust ประกอบด้วย "crates" หลายตัว และ gccrs กำลังมุ่งเน้นไปที่การรองรับการคอมไพล์ core และ alloc crate ในกลุ่มนี้
  • ขณะนี้ gccrs ยังไม่สามารถคอมไพล์ crates เหล่านี้ได้ เนื่องจากยังขาดฟีเจอร์หลายอย่าง โดยมีปัญหาสำคัญคือการไม่มี borrow checker และการขาด LLVM intrinsics ที่ GCC ยังไม่รองรับ

การใช้ประโยชน์จากข้อดีของระบบนิเวศ GCC

  • หนึ่งในเหตุผลหลักของการพัฒนา gccrs คือเพื่อให้สามารถใช้ security plugin ของ GCC ได้
  • gccrs ถูกใช้งานแล้วในชุมชนโฮมบรูของ Sega Dreamcast และสามารถใช้ GCC plugin เพื่อทำ static analysis กับโค้ด unsafe Rust ได้
  • จากความพยายามของ gccrs ทำให้สามารถช่วยเพิ่มฟีเจอร์ให้กับสเปกของ Rust และต้องการมีส่วนร่วมในงานจัดทำสเปกทางการของ Rust

ฟีเจอร์ที่กำลังพัฒนา

  • gccrs ยังคงขาดฟีเจอร์แกนกลางอีกหลายอย่าง รวมถึง async/await, LLVM intrinsics ที่ไม่มีใน GCC และแมโคร format_args!()
  • โครงการ Polonius เป็นการนำ borrow checker มาใช้ด้วยอัลกอริทึมอีกแบบหนึ่งเพื่อคำนวณอายุของ reference และแก้ข้อด้อยของ borrow checker ปัจจุบันใน rustc
  • เริ่มมีการทำงานกับแมโคร format_args!() แล้ว ซึ่งจำเป็นต่อการประกอบอาร์กิวเมนต์ที่ส่งต่อไปยังแมโครจัดรูปแบบสตริงตัวอื่น

rustc_codegen_gcc

  • rustc_codegen_gcc เป็นอีกหนึ่งโครงการ Rust ที่อิงกับ GCC ซึ่งมีความพร้อมมากกว่า gccrs และมีขอบเขตที่จำกัดกว่า
  • rustc_codegen_gcc ใช้ไลบรารี libgccjit เพื่อเชื่อมต่อเข้ากับ LLVM backend API ของ rustc และทำการคอมไพล์ในช่วงท้ายของทั้ง rustc และ GCC
  • ณ เดือนตุลาคม 2023 rustc_codegen_gcc สามารถคอมไพล์ Rust for Linux ได้โดยไม่ต้องมีแพตช์เพิ่มเติม

Rust for Linux

  • โครงการ Rust for Linux มีเอกสารอธิบายวิธีสร้างโค้ด Rust สำหรับเคอร์เนลโดยใช้ rustc หรือ rustc_codegen_gcc
  • gccrs ตั้งเป้ารองรับ Rust for Linux แต่ในตอนนี้ยังดูเป็นเป้าหมายที่ห่างไกล เนื่องจากมีช่องว่างขนาดใหญ่กับเวอร์ชัน rustc ที่รองรับอยู่ในปัจจุบัน

ความเห็นของ GN⁺

  • โครงการ gccrs มีเป้าหมายเพื่อสร้างคอมไพเลอร์ Rust ที่อิงกับ GCC ซึ่งช่วยเพิ่มความหลากหลายให้ระบบนิเวศ Rust และมีศักยภาพในการใช้ประโยชน์จากเครื่องมือเดิม เช่น security plugin ของ GCC
  • แม้ gccrs จะยังไม่สามารถคอมไพล์ส่วนแกนหลักของไลบรารีมาตรฐาน Rust ได้ แต่การที่มีกรณีใช้งานจริงแล้วในชุมชนโฮมบรูของ Sega Dreamcast ก็นับว่าน่าสนใจ
  • บทความนี้ให้มุมมองที่น่าสนใจเกี่ยวกับการมีอิมพลีเมนเทชันคอมไพเลอร์ Rust ที่หลากหลาย และความเป็นไปได้ในการขยายระบบนิเวศที่ตามมา

1 ความคิดเห็น

 
GN⁺ 2023-12-19
ความคิดเห็นใน Hacker News
  • สรุปความคิดเห็นแรก:

    • รู้สึกว่าบทความอธิบายแรงจูงใจในการพัฒนา gccrs ได้ไม่หนักแน่นพอ
    • gccrs กำลังถูกพัฒนาเพื่อใช้ประโยชน์จากปลั๊กอินด้านความปลอดภัยของ GCC
    • โครงการ 'Rust for Linux' ที่เพิ่มการรองรับ Rust ให้ลินุกซ์เคอร์เนลก็เป็นอีกเหตุผลหนึ่ง
    • เป็นแรงจูงใจสำคัญเพราะมีนักพัฒนาเคอร์เนลจำนวนมากที่ต้องการคอมไพล์ลินุกซ์เคอร์เนลโดยใช้เฉพาะ GNU toolchain
    • มีการอธิบายเหตุผลของการใช้ GCC เป็นแบ็กเอนด์ แต่ยังอธิบายไม่พอว่าทำไมจึงต้องมีฟรอนต์เอนด์ที่ซ้ำกัน
    • ควรเรียนรู้จากความผิดพลาดของ C++ และฟรอนต์เอนด์ที่หลากหลายทำให้การพัฒนาข้ามแพลตฟอร์มยากขึ้น
    • มีความระมัดระวังไม่ให้ gccrs กลายเป็น 'GNU Rust' และพยายามจำลองผลลัพธ์ของ rustc
  • สรุปความคิดเห็นที่สอง:

    • Rust จำเป็นต้องมีมาตรฐานภาษา
    • หลายองค์กรและหลายอุตสาหกรรมจะไม่ยอมรับ Rust หากไม่มีมาตรฐาน
    • ภาษาอื่นอย่าง C, C++, C#, JavaScript (ECMAScript) ต่างก็มีมาตรฐานทั้งหมด
  • สรุปความคิดเห็นที่สาม:

    • รู้สึกประหลาดใจกับปฏิกิริยาเชิงลบต่อ GCC-RS
    • หากภาษาหนึ่งไม่มีหลาย implementation ภาษานั้นก็ยังไม่สมบูรณ์
  • สรุปความคิดเห็นที่สี่:

    • gccrs จะทำให้ Rust รองรับสถาปัตยกรรมที่ LLVM ไม่รองรับได้
  • สรุปความคิดเห็นที่ห้า:

    • คิดว่าการที่ gccrs พยายามจำลองแม้กระทั่งบั๊กและความผิดปกติเฉพาะของ rustc เป็นความผิดพลาด
    • Rust ไม่มีสเปกอย่างเป็นทางการ และการใช้ reference implementation เพียงตัวเดียวเป็นเอกสารอ้างอิงถือเป็นจุดอ่อนระยะยาว
    • การพยายามทำให้โค้ดที่มีอยู่ทำงานได้บนทุก implementation เป็นเรื่องสมเหตุสมผล แต่ก็มีปัญหาเรื่องการทำให้การตัดสินใจที่ผิดพลาดและบั๊กคงอยู่ถาวร
    • Microsoft ทุ่มเทอย่างมากเพื่อให้โปรแกรมเก่ายังคงรันต่อไปได้
    • Rust ไม่ควรแบกรับภาระนี้ตั้งแต่ช่วงต้นของการพัฒนาภาษา
    • หากภาษาจะพัฒนาต่อไปได้ ก็ต้องยอมรับ QA และ QC
    • ภาษาที่มีมาตรฐานแข็งแรงต่างยอมรับแนวคิดนี้
  • สรุปความคิดเห็นที่หก:

    • ขอบคุณที่โพสต์ลิงก์ lwn.net เพราะช่วยเตือนให้ต่ออายุสมาชิก
  • สรุปความคิดเห็นที่เจ็ด:

    • ตอนนี้ลินุกซ์สามารถคอมไพล์ด้วย clang ได้อยู่แล้ว
    • การพัฒนาและดูแลความพยายามที่ซ้ำซ้อนเช่นนี้เพื่อ 'ความบริสุทธิ์' แบบ GNU ดูไม่คุ้มค่า