Dozer คอมไพเลอร์ Rust ที่กำลังเขียนด้วย C ล้วน

 (notgull.net)
1 คะแนน โดย GN⁺ 2024-08-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Dozer เป็นคอมไพเลอร์ Rust ที่ใช้ C ล้วน โดยมีเป้าหมายให้สามารถใช้ Rust ได้ตั้งแต่ขั้นตอน bootstrap ที่เร็วขึ้น และกำลังเขียนโดยไม่ใช้ C++·flex·yacc·Makefile
  • คอมไพเลอร์ทางการ rustc เขียนด้วย Rust จึงใช้ rustc เวอร์ชันก่อนหน้าเพื่อ build เวอร์ชันใหม่ และโซ่นี้ย้อนกลับไปได้ถึงคอมไพเลอร์ Rust ยุคแรกที่เขียนด้วย OCaml รวมถึงชั้นของ Guile·C
  • การ bootstrap Linux ของ Bootstrappable Builds เริ่มจาก binary seed ขนาด 512 ไบต์ แล้วขยายไปเป็นคอมไพเลอร์อย่างง่าย, shell, subset ของ C, TinyCC, yacc, coreutils, Bash, autotools, GCC, Linux
  • ปัจจุบัน Rust ปรากฏในขั้นตอนปลาย ๆ ผ่าน mrustc ที่เขียนด้วย C++ เพื่อคอมไพล์ rustc 1.56 ดังนั้นก่อนนำ C++ เข้ามาจึงใช้งาน Rust ได้ยาก
  • Dozer ตั้งเป้าเป็น คอมไพเลอร์ Rust ที่ bootstrap ได้ด้วย TinyCC และหลังจากนั้นต้องการเชื่อมต่อไปถึง libcore, backend Cranelift ของ rustc, เครื่องมือทดแทน cargo และการ rebuild canonical rustc/cargo

เป้าหมายและข้อจำกัดของ Dozer

  • Dozer เป็นคอมไพเลอร์ Rust ที่กำลังเขียนด้วย C ล้วน
  • ไม่ใช้ C++ และไม่ใช้ flex, yacc, Makefile
  • เป้าหมายหลักคือสร้างคอมไพเลอร์ที่ทำให้ Rust สามารถ bootstrap จาก C ได้
  • โดยเฉพาะต้อง bootstrap ได้จาก TinyCC และสมมติว่าระบบไม่มีเครื่องมือที่มีประโยชน์ใด ๆ นอกจากคอมไพเลอร์ C กับ shell พื้นฐานมาก ๆ

ปัญหาที่คอมไพเลอร์ Rust build ตัวเอง

  • หากต้องการรันโค้ด Rust จำเป็นต้องคอมไพล์ และโดยทั่วไป cargo build จะเรียก rustc ภายใน
  • ตัว rustc เองก็เป็น คอมไพเลอร์ Rust ที่เขียนด้วย Rust ดังนั้น rustc เวอร์ชันใหม่จึงถูกคอมไพล์ด้วย rustc เวอร์ชันก่อนหน้า
    • rustc 1.80.0 คอมไพล์ด้วย rustc 1.79.0
    • โซ่นี้ดำเนินต่อไปยังเวอร์ชันเก่ากว่านั้น เช่น rustc 1.78.0
  • ช่วงแรกสุดย้อนกลับไปถึง Rust 0.7 ซึ่งคอมไพเลอร์ ณ จุดนั้นเขียนด้วย OCaml
  • เนื่องจากต้องมีคอมไพเลอร์ OCaml ด้วย โซ่ bootstrap จึงต่อไปยัง implementation ของภาษาอื่นอีก
    • camlboot สามารถใช้ Guile เพื่อคอมไพล์คอมไพเลอร์ OCaml ได้
    • interpreter ของ Guile เขียนด้วย C

โซ่ด้านล่างของ Bootstrappable Builds

  • Bootstrappable Builds ครอบคลุมกระบวนการ bootstrap ทั้งระบบจาก binary seed ขนาดเล็ก
  • Linux bootstrap process เริ่มจาก binary seed ขนาด 512 ไบต์
    • seed นี้มีคอมไพเลอร์ที่เรียบง่ายมาก ซึ่งรับเลขฐานสิบหกแล้ว output เป็น raw byte ที่สอดคล้องกัน
    • การเรียง byte ฐานสิบหกโดยไม่นับ comment และ whitespace ก็ถือในเชิงเทคนิคว่าเป็น source code ที่วิเคราะห์ได้
  • ขั้นตอนหลังจากนั้นจะค่อย ๆ build เครื่องมือระดับสูงขึ้น
    • ระบบปฏิบัติการที่เรียบง่ายมาก
    • shell พื้นฐาน
    • คอมไพเลอร์ที่ก้าวหน้าขึ้นเล็กน้อย
    • ขั้นตอนที่ดูเหมือน assembly code
    • subset ของ C ที่พื้นฐานมาก
    • คอมไพเลอร์ C ที่ก้าวหน้าขึ้นซึ่งเขียนด้วย subset ของ C นั้น
  • หลังจากผ่านไปไม่กี่ขั้น ก็สามารถคอมไพล์ TinyCC ได้ และจากนั้นต่อไปยัง yacc, coreutils พื้นฐาน, Bash, autotools, GCC, Linux
  • แต่ละขั้นตอนถูกระบุไว้ใน live-bootstrap parts.rst

Rust ปรากฏช้าเกินไปใน bootstrap chain

  • ปัจจุบัน Rust ปรากฏในกระบวนการนี้ในขั้นตอนที่ช้ามาก
  • implementation ที่ใช้คือ mrustc ซึ่งเป็น implementation ทางเลือกของ Rust ที่เขียนด้วย C++
  • mrustc สามารถคอมไพล์ rustc 1.56 ได้ และหลังจากนั้นก็สามารถคอมไพล์ต่อไปจนถึงโค้ด Rust สมัยใหม่
  • อย่างไรก็ตาม เมื่อถึงจุดที่ C++ ถูกนำเข้ามาใน bootstrap chain กระบวนการ bootstrap ก็แทบจะจบลงแล้วในทางปฏิบัติ
  • หากต้องการใช้ Rust ในขั้นตอนก่อนนำ C++ เข้ามา จำเป็นต้องมี คอมไพเลอร์ Rust ที่ bootstrap ได้จาก C

สถานะ implementation ปัจจุบันของ Dozer

  • Dozer ถูกพัฒนามาประมาณสองเดือนแล้ว และเขียนโดยไม่ใช้ extension
  • ปัจจุบันสามารถคอมไพล์ได้ทั้ง TinyCC และ cproc โดยไม่มีปัญหา
  • backend ใช้ QBE
  • implementation ยังอยู่ในช่วงต้น
    • lexer เสร็จแล้ว
    • parser ถูก implement ไปแล้วเป็นส่วนใหญ่
    • macro/module expansion ถูกเลื่อนไปไว้ให้ช้าที่สุดเท่าที่จะเป็นไปได้
    • type checking ตอนนี้รองรับเฉพาะ i32
    • code generation ยังอยู่ในสภาพหยาบ ๆ
  • ปัจจุบันสามารถคอมไพล์โค้ด Rust ต่อไปนี้ได้สำเร็จ
fn rust_main() -> i32 {
    (2 - 1) * 6 + 3
}

แผนที่ต่อไปถึง rustc

  • เป้าหมายคือค่อย ๆ พัฒนา Dozer ให้คอมไพล์ตัวอย่างการใช้ libc พื้นฐานได้ จากนั้นคอมไพล์ libcore และ rustc ต่อไป
  • มีแผนใช้ backend Cranelift สำหรับการคอมไพล์ rustc
    • backend Cranelift เขียนด้วย Rust ทั้งหมด
    • เนื่องจากสมมติว่าไม่มี C++ จึงไม่สามารถคอมไพล์ LLVM ได้
  • มีแผนสร้าง เครื่องมือทดแทน cargo ที่สามารถคอมไพล์ package Rust ด้วย Dozer ได้ด้วย
  • ต้องค้นหาและลบไฟล์ที่สร้างอัตโนมัติใน source ของ rustc
    • ตามกฎของโปรเจกต์ Bootstrappable ไม่อนุญาตให้มีโค้ดที่สร้างอัตโนมัติ
  • เป้าหมายสุดท้ายคือสร้างกระบวนการที่หลังจากคอมไพล์ rustc และ cargo แล้ว จะใช้ rustc/cargo ที่คอมไพล์เองนั้นมาคอมไพล์ canonical rustc/cargo อีกครั้ง
  • โปรเจกต์นี้เป็นงานที่ยากที่สุดในบรรดางานที่รับมาจนถึงตอนนี้ และแม้จะมีข้อสงสัยว่าจะทำสำเร็จได้หรือไม่ แต่ก็มีจุดยืนว่าจะพยายามต่อไป

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2024-08-26
ความคิดเห็นบน Hacker News

  • ถ้าจะบูตสแตรป Rust ผมคงสร้าง proto-Rust ที่มีฟีเจอร์น้อยกว่า Rust ทั้งหมดด้วย C แล้วใช้ proto-Rust นั้นเขียนคอมไพเลอร์ Rust แบบสมบูรณ์
    ตัวอย่างเช่น proto-Rust อาจไม่มี borrow checker, รองรับแมโครแบบจำกัดหรือไม่รองรับเลย, อาจไม่คืนหน่วยความจำ และไม่จำเป็นต้องสร้างโค้ดที่ดีด้วย
    โดยพื้นฐานแล้วคงใกล้เคียงกับ C ที่มีไวยากรณ์แบบ Rust แต่ในมุมของคนชอบ Rust วิธีนี้ดูดีกว่าการเขียนคอมไพเลอร์ Rust ด้วย “C ที่มีไวยากรณ์ C” ซึ่งเป็นเป้าหมายของโปรเจกต์นี้
    สงสัยว่าทำไมจึงไม่เลือกเส้นทางนี้

    • อ้างอิงเพิ่มเติม คอมไพเลอร์ Rust ที่ไม่ใช่ Rust ตัวเด่นที่มีอยู่แล้วอย่าง mrustc ก็ไม่มี borrow checker อยู่แล้ว
      การเอา borrow checker ออกไม่ได้ทำให้โปรแกรมที่ถูกต้องพัง เพียงแต่ทำให้โปรแกรมที่ผิดจำนวนมากคอมไพล์ผ่านได้
      การใช้งานหลักของ mrustc คือคอมไพล์ rustc และเรารู้อยู่แล้วว่า rustc สามารถคอมไพล์ตัวเองได้โดยไม่มีข้อผิดพลาดจาก borrow checker ดังนั้นจึงไม่เป็นไร
    • ใน Mozart/Oz ทำแบบนั้นจริง ๆ มีคอมไพเลอร์ proto-Oz ที่เขียนด้วย Scala แล้วใช้มันคอมไพล์คอมไพเลอร์จริงที่เขียนด้วย Oz
      เนื่องจากคอมไพเลอร์ Scala สร้างโค้ดที่ไม่มีประสิทธิภาพ หลังจากนั้นจึงคอมไพล์คอมไพเลอร์จริงซ้ำด้วยตัวมันเอง
      ทำแบบนี้แล้วสุดท้ายจะได้คอมไพเลอร์จริงที่มีประสิทธิภาพและสร้างโค้ดได้ดี และกระบวนการนี้รวมอยู่ในบิลด์มาตรฐานของภาษา
      https://github.com/mozart/mozart2
    • แบบนั้นท้ายที่สุดก็เท่ากับใช้คอมไพเลอร์สองตัวอยู่ดี เลยไม่รู้ว่านอกจากงานที่เพิ่มขึ้นแล้ว ได้อะไรจริง ๆ

  • ผมกำลังทำคอมไพเลอร์ C ด้วย Rust เป็นงานอดิเรก และเรียกมันว่า Small C Compiler แบบขำ ๆ เพราะ Rust หนักกว่า C แน่นอน เป็นการล้อ “Tiny C Compiler”
    ใช้ Cranelift เป็นแบ็กเอนด์ แต่โครงสร้างคอมไพเลอร์ทั้งตัวออกแบบให้เสียบเปลี่ยนได้ด้วย trait จำนวนมากและแฮ็กได้ง่าย
    ยังไม่คิดจะเปิดเป็นโอเพนซอร์สจนกว่าจะทำงานได้พอประมาณ เช่นจัดการ printf("%s", "Hello World!") ได้
    ผมตั้งใจจะทำ preprocessor และ parser และเพราะปัญหา typedef อันเลื่องชื่อ จึงเข้าไปเกี่ยวข้องกับ rust-peg และ HimeCC ด้วย
    ในอุตสาหกรรมรู้กันว่าใช้ symbol table เพื่อรักษาบริบทของ typedef แต่ก็มีข้อจำกัดคืออ่านชนิดที่อยู่ด้านล่างไม่ได้ ผมสงสัยว่าแนวทางแก้แบบวิชาการคืออะไร และที่นึกออกก็มีแค่ transactional memory
    ถ้ามีอะไรที่เป็นประโยชน์ สุดท้ายก็คงเปิดเผยออกมา

    • เกร็ดทางประวัติศาสตร์ที่น่าสนใจคือ Dr. Dobbs Journal เคยตีพิมพ์โปรแกรมชื่อ Small C Compiler ของ Ron Cain ในปี 1980
      ต่อมา James Hendrix ขยายมันเป็นหนังสือที่มีการใช้งานสมบูรณ์กว่า ตอนเด็กผมเจอหนังสือเล่มนี้ในกระบะลดราคาของ CompUSA จึงได้เรียน C และยังเก็บหนังสือไว้จนถึงตอนนี้
      https://archive.org/details/dr_dobbs_journal_vol_05_201803/p...
      https://www.amazon.com/Small-Compiler-Language-Theory-Design...
    • อยากให้ตั้งชื่อว่า “SmaCC” แทน “SCC”

  • เจ๋งมากจริง ๆ แต่สิ่งที่น่าสนใจคือ ปัญหาการบูตสแตรป แบบเดียวกันนี้มีอยู่ในฮาร์ดแวร์ด้วย
    คอมพิวเตอร์ถูกสร้างขึ้นด้วยอะไร? ด้วยคอมพิวเตอร์ที่ถูกสร้างไว้ก่อนหน้าและซอฟต์แวร์ที่รันอยู่บนนั้น ยิ่งคิดก็ยิ่งน่าสนใจ

    • ปัญหาบูตสแตรปแบบเดียวกันมีอยู่ในทุกสิ่ง ถนนถูกสร้างด้วยอะไร? ด้วยเครื่องจักรก่อสร้าง แล้วถ้ายังไม่มีถนน จะเอาเครื่องจักรก่อสร้างนั้นไปยังไซต์งานได้อย่างไร?
      ไม่กี่เดือนก่อนผมได้พบคนที่ทำงานในสตาร์ทอัพด้านการจัดส่ง/ฟูลฟิลเมนต์วัสดุสำหรับโครงการก่อสร้าง
      งานแบบนี้ต้องใช้ความเชี่ยวชาญต่างจากการจัดส่งทั่วไปแบบ Amazon เพราะวัสดุมักมีคุณสมบัติแปลกหรืออันตราย และปลายทางก็มักยังไม่มีที่อยู่ด้วย
      แก้ได้ก็จริง แต่ดูเหมือนต้องอาศัยความเชี่ยวชาญที่เกินกว่าความสามารถทั่วไปของบริษัทขนส่งสมัยใหม่
    • ผมเคยทำงานในบริษัทที่สร้างดาต้าเซ็นเตอร์ และพยายามทำซอฟต์แวร์ให้ถึงระดับที่สามารถ เริ่มเดินระบบดาต้าเซ็นเตอร์ทั้งแห่ง ได้ด้วยแล็ปท็อปเครื่องเดียว
      เหตุผลคือเพื่อพิสูจน์ต่อหน่วยงานกำกับดูแลว่าไม่มีแบ็กดอร์ เมื่อทำงานร่วมกับบริษัทในยุโรป
      เป็นปัญหาที่น่าสนใจมากแต่ยากมาก และทีมของเราเกี่ยวข้องทางอ้อมเท่านั้น โดยทำงานส่งผ่านข้อมูลผ่านพร็อกซีที่ทำให้ข้อมูลทั้งหมดตรวจสอบย้อนหลังได้ และรับประกันว่าจะไม่ส่งสิ่งที่ไม่ควรส่งออกไป
      ผมออกจากบริษัทก่อนจะเสร็จ และภายหลังได้ยินว่าถูกยกเลิกเพราะยากเกินไป
    • เมื่อดู opcode แบบฐานแปดของแอสเซมบลีใน Cray-1 รุ่นเก่า หรือ word opcode ของ IBM System/360 จะเห็นว่ามันถูกออกแบบให้เรียบง่ายอย่างน่าทึ่ง จนคนสามารถเขียนไบต์ opcode เองและประกอบคำสั่งด้วยมือได้
      ต่อมา x86 ปรากฏขึ้นโดยไม่มีงบประมาณมหาศาลหรือผู้ซื้อรายใหญ่ และออกแบบแอสเซมบลีให้มีประสิทธิภาพและหนาแน่นที่สุดเท่าที่ทำได้
      ผลคือสูญเสียคุณสมบัติที่เครื่องอื่น ๆ เคยมีได้อย่างสบาย ๆ ไป
    • นี่เป็นหนึ่งในจุดที่เจ๋งที่สุดของโปรเจกต์บูตสแตรปแบบนี้และ reproducible builds
      ในทางทฤษฎี เราสามารถสร้างคอมพิวเตอร์ที่เรียบง่ายมากได้เองจากชิ้นส่วนแยก
      มันจะใหญ่ ไม่มีประสิทธิภาพ และช้ามาก แต่สามารถทำให้ทำตาม instruction set architecture เฉพาะได้ และสร้างโปรแกรมบูตสแตรปบนเครื่องนั้นได้
      จากนั้นก็สามารถอ้างได้ว่าผลลัพธ์ที่ได้จากคอมพิวเตอร์แย่ ๆ ที่เราเข้าใจได้ทั้งหมดนั้น เหมือนกับผลลัพธ์ที่ได้จากฮาร์ดแวร์สมัยใหม่ที่เราไม่ได้ไว้วางใจทั้งหมด
    • แม้ในระดับอารยธรรมมนุษย์ก็น่าคิดเหมือนกัน ถ้ามนุษยชาติ somehow ย้อนกลับไปสู่ยุคหิน ณ ตอนนี้ เราจะสร้างกลับมาถึงระดับปัจจุบันได้อีกไหม?
      มันเป็นปัญหาบูตสแตรปอย่างหนึ่ง เช่น แหล่งน้ำมันในปัจจุบันขุดยากกว่าเมื่อ 100 ปีก่อน ผมสงสัยว่าเราจะบูตสแตรปกลับไปถึงจุดนั้นได้หรือไม่

  • ต้องคลิกลิงก์ตามไปถึง 4 ครั้ง เพื่อหาคำอธิบายเชิงภาพรวมว่าการบูตสแตรปมีประโยชน์อย่างไร เลยหงุดหงิดนิดหน่อย
    คาดหวังว่าส่วน “Why” ในชื่อเรื่องจะพูดถึงเรื่องนั้น
    https://bootstrappable.org/benefits.html

    • การอธิบายว่าทำไมการบูตสแตรปจึงสำคัญอาจเป็นเรื่องยาก ผมเลยใส่ ส่วน “Why?” ไว้ใน README ของคอมไพเลอร์บูตสแตรปของผมด้วย
      ความปลอดภัยเป็นเหตุผลใหญ่ และเป็นส่วนที่ทีม bootstrappable เน้นเป็นหลัก
      หากต้องการหลีกเลี่ยงปัญหา trusting trust และการโจมตีอย่างแบ็กดอร์ xz เมื่อไม่นานมานี้ เราต้องสามารถบูตสแตรปทุกอย่างจากซอร์สโค้ดล้วนได้
      พวกเขาลบแม้กระทั่งไฟล์ที่สร้างไว้ล่วงหน้าทั้งหมด เพื่อให้พึ่งพาเฉพาะสิ่งที่เขียนด้วยมือและตรวจสอบได้เท่านั้น เช่น การบูตสแตรป Python จะค่อนข้างซับซ้อน เพราะในซอร์สมีโค้ดที่สร้างโดยสคริปต์ Python อยู่
      ส่วนผมกลับสนใจด้านการอนุรักษ์วัฒนธรรมมากกว่า อยากเก็บรักษาสื่อยุคปัจจุบันไว้ในที่อย่าง Arctic World Archive เพื่อให้นักโบราณคดีในอนาคต แต่ถ้าไม่มีวิธีถอดอ่าน มันก็ไม่มีความหมาย
      เราสามารถเก็บรักษาสเปกไว้ได้ แต่คงคาดหวังไม่ได้ว่าพวกเขาจะ implement x265 และทุกอย่างที่จำเป็นตั้งแต่ศูนย์ ถ้าเก็บรักษาไบนารีไว้ ก็ต้องเปิดฮาร์ดแวร์อายุพันปี หรือจำลอง CPU อายุพันปี
      อาจให้คำนิยาม Lisp แบบเรียบง่ายพร้อมโค้ดที่รันบนนั้นได้ แต่ใครจะไป implement x265 ด้วย Lisp พื้นฐานกัน ไม่ใช่เรื่องสมจริง
      ดังนั้นในโปรเจกต์ของผมจึงสร้าง virtual machine แบบเรียบง่าย แล้วบูตสแตรป C ขึ้นบนนั้น
      พอร์ตไปยังสถาปัตยกรรมปัจจุบัน รวมถึงสถาปัตยกรรมในอนาคตหรือของต่างดาวได้ง่ายมาก นักโบราณคดีในอนาคตหรืออารยธรรมต่างดาวสามารถ implement VM ได้ภายในวันเดียว จากนั้นรันการบูตสแตรป C บนนั้น แล้วคอมไพล์ ffmpeg ฯลฯ เพื่อถอดรหัสสื่อของเราได้
      ไม่มี black box ทุกอย่าง debug ได้ ตรวจสอบได้ และเป็นซอร์สโค้ดเปิดที่เขียนด้วยมือ
      https://github.com/ludocode/onramp?tab=readme-ov-file#why-bo...
      https://en.wikipedia.org/wiki/Arctic_World_Archive

  • ค่อนข้างสับสน เหตุผลที่เริ่มเส้นทางตามชื่อเรื่องเพิ่งโผล่มากลางบทความ ซึ่งใจความคือเมื่อ C++ เข้ามาอยู่ใน chain การบูตสแตรป ก็แทบจะถือว่าการบูตสแตรปจบแล้ว ดังนั้นก่อนถึงจุดนั้น ต่อให้อยากใช้ Rust ก็ไม่มีวิธี
    เลยดูเหมือนว่าจุดประสงค์คืออยากมีคอมไพเลอร์ Rust ที่บูตสแตรปจาก TinyCC ได้บนระบบที่สมมติว่ายังไม่มีเครื่องมือที่มีประโยชน์ โดยเฉพาะคือเขียนด้วย C
    แต่ขัดกับสมมติฐานตอนต้น เพราะ rustc ย้อนกลับไปได้เรื่อย ๆ คือ 1.80.0 คอมไพล์ด้วย 1.79.0, 1.79.0 คอมไพล์ด้วย 1.78.0 ไปจนถึง 0.7 และคอมไพเลอร์ในตอนนั้นเขียนด้วย OCaml
    อีกทั้งยังบอกว่ามีโปรเจกต์ที่คอมไพล์คอมไพเลอร์ OCaml ด้วย Guile ได้สำเร็จ และตัวอินเทอร์พรีเตอร์ Guile ก็เขียนด้วย C
    ถ้าอย่างนั้น เส้นทาง ที่ไม่มี C++ ตามที่ผู้เขียนต้องการก็มีอยู่แล้ว เพียงแต่ไม่ใช่เส้นทางที่ทีม rustc ใช้เป็นประจำเท่านั้น
    สุดท้ายแรงจูงใจจึงไม่ชัดเจน ไม่รู้ว่าต้องการสร้างกระบวนการบูตสแตรปที่ดีกว่าโดยอิง C หรืออยากทำให้มันเป็นวิธีบูตสแตรปประจำวันของ rustc ทำไมถึงอยากตัดขั้น C++ ออก และทำไมถึงชอบขั้น C
    ถ้าแค่ทำเพราะอยากทำก็ไม่เป็นไร แต่แม้อ่านบทความยาวพอสมควรแล้ว ก็ยังไม่ค่อยเข้าใจเป้าหมายอื่นนอกเหนือจากนั้น

    • การบูตสแตรป Rust จาก Guile และคอมไพเลอร์ Rust 0.7 อาจเป็นไปได้ทางเทคนิค แต่ต้องคอมไพล์ คอมไพเลอร์ Rust ซ้ำประมาณ 100 ครั้ง
      แต่ละขั้นใช้เวลาหลายชั่วโมง และเพราะ 1.80 ต้องการ 1.79, 1.79 ต้องการ 1.78 ไล่ไปแบบนี้ จึงข้ามขั้นใด ๆ จนถึง 0.7 ไม่ได้
      ต่อให้ทำให้อัตโนมัติทั้งหมด การบูตสแตรปนี้ก็อาจใช้เวลาหลายเดือน
      ยิ่งกว่านั้น เท่าที่ผมรู้ rustc เวอร์ชันแรก ๆ เอาต์พุตได้เฉพาะ LLVM ดังนั้นสุดท้ายถ้าจะคอมไพล์ LLVM ก็ต้องบูตสแตรปคอมไพเลอร์ C++ อยู่ดี
      ถ้ามีคอมไพเลอร์ C++ แล้ว ก็แค่คอมไพล์ mrustc ก็พอ ปัจจุบัน mrustc รองรับได้ถึง rustc 1.54 เท่านั้น ดังนั้นก็ยังต้องคอมไพล์ผ่านประมาณ 35 เวอร์ชัน
      ทั้งหมดนี้ไม่ใช่กระบวนการที่ใช้งานได้จริง เป้าหมายของ Dozer คือบูตสแตรปคอมไพเลอร์ C ขนาดเล็ก คอมไพล์ Dozer แล้วคอมไพล์ rustc รุ่นล่าสุดโดยตรง
      แบบนั้นจะได้ Rust ทันทีโดยไม่ต้องบูตสแตรป C++ หรือขั้นกลาง ๆ

  • ถ้าสามารถแยก GCC 4 กับ binutils ออกจากสคริปต์บิลด์เดิมได้ ก็น่าจะตัดรายการออกได้ราวครึ่งหนึ่ง
    รายการจำนวนมากในนั้นเป็นแค่การบิลด์ตระกูล autoconf และ dependency ของมันซ้ำไปซ้ำมา
    https://github.com/fosslinux/live-bootstrap/blob/master/part...

  • ไม่ค่อยเข้าใจประเด็น ถ้าจะสร้างไบนารีใหม่ที่ทำงานบนเครื่องเป้าหมาย rustc ก็ต้องรองรับสถาปัตยกรรมเป้าหมาย
    ถ้าเพิ่มการรองรับนั้นเข้าไปใน rustc แล้ว ก็ให้ rustc build ตัวเองไปเลยก็ได้

    • ประเด็นหลักไม่ใช่การรองรับสถาปัตยกรรมใหม่ แต่คือการมีกระบวนการบูตสแตรปที่สั้นกว่ามากและ ตรวจสอบได้

  • บางครั้งก็จินตนาการถึงการเขียน อินเทอร์พรีเตอร์หรือคอมไพเลอร์ C++ ด้วย Scheme
    การไปจาก Scheme ตรง ๆ ถึง GCC ปัจจุบันอาจเป็นทางลัดมหาศาล
    แต่ตามความเข้าใจทั่วไป การเขียนคอมไพเลอร์ C++ แทบจะเป็นไปไม่ได้อยู่แล้ว ถึงอย่างนั้นก็น่าจะช่วยในการเรียนรู้ได้

  • หากมองทั้งสแต็กตั้งแต่ sub-assembler เป็นต้นมา นี่จะเป็นวิธีเลี่ยงปัญหา trusting trust ได้หรือไม่?
    https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

    • จะเป็นไปได้ก็ต่อเมื่อตรวจสอบทุกอย่างและรันกระบวนการทั้งหมดด้วยตัวเอง
      ถึงอย่างนั้นก็ยังมีสิ่งอย่าง https://en.m.wikipedia.org/wiki/Underhanded_C_Contest อยู่ และผลงานบางส่วนในนั้น แม้ฉันจะตรวจสอบเองก็น่าจะพลาดไป
    • นั่นไม่ใช่ประเด็นหลักหรอกหรือ?

  • ตอนเรียน C นิดหน่อย ฉันเคยไปดูว่าผู้คนทำสิ่งที่คล้าย C++ ใน C กันอย่างไร และได้เห็นการอิมพลีเมนต์อย่างอ็อบเจ็กต์, exception, concurrency
    ถ้า mrustc เขียนด้วย C++ การพอร์ตโค้ด C++ ที่ทำงานอยู่ไปเป็น C โดยใช้ primitive แบบ C++ ในสไตล์ C เหล่านั้น น่าจะง่ายกว่าหรือเปล่า?
    ดูเหมือนว่าจะทำได้ด้วยการย้ายทีละนิด โดยใช้ประโยชน์จาก interoperability ที่แข็งแกร่งระหว่าง C++ กับ C
    แน่นอน ฉันรู้ว่านี่เป็นงานพอร์ตที่ยากและมีหลุมพรางมากมาย เพียงแต่ต้องจำไว้ว่าสิ่งที่เอามาเทียบคือการเขียนคอมไพเลอร์ Rust ขึ้นใหม่ด้วย C
    ยังนึกถึงคอมไพเลอร์ C++ to C ที่เคยมีอยู่ในอดีตด้วย ไม่รู้ว่ายังมีอยู่หรือเปล่า
    ทุกวันนี้ Rust to C/C++ และคอมไพเลอร์ C++ to C ที่มนุษย์อ่านได้ ก็น่าจะยังมีประโยชน์ เพราะสามารถผสานข้อดีด้านความปลอดภัยของฝั่งหนึ่งกับระบบนิเวศเครื่องมือของอีกฝั่งได้