+1! Avr rust yang dibangun ke dalam kompiler akan sangat berguna. Ini hampir bebas dari bug sekarang.

Tidak sepenuhnya bebas dari bug :)

Saya akan memperbarui deskripsi untuk memasukkan beberapa informasi tentang status bug backend wrt

Hampir meskipun . Hanya beberapa untuk pergi

Secara umum kami cukup menyambut platform upstream di rust-lang/rust selama mereka tidak membebani kami dengan pemeliharaan! Beberapa pemikiran spesifik dari apa yang Anda pikirkan:

• LLVM memetik ceri melakukan sesering mungkin benar-benar baik-baik saja, saya pikir Anda semua sudah melalui proses beberapa kali juga :)
• Instrinsik yang hilang di compiler-rt tidak masalah bagi kami, Anda memiliki opsi untuk mengimplementasikannya di Rust juga melalui proyek compiler-builtin.
• Patch yang Anda miliki terlihat cukup bagus, meskipun saya pikir kami ingin bekerja lebih banyak melalui berbagai #[cfg] di libcore. Apakah item ini ditinggalkan karena "bug di LLVM" atau karena pada dasarnya tidak didukung sama sekali di AVR? Yang pertama akan lebih baik dilakukan dengan "memperbaiki LLVM" entah bagaimana sedangkan yang terakhir membuat segalanya lebih rumit.

Secara umum saat ini kami memiliki semua platform dengan antarmuka seragam libcore/libstd yang sama, tetapi tidak jelas apakah itu akan tetap benar karena kami terus mengambil lebih banyak platform.

Patch yang Anda miliki terlihat cukup bagus, meskipun saya pikir kami ingin bekerja lebih banyak melalui berbagai #[cfg] di libcore. Apakah item ini ditinggalkan karena "bug di LLVM" atau karena pada dasarnya tidak didukung sama sekali di AVR?

Itu karena bug di LLVM.

Satu-satunya pertanyaan di benak saya adalah tentang dukungan jenis i128 / u128 - Saya pikir untuk AVR, ini tidak terlalu berguna. Dukungan i128 di libcore saat ini dikomentari karena bug, tetapi mungkin ada bug lain yang belum ditemukan karena ini bukan jalur kode yang teruji dengan baik, dan benar-benar menggunakan pengalokasi register sebagai AVR saja memiliki register tujuan umum senilai 32 byte.

Masih sangat mungkin bahwa kita bisa mendapatkan i128 bekerja di AVR, saya tidak tahu terlalu banyak masalah spesifik yang dipicunya di backend.

Saya pikir cara terbaik ke depan adalah mengusulkan tambalan secara nyata setelah libcore _does_ dikompilasi tanpa modifikasi, atau setidaknya tanpa banyak.

Saya pikir cara terbaik ke depan adalah mengusulkan tambalan secara nyata begitu libcore dikompilasi tanpa modifikasi, atau setidaknya tanpa banyak.

Kedengarannya masuk akal bagi saya!

Satu-satunya pertanyaan di benak saya adalah tentang dukungan untuk tipe i128/u128 - saya pikir untuk AVR, ini tidak terlalu berguna.

Ketakutan utama saya tidak mendukung i128 pada AVR adalah bahwa hal itu akan memiliki efek mengerikan pada adopsi bilangan bulat 128 bit demi kompatibilitas dengan AVR atau platform tertanam lainnya. Misalnya jika ada perpustakaan yang menggunakan bilangan bulat 128 bit, pengguna AVR yang ingin menggunakannya akan mengajukan masalah untuk membatalkan penggunaan. Ini mungkin membuat bilangan bulat 128 bit tidak "aman" untuk digunakan dalam kode Rust yang berusaha untuk portabel, yang saya tidak ingin terjadi.

efek mengerikan pada adopsi bilangan bulat 128 bit demi kompatibilitas dengan AVR atau platform tertanam lainnya

Saya tidak berpikir bahwa itu adalah masalah yang sangat besar di sini. Perangkat tertanam kecil sudah memiliki batasan besar (tidak ada stdin / stdout, umumnya tidak ada pengalokasi, dll.) yang membuatnya sangat sulit untuk hanya memasukkan perpustakaan sewenang-wenang. Baru-baru ini saya mengetahui bahwa double AVR GCC sebenarnya adalah alias untuk float ! Saya tidak tahu apakah kita akan menyimpan keanehan itu atau tidak, tetapi itu akan mempengaruhi peti lebih dari i128 .

Saya pikir kami akan selalu memiliki fitur khusus yang digunakan untuk membuat peti yang cocok untuk disematkan, seperti yang kami lakukan untuk no-std.

tidak ada stdin / stdout, umumnya tidak ada pengalokasi, dll.

Anda menggambarkan ekosistem #![no_std] . Ada perpustakaan yang menargetkan ekosistem ini. Dan aturan umum untuk ekosistem itu adalah untuk menerima libcore sebagai pemberian, yang juga mencakup i128 . Setiap target yang tidak mendukung i128 memiliki efek dingin yang lebih besar di dalam ekosistem ini, karena "pangsa pasar" target yang disematkan lebih besar di dalam subset dari seluruh ekosistem Rust di mana keluarga x86 bukanlah pemain yang sangat relevan .

Saya tidak tahu apakah kita akan menyimpan keanehan itu atau tidak, tetapi itu akan mempengaruhi peti lebih dari i128.

Menarik! Saya setuju bahwa jika kita akan alias f64 ke f32 (atau tidak memberikannya), itu akan lebih mempengaruhi ekosistem. Namun, jika kita bisa berjuang untuk konsistensi, mengapa kita tidak? Sangat mungkin bagi kita untuk mengimplementasikan i128 .

Sangat mungkin bagi kami untuk mengimplementasikan i128.

Tentu saja, dan saya menyadari bahwa saya tidak secara jelas menyatakan bahwa saya pikir kita harus mengimplementasikan i128 untuk AVR . Namun, kode apa pun yang benar - i128 pada AVR akan berada di dunia yang menyakitkan.

Namun, jika kita bisa berjuang untuk konsistensi, mengapa kita tidak?

Konsistensi dengan apa , adalah pertanyaannya. Konsistensi dengan GCC ( f64 == f32 ) atau dengan setiap target Rust lainnya ( f64 != f32 )?

Anda menggambarkan ekosistem #![no_std].

Ya, itulah mengapa saya mengatakan "fitur khusus yang digunakan untuk membuat peti yang cocok untuk disematkan, seperti yang kami lakukan untuk no-std." 😇

Masalah yang lebih besar yang ada di benak saya sejak kami awalnya mendaratkan tambalan usize 16-bit adalah bahwa, pada dasarnya, pemrogram Rust dan Rust cenderung menganggap bahwa usize adalah "asli" ukuran register. AFAIK, ini berlaku untuk semua target platform Rust lainnya, tetapi tidak untuk AVR.

Konsistensi dengan apa, itulah pertanyaannya. Konsistensi dengan GCC (f64 == f32) atau dengan setiap target Rust lainnya (f64 != f32)?

Nama f64 secara harfiah menunjukkan bahwa ia memiliki 64 bit. Jika Anda tidak mematuhi nama maka itu menjadi tidak berarti seperti di C.

Poin bagus di sini, saya bisa melihat kekhawatiran di sekitar bilangan bulat 128-bit. Saya benar-benar berpikir bahwa mereka harus didukung, meskipun kita tidak boleh mendorong penggunaannya. Saya tidak suka melihat peti harus menambahkan tanda fitur untuk hal-hal seperti sifat impls pada tipe i128 . Ini seharusnya tidak menjadi masalah karena semua barang i128 yang tidak digunakan harus dipangkas oleh tautan.

Masalah f32/64 adalah masalah yang menarik. Perhatian utama saya dengan membuat f64 sebenarnya 64-bit adalah bahwa itu berarti C FFI bisa sangat rapuh. Jika pengembang tidak mengetahui bahwa AVR-GCC menggunakan double 32-bit, maka panggilan melalui FFI dapat membaca memori atau segfault yang tidak diinisialisasi.

Saya membayangkan kita bisa menyelesaikan ini kurang lebih dengan mengharapkan pengguna menggunakan tipe dari peti libc sebagai gantinya. Kita dapat menambahkan fungsionalitas khusus AVR untuk menyetel c_double ke f32 . Saya pikir kita dapat mengharapkan orang untuk menggunakan peti libc dalam ikatan FFI mereka.

Sesuatu yang perlu diingat untuk penggabungan, perlu memperbarui jenis c_int digunakan dalam tanda tangan main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Sunting: membuka masalah untuk ini karena memengaruhi MSP430 juga: https://github.com/rust-lang/rust/issues/44934

digunakan dalam tanda tangan main()

@mattico Mungkin saya baru saja melakukan sesuatu dengan cara yang aneh, tetapi tidak ada kode saya yang menggunakan main Rust :

#[no_mangle]
pub extern fn main() {

Lebih penting lagi, kita tidak bisa benar-benar kembali karena tidak ada yang kembali ke. Setiap program harus berjalan selamanya.

@mattico Kami masih harus memodifikasi libc sehingga jenisnya cocok dengan GCC untuk AVR

Oh, tentu saja, saya hanya tidak tahu bahwa main akan mempengaruhi kita sama sekali.

@shepmaster Bahkan pada platform non-embedded, ukuran argc di main tidak masalah mengingat kami telah melakukan kesalahan selama ini dan tidak ada yang memperhatikan kecuali saat memeriksa IR. Mungkin ada beberapa RTOS yang menggunakan titik masuk main() standar untuk prosesnya? Terlepas dari itu, cukup mudah untuk memperbaikinya.

Mungkin akan memakan waktu yang sama untuk mengirimkan perbaikan seperti yang dilakukan untuk mengetik ini, sekarang aku memikirkannya

Apakah hanya masalah libcore yang mencegah penggabungan ini? Supaya kita tahu di mana harus memusatkan upaya.

Satu-satunya masalah yang saya alami dari libcore adalah kesalahan tautan aneh yang disebabkan oleh saya tidak tahu apa dan juga kesalahan bitshifting 32 bit (saya pikir hilang intrinsik). Saya tidak tahu apakah itu memblokir penggabungan.

chocol4te: Apakah hanya masalah libcore yang mencegah penggabungan ini? Supaya kita tahu di mana harus memusatkan upaya.

Ya - semua pekerjaan yang diperlukan di sini harus dilakukan dalam LLVM .

Restioson: Satu-satunya masalah yang saya alami dari libcore adalah kesalahan tautan aneh yang disebabkan oleh saya tidak tahu apa dan juga kesalahan bitshifting 32 bit (saya pikir intrinsik hilang).

Itu karena semua kode yang membuat backend choke AVR dikomentari :)

Restioson: Saya tidak tahu apakah itu memblokir penggabungan.

Tidak secara langsung, tetapi akan lebih baik untuk memperbaikinya sebelum backend digabungkan. Ada beberapa bug yang sangat mengganggu seperti ini yang harus kami perbaiki sebelum kami bergabung, tetapi mereka mungkin tidak menahannya.

@dylanmckay LLVM6 telah digabungkan https://github.com/rust-lang/rust/pull/47828 - apa artinya itu bagi RFC ini?

@kellerkindt semua masalah yang tercantum dalam "Masalah saat ini di backend AVR" masih benar. Kemungkinan HEAD avr-rust saat ini dapat di-rebase dan kode khusus Rust yang menarik digabungkan, tetapi itu masih tidak mendapatkan kode yang berfungsi.

Saya pribadi masih mendukung

Saya pikir cara terbaik ke depan adalah mengusulkan tambalan secara nyata begitu libcore dikompilasi tanpa modifikasi, atau setidaknya tanpa banyak.

Meskipun harus menghindari rebasing ekstra itu bagus.

Saya ingin tahu keadaan Rust pada AVR saat ini, sekarang kami setengah tahun kemudian dalam pengembangan. Saya menjalankan grup proyek Arduino kecil di kota saya, dan saya ingin _suka_ dapat menggunakan Rust sebagai gantinya.

Jadi, kabar baik!

Saya pikir cara terbaik ke depan adalah mengusulkan tambalan secara nyata begitu libcore dikompilasi tanpa modifikasi, atau setidaknya tanpa banyak.

Sekarang ini masalahnya!

Garpu avr-rust saat ini tidak mengandung modifikasi apa pun pada libcore .

Modifikasi yang diperlukan untuk mendukung AVR dari stock Rus adalah:

• Fungsi inisialisasi backend AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} dideklarasikan dan dipanggil.
• Spesifikasi target avr minimum dasar avr-unknown-unknown telah ditambahkan. Ini memodelkan perilaku default avr-gcc dalam membangun untuk common denominator terendah kecuali jika ditentukan secara eksplisit. Tidak seperti avr-gcc yang secara eksplisit mendukung argumen -mmcu=<avr mcu name> , tidak ada argumen baris perintah khusus AVR yang ditambahkan untuk AVR. Ini berarti bahwa file JSON spesifikasi target khusus harus ditulis untuk setiap proyek. Ini adalah kasus untuk banyak proyek yang disematkan Rust.
• Di fork, backend AVR LLVM selalu dikompilasi dan ditautkan di default Rust checkout dan ditambahkan ke file config.toml.example . Haruskah AVR disertakan dalam Rust hulu secara default, atau haruskah itu juga ikut serta?
• Logika khusus AVR ditambahkan ke kompiler jika diperlukan untuk semua target baru
• Konvensi pemanggilan "avr-interrupt" telah ditambahkan. Ini memungkinkan extern "avr-interrupt" fn my_isr_handler() { .. } . Ini mungkin perlu melalui proses RFC untuk menjadi stabil, tetapi saya bisa saja salah.
• Dukungan untuk kompilasi bersyarat pada CPU, a la #[cfg(target_cpu = "...")] telah ditambahkan. Implementasinya dapat ditemukan di sini . Implementasi ini tidak bergantung pada target, dan karenanya berfungsi untuk kompilasi bersyarat berdasarkan CPU untuk arsitektur lain juga, seperti ARM. Hal ini memungkinkan peti ruduino kondisional menyertakan modul khusus perangkat yang memaparkan semua IO, register, dan modul yang didukung dalam silikon. Ini pasti harus melalui proses RFC sebelum upstream.

Mungkin sudah waktunya saya mengirim RFC ke LLVM-dev terkait promosi backend ke status non-eksperimental.

Anda dapat melihat set lengkap perubahan dari upstream Rust ke avr-rust di sini .

Masih ada beberapa tambalan LLVM dari dua bulan terakhir yang kami pilih saat ini, tetapi upaya Rust hulu untuk memisahkan versi emscripten LLVM dari versi LLVM yang digunakan untuk semua target lain telah membuatnya sangat mudah untuk dibawa. perubahan ini dari rust-lang/llvm repo, karena sekarang diperbarui secara berkala.

Patch LLVM <4 cherry-picked yang kami miliki saat ini sedang ditinjau di LLVM upstream, dan begitu peninjau menemukan waktu yang cukup, patch tersebut akan secara otomatis melayang ke Rust upstream. Upstream Rust juga memiliki patch spesifik Rust yang spesifik untuk target, sehingga patch LLVM yang dipilih dengan cermat mungkin tidak benar-benar menjadi penghalang untuk menggabungkan avr-rust upstream

Ada update status Rust di AVR?

Juga tertarik untuk tahu! Untuk saat ini saya beralih ke peretasan pada pil biru STM32, tetapi saya pasti ingin kembali ke arduino setelah dukungan untuk avr in rust siap.

Kami @slowtec juga ingin menggunakan Rust untuk proyek AVR kami dan tentu saja kami akan membuka banyak kode produksi kami :)

Bump, akan senang melihat dukungan dibuat resmi. Akan mencoba menggunakan garpu untuk sebuah proyek.

Pembaruan: Saat ini, kami sedang mengupgrade fork ke versi Rust yang lebih baru (avr-rust/rust#137). Ada dua bug yang kami temukan yang kami temukan.

LLVM ERROR: kehabisan register selama alokasi register

Ini telah diperbaiki di LLVM trunk di llvm/ llvm-project@45eb4c7e55341c0b83a21dedecc092e273795eda. Saya memilih ini ke dalam garpu LLVM kami sekarang. Bug ini secara historis merupakan titik nyeri terbesar di backend, yang muncul di sebagian besar kode pointer-berat.

LLVM ERROR: Tidak dapat memilih: t2: i16 = addrspacecast[1 -> 0] undef:i16
t1: i16 = undef
Dalam fungsi: _ZN4core3ptr87_$LT$impl$u20$core..fmt..Debug$u20$for$u20$unsafe$u20$fn$LP$A$RP$$u20$.$GT$$u20$Ret$GT $3fmt17h0fdf8ca7140def9b

Yang ini lebih sulit untuk diperbaiki. Hal ini disebabkan oleh Rust salah menangani pointer fungsi pada arsitektur Harvard dimana terdapat dua ruang alamat pointer yang terpisah untuk mengakses memori utama dan memori program.

Penjelasannya paling baik dibuat oleh @ecstatic-morse

Masalah mendasarnya adalah *const T selalu memiliki addrspace(0). Saya pikir pemeran eksplisit (ptr as *const T) harus mempertahankan ruang alamat input mereka di sini.

Bug tersebut diekspos oleh implementasi std::fmt::Debug untuk fungsi dan pointer fungsi. Rust memancarkan dereferensi pointer dengan tipe pointer target addrspace(0)* i16 , menggunakan rutinitas LLVM yang secara implisit akan menyisipkan bitcast (iN -> iM bit) atau cast ruang alamat jika perlu. Dalam hal pointer fungsi, Rust harus mengkodekan pointer addrspace(1)* i16 , sehingga LLVM tidak harus memetakan ( addrspacecast ) pointer PROGMEM ke pointer RAM tugas yang mustahil karena tidak ada pemetaan memori dan ruang alamat tidak tumpang tindih.

Bug ini adalah pemblokir utama.

Saya berharap hulu Rust menarik dari LLVM master (AFAICT, ini cukup banyak pada rilis 8.0) sehingga kami dapat menghapus banyak pilihan ceri.

Saya baru-baru ini mendapatkan tes https://github.com/dylanmckay/avr-compiler-integration-tests/ yang berhasil menggunakan emulator AVR, yang sangat bagus karena tidak ada rangkaian uji lain yang benar-benar mengeksekusi rakitan AVR yang dimuntahkan oleh LLVM. Saya menyiapkan pelari GitLab untuk menjalankan tes untuk setiap komit AVR-Rust (melalui cermin repositori GitLab), tetapi itu tidak terlalu berguna karena GitLab tidak mendukung pembuatan CI berdasarkan permintaan tarik, karena kode sebenarnya di-host di gudang bercabang.

Terima kasih atas pembaruannya @dylanmckay. Kami semua menghargai upaya yang telah Anda lakukan untuk ini.

Kami sekarang telah meningkatkan fork di atas Rust base rust-lang/ rust@fb7cca33f , program blink berhasil dikompilasi.

Apakah masalah ini terhenti?

Apakah Anda memiliki pembaruan tentang ini? Apakah PR masih mandek pada masalah address space?

Hai @dylanmckay , maaf mengganggu ini.. apakah ada pembaruan tentang masalah ini?

Halo semua, ini beberapa komentar dari saya

Perbaikan memetik ceri

Hampir semua perbaikan yang diperlukan untuk mendapatkan libcore bekerja telah di-upstream ke master LLVM dan saat ini ada di fork rust-lang/llvm. Kemarin saya memulai PR untuk memperbarui garpu AVR ke 1.39.0 (avr-rust/rust#155), saya hanya perlu memilih satu perbaikan yang belum ada - avr-rust/ llvm@4350776601bc671e6e055bfbe32add34b70d2635.

libcore tidak dapat dikompilasi tanpa modifikasi

Kami tidak lagi memerlukan garpu libcore khusus untuk menggunakan AVR. Saat ini hanya ada satu modifikasi pada libcore pada fork avr-rust - avr-rust/ rust@44240ac59c5949b8a9fd191f5cd666d0206fbe85 - tulis ulang cast pointer untuk mendapatkan pembangkitan IR yang tepat.

Kami bergantung pada xargo untuk mengkompilasi binari AVR-Rust - ini akan menjadi lebih mudah dengan inisiatif Kargo std-aware yang sedang berlangsung (termasuk kelompok kerja). Saat ini, AVR memerlukan sysroot yang dikompilasi untuk setiap jenis MCU - kami menggunakan Xargo saat ini untuk mengkompilasinya dengan malas, tetapi akan jauh lebih mulus ketika Cargo dapat mengkompilasi core/std secara native untuk spesifikasi target yang diinginkan.

Setiap operasi pada pointer fungsi selain RAM akses 'panggilan', bukan memori program (avr-rust#68)

Ini telah diperbaiki.

Pergeseran 32-bit menghasilkan panggilan ke rutin compiler-rt yang tidak ada (avr-llvm/llvm#163)

Ini masih masalah yang menyakitkan. Saya menduga perbaikan terbaik adalah dengan menulis kode penurunan kustom di backend LLVM AVR yang menurunkan pergeseran ini ke Majelis murni, menghapus ketergantungan ABI pada compiler-rt atau libgcc. Saya tidak yakin seberapa besar ukuran kode yang dihasilkan, itu mungkin bukan ide yang baik.

Pertanyaan sebelum upstream

RFC dan konvensi panggilan yang tidak stabil

Saya memposting komentar ini di utas

Konvensi panggilan "avr-interrupt" telah ditambahkan. Hal ini memungkinkan extern "avr-interrupt" fn my_isr_handler() { .. }. Ini mungkin perlu melalui proses RFC untuk menjadi stabil, tetapi saya bisa saja salah.

Bisakah konvensi panggilan yang tidak stabil ditambahkan tanpa melalui proses RFC?

Saat ini, kami memiliki "avr-interrupt" dan "avr-non-blocking-interrupt" bawah gerbang fitur #![feature(abi_avr_interrupt)] . Bisakah ini di-upstream sebagai konvensi panggilan yang tidak stabil, sambil menunggu RFC stabilisasi di masa mendatang?

Buildbots

Upstreaming backend LLVM memerlukan penyiapan buildbot khusus yang menjalankan pengujian untuk backend itu, dan memeliharanya. Apakah ini kasus dengan Rust? Bagaimana kami memastikan bahwa rangkaian pengujian berjalan dalam mode AVR pada setiap dorongan? Apa yang dilakukan backend lain (seperti WASM)?

Distribusi

Apakah "Menggabungkan fork avr-rust upstream" berarti hanya menggabungkan dua fork menjadi satu, tetapi masih memerlukan build-from-source? Mungkinkah backend dapat didistribusikan, tetapi hanya pada malam hari? Apa yang dilakukan backend lainnya?

Selain itu, tambalan khusus avr-rust sangat tipis, tanpa peretasan yang parah saat ini.

Patchset lengkapnya bisa dilihat disini https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support

Patchset rebase WIP 1.39.0 saya (yang sebagian besar identik) dapat ditemukan di sini https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support-1.39.0-4560ea788c . Ini harus digabungkan ke avr-rust/master dalam beberapa hari ke depan.

Saya tidak dapat memikirkan sesuatu yang spesifik yang menghalangi ini - mungkin, inilah saatnya untuk mengirimkan tambalan dan melihat bagaimana kelanjutannya?

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

Saya menyebutkan masalah ini di atas, tetapi saya tidak berpikir itu menghalangi upstreaming dari backend AVR. Kita seharusnya bisa mendapatkan versi rustc yang berfungsi dan berguna dengan AVR tanpa itu. Saya yakin ada solusi dan peretasan yang bisa kita lakukan kembali. deteksi perangkat di peti AVR sementara itu setelah backend secara hipotetis digabungkan, dan sebelum API kueri target-cpu resmi mendarat di Rust resmi.

Dia hidup! Terima kasih atas pembaruannya @dylanmckay , kemajuan yang menggembirakan.

Kerja bagus @dylanmckay! Terima kasih telah memberi tahu kami.

Agak di luar topik, tetapi: apakah rustc untuk avr dapat melakukan FFI dengan pustaka C?
Ada banyak perpustakaan dewasa yang sudah tersedia untuk avr tetapi ditulis dalam C/C++.
Akan sangat bagus untuk dapat membuat beberapa pembungkus bergaya karat untuk mereka dan menggunakannya kembali dalam proyek rust avr kami.

Rust sudah bisa melakukan FFI dengan C pada umumnya.

Ya dan itu sangat bagus! Pertanyaannya adalah: apakah itu diterjemahkan ke rust-avr?

Selama C ABI LLVM untuk AVR cocok dengan gcc, itu akan berfungsi

Bisakah konvensi panggilan yang tidak stabil ditambahkan tanpa melalui proses RFC?

Pilihan saya adalah ya , karena perubahan untuk mendukung konvensi panggilan AVR pada dasarnya hanya memberi mereka nama dan memetakannya ke nomor LLVM. Tidak ada perubahan kode mendasar yang diperlukan karena kami sudah memiliki dukungan untuk konvensi yang tidak stabil.

Upstreaming backend LLVM memerlukan penyiapan buildbot khusus yang menjalankan pengujian untuk backend itu, dan memeliharanya. Apakah ini kasus dengan Rust? Bagaimana kami memastikan bahwa rangkaian pengujian berjalan dalam mode AVR pada setiap dorongan? Apa yang dilakukan backend lain (seperti WASM)?

Sistem tingkat Rust agak longgar, tetapi saya pikir hal yang benar adalah menggabungkan kode khusus AVR . Kemudian AVR akan menjadi tier 3 yang artinya tidak otomatis dibangun atau diuji, hanya nongkrong di kode. Paling tidak, ini berarti bahwa file-file itu akan terus diperbarui dengan perubahan kompiler.

Apakah "Menggabungkan fork avr-rust upstream" berarti hanya menggabungkan dua fork menjadi satu, tetapi masih memerlukan build-from-source?

Sepengetahuan saya, itu akan menyerahkan satu komit sebagai PR. Garpu kustom kami secara efektif akan mati / menjadi tempat untuk melacak detail spesifik AVR hingga menjadi target yang lebih banyak digunakan.

mungkin, sudah waktunya untuk mengirimkan tambalan

Aku pikir begitu.

@edvorg sangat sesuai dengan topik IMO

Agak di luar topik, tetapi: apakah rustc untuk avr dapat melakukan FFI dengan pustaka C?
Ada banyak perpustakaan dewasa yang sudah tersedia untuk avr tetapi ditulis dalam C/C++.

Ya.. kebanyakan. Konvensi pemanggilan AVR yang diterapkan oleh backend AVR dirancang agar sesuai dengan AVR-GCC (didokumentasikan di sini ). Ada beberapa keanehan, tetapi LLVM patch D68524 yang perlu saya tinjau harus memperbaikinya.

Situs panggilan Rust akan selalu dapat memanggil fungsi terkompilasi Rust atau avr-clang dengan benar (karena avr-clang C menggunakan implementasi konvensi pemanggilan extern "C" sama seperti frontend Rust), dan antar operasi dengan AVR-GCC _harus_ bekerja, terutama untuk tanda tangan fungsi sederhana, tetapi kadang-kadang bisa tersedak (lihat deskripsi D68524 untuk lebih jelasnya).

Ada pembaruan tentang ini?
Hanya penasaran.

Permintaan yang diajukan untuk menjadikan backend LLVM AVR sebagai backend resmi - https://reviews.llvm.org/D75099

@dylanmckay Jika diterima, apa bagian yang tersisa untuk menutup masalah ini?

@dylanmckay Jika diterima, apa bagian yang tersisa untuk menutup masalah ini?

Secara teknis, Rust akan bekerja dengan backend resmi dan eksperimental. Saya telah mengangkat #69478 untuk upstreaming sebagian besar backend.

Saya tidak yakin apakah menggabungkan AVR sebagai target Tingkat 3 didasarkan pada AVR menjadi backend LLVM resmi - selamat datang.

Memikirkannya, perbedaan resmi versus eksperimental LLVM dapat dipetakan ke sistem tingkat Rust, di mana Rust memiliki tiga tingkat dan LLVM memiliki dua. Backend resmi LLVM sesuai dengan campuran Tingkat 1 dan 2 - pada dasarnya, termasuk dalam suite pengujian dan rilis resmi. Sebuah backend eksperimental LLVM, sejauh yang saya tahu, secara semantik sama dengan backend Rust Tier 3; disertakan dalam pohon sumber, tidak disertakan dalam rilis secara default, tidak disertakan dalam pengujian CI default, dll.

Maka saya kira satu-satunya bagian yang tersisa untuk menutup masalah ini adalah yang muncul dalam tinjauan kode #69478.

tl;dr backend AVR akan menjadi target hulu Tier 3 di rust-lang/rust#69478 jika digabungkan, sehingga menghentikan fork.

Satu-satunya perbedaan antara fork avr-rust/rust dan #69478 adalah flag target_cpu cfg yang ada di fork AVR tetapi tidak di upstream. Saya telah meninggalkan itu dari PR awal.

apa sisa potongannya?

Saya cukup yakin masih ada sejumlah kesalahan kompilasi dari berbagai jenis kode, sehingga masih membutuhkan lebih banyak orang untuk mencoba berbagai hal dan meminimalkan bug dan memperbaikinya.

Menjadi upsteamed akan menurunkan standar untuk membuat orang mencoba berbagai hal, karena mereka hanya bisa mendapatkan Rust reguler setiap malam alih-alih menyusun garpu yang biasanya kedaluwarsa.

Setelah di-upstream sebagai target tingkat 3, apakah pengembangan AVR akan bekerja dengan fitur -Z build-std kargo, atau akankah memerlukan xargo? Apakah LLD yang dikirimkan dengan Rust memiliki dukungan AVR, atau akankah tautan gnu diperlukan?

apakah pengembangan AVR akan bekerja dengan fitur -Z build-std kargo, atau akankah memerlukan xargo? Apakah LLD yang dikirimkan dengan Rust memiliki dukungan AVR, atau akankah tautan gnu diperlukan?

Saya tidak bisa mengatakan itu tidak akan berhasil, tetapi semua yang saya lakukan telah menggunakan tautan Xargo dan GNU.

Penaut GNU sulit diatur di Windows dan xargo memerlukan satu alat lagi untuk dipasang, itulah mengapa saya bertanya.

Apakah LLD yang dikirimkan dengan Rust memiliki dukungan AVR, atau akankah tautan gnu diperlukan?

LLD hanya memiliki dukungan yang sangat mendasar untuk menautkan AVR, ia belum dapat menautkan program nyata apa pun. Oleh karena itu, avr-ld akan diperlukan.

makanya saya bertanya.

Jangan salah, saya juga berpikir itu adalah tujuan akhir yang benar, hanya saja mungkin bukan keadaan dunia saat ini. Sejujurnya, saya akan senang untuk membuat overhead lebih rendah dan lebih rendah. Menggabungkannya hanyalah langkah pertama menuju itu.

Backend AVR sekarang telah diaktifkan sebagai target LLVM resmi :tada: LLVM master berisi dukungan AVR secara default sekarang. Rilis LLVM pertama yang menyertakan AVR secara default akan menjadi LLVM 11 dalam waktu sekitar 6 bulan.

Bagus! Terima kasih atas semua upaya yang Anda lakukan untuk ini.

Sangat keren!

Selamat @dylanmckay atas pencapaian luar biasa ini. Komunitas berterima kasih atas kerja Anda dalam hal ini.

Saya telah mengikuti masalah ini untuk sementara waktu sekarang dan sementara saya tahu ini sebagian besar di luar topik, saya tertarik apa artinya ini bagi pengguna rata-rata-bukan-dari-sumber ... Apakah ini proses yang rumit untuk mendapatkan Arduino Uno aktif dan berjalan dengan Rust asli menggunakan ini? Saya paling tertarik dengan ini karena Rust memiliki perlindungan yang cukup. Saya mungkin tidak dapat menyebabkan momen oops sebanyak xP

@ Jimmio92 Dari apa yang saya tahu, ya. Seperti dalam "ya, itu rumit". Atau setidaknya panjang dan membosankan, meskipun tidak terlalu rumit, karena Anda masih harus membuat garpu kustom kompiler Rust ini dari sumber, yang juga memerlukan pembuatan LLVM dari sumber. Itu biasanya memakan waktu beberapa jam, jika semuanya berjalan dengan baik.

_{Pengalaman pribadi saya dengan LLVM adalah, bagaimanapun, bahwa lebih sering daripada tidak, itu hanya tidak menyukai sesuatu di sistem Anda (setidaknya pasti di macOS - lebih mudah di Linux dan tentu saja bahkan tidak bermimpi melakukan ini di Windows), jadi Anda akhirnya akan memijat jalur instal dan perpustakaan khusus sampai Anda berhasil atau menyerah.}

Yang dimaksud dengan berita (luar biasa) di atas hanyalah ini: pengembang LLVM sekarang menargetkan/mendukung AVR secara resmi (?), dan rilis LLVM berikutnya akan menyertakan dukungan AVR. Tidak ada yang mengatakan bahwa Rust sekarang juga mendukung atau akan mendukung AVR dalam jangka pendek. Jika Anda melihat masalah dan komentar di atas, Anda dapat melihat bahwa itu akan membutuhkan banyak pekerjaan sampai dukungan AVR "berfungsi" dengan rantai alat Rust stok.

Apakah ada proses/contoh yang bisa saya lihat pada perbaikan AVR pemetik ceri dari master LLVM ke garpu Rust LLVM?

Juga, apakah Rust masih melacak master LLVM? Dari kelihatannya, itu melacak rilis saat ini ditambah beberapa perbaikan yang dipilih ceri. Apakah PR untuk memperbarui versi LLVM ke master masih diterima?

@dylanmckay

Juga, apakah Rust masih melacak master LLVM?

Seperti yang Anda perhatikan, ini melacak rilis sekarang.

Apakah PR untuk memperbarui versi LLVM ke master masih diterima?

Saya rasa tidak, tapi cc @nikic

@dylanmckay ada banyak perbaikan pada garpu LLVM Rust dibandingkan dengan rilis 10.0: https://github.com/rust-lang/llvm-project/commits/rustc/10,0-2020-05-05

Apakah ada proses/contoh yang bisa saya lihat pada perbaikan AVR pemetik ceri dari master LLVM ke garpu Rust LLVM?

Ada instruksi yang tersedia di sini: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

Juga, apakah Rust masih melacak master LLVM? Dari kelihatannya, itu melacak rilis saat ini ditambah beberapa perbaikan yang dipilih ceri. Apakah PR untuk memperbarui versi LLVM ke master masih diterima?

Rust saat ini melacak rilis LLVM, karena ini memungkinkan orang untuk dengan mudah melakukan LTO lintas bahasa dengan versi dentang yang sesuai. Jadi jawaban default di sini mungkin "tidak".

Yang mengatakan, telah ada beberapa diskusi tentang memperbarui ke master LLVM untuk mengurangi regresi waktu kompilasi LLVM 10. Saat ini saya sedang mengerjakannya untuk tujuan evaluasi. Saya pikir lebih aman untuk berasumsi bahwa ini tidak akan terjadi, dan mengirimkan cherry-picks terhadap garpu LLVM 10 kami (apakah ada banyak?)

Garpu telah digabungkan! Saya akan menulis pembaruan yang tepat sore ini

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

Saya akan menulis pembaruan yang tepat sore ini

Saya tertarik dengan pembaruan tersebut. Di mana Anda berencana untuk mempostingnya @dylanmckay (jadi saya tahu di mana mencarinya :slightly_smiling_face :)?

Saya sudah tidak sabar menunggu tambahan ini ke ekosistem Rust selama bertahun-tahun sekarang! Namun upaya naif saya untuk menggunakan ini pada master tampaknya cacat.

Saya membuat master rust dengan standar ./x.py build , ditautkan sebagai toolchain master , kemudian mencoba membuat contoh avr-rust/blink (setelah memperbarui src/main.rs untuk menggunakan llvm_asm! ):

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

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

Ini gagal dengan:

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

Saya berasumsi masih ada konfigurasi yang saya lewatkan.

@nixpulvis lihat https://github.com/rust-lang/rust/issues/44052#issuecomment -591396417

Saya tidak akan berharap banyak dari apa pun untuk berfungsi sekarang karena libcore adalah bagian dari apa yang salah dikompilasi.

Garpu rustc AVR telah digabungkan ke hulu.

Garpu hulu belum dapat digunakan secara umum. Ada beberapa hal yang perlu dilakukan terlebih dahulu.

Perbaikan upstream AVR LLVM yang Rust belum perlu dipilih

Untuk menjawab pertanyaan @nikic , ada maksimal 20 komit LLVM yang perlu dipilih.

Saya telah menggunakan skrip untuk secara otomatis memilih _all_ AVR commit dari LLVM upstream ke fork lokal.
Ini adalah palu besar dan akan ada perbaikan yang tidak perlu - ada perbaikan LLVM hulu yang perlu ditarik ke hulu Rust sebelum backend dapat digunakan. mereka perlu disaring dan dipetik ceri ke hulu Rust.

Mengkompilasi program kedip LED AVR dari cabang master Rust hulu

Karena upaya hulu telah berlangsung selama beberapa bulan sekarang, garpu avr-rust hilir
masih menggunakan versi Rust yang sangat lama. Sejak itu setidaknya ada satu perubahan di Rust hulu yang memerlukan generalisasi untuk mendukung AVR tanpa mengenai kesalahan pernyataan LLVM. Saya telah membuka permintaan tarik #73270 untuk memperbaikinya.

Saya tidak yakin apakah ada perubahan lain di Rust hulu yang memerlukan perubahan untuk AVR - kemungkinan tidak.

Setelah program kedipan berfungsi, saya akan memposting pembaruan lain karena pada saat itu, dukungan AVR hulu harus siap digunakan/eksperimen.

Di mana komunikasi AVR harus dilakukan/diposting

@wezm Anda menyampaikan poin bagus - belum tentu ada saluran komunikasi "diberkati" untuk pembaruan. Tiket ini telah dilayani dengan baik, tetapi pasti akan segera ditutup.

Saluran AVR-Rust Gitter adalah pilihan paling alami yang ada. Saya suka ide milis (tapi saya tidak suka ide hosting server email jika memungkinkan). Saluran Gitter memang memiliki diskusi di dalamnya jadi mungkin sesuatu seperti milis akan membantu.
Mungkin menyiapkan blog akan baik untuk memusatkan pengumuman/pembaruan. Saya ingin memiliki "media resmi" sehingga orang yang menginginkan pembaruan kasual tidak ketinggalan. Saya kira sebuah blog membutuhkan pemeriksaan konstan untuk posting baru, sedangkan milis secara inheren memberi tahu
semua orang yang tertarik. Saran diterima.

Pertanyaan-pertanyaan terbuka

• Haruskah masalah GitHub pada fork avr-rust dipindahkan ke repositori Rust upstream?
  ** Terlepas dari itu, masalah baru harus diangkat di repositori hulu - pelacak masalah lama harus dihentikan.
  
  
  
  • Di mana instruksi untuk mengkompilasi Rust dengan AVR harus ditayangkan?
  
  

Hal terpenting untuk masa depan (baca: prioritas)

• Pengemasan dan distribusi binari AVR Rust. Mengkompilasi Rust bisa menjadi sakit kepala besar bagi pengguna biasa,
  banyak distro tampaknya memiliki masalah dari waktu ke waktu dalam alur kerja tertentu. Beberapa kesalahan OOM salah dilaporkan sebagai
  bug kompiler. Hambatan untuk masuk terlalu tinggi dan perlu lebih rendah - cukup unduh dan buka.
  Dilacak oleh https://github.com/avr-rust/rust/issues/162
• Membangun daftar konfigurasi yang "didukung", atau setidaknya diuji. Kami membutuhkan meja (rustc version, Xargo version) jadi
  bahwa perubahan ke API Rust pribadi yang menjadi sandaran Xargo tidak merusak rantai alat AVR Rust saat pemutakhiran.
  Xargo dalam mode pemeliharaan - cargo-xbuild tampaknya cukup terbatas (saya mencobanya beberapa minggu yang lalu, saya tidak dapat mengingat alasannya),
  kita mungkin perlu melakukan fork Xargo. Mungkin lebih baik menambahkan perkakas langsung ke Kargo (ada masalah pelacakan untuk ini).
• Menyiapkan semacam beranda untuk proyek, termasuk tautan untuk mengunduh
• Pengujian integrasi (pada AVR yang ditiru/disimulasikan, pada setiap komit)

Untuk saat ini, saya akan memastikan untuk memposting ulang pembaruan ke masalah GitHub ini, hingga media yang lebih baik dapat ditemukan. Saya akan mempostingnya di Gitter juga.

Mungkin menyiapkan blog akan baik untuk memusatkan pengumuman/pembaruan. Saya ingin memiliki "media resmi" sehingga orang yang menginginkan pembaruan kasual tidak ketinggalan. Saya kira sebuah blog membutuhkan pemeriksaan konstan untuk posting baru, sedangkan milis secara inheren memberi tahu
semua orang yang tertarik. Saran diterima.

Preferensi pribadi saya sangat mendukung blog (dengan RSS feed). Saya pikir blog biasanya muncul lebih baik di hasil mesin pencari dan lebih bagus untuk ditautkan daripada utas milis. Umpan RSS menyelesaikan aspek pemeriksaan/pemberitahuan.

Saya tidak 100% yakin itu tempat terbaik untuk itu, tetapi ada blog WG Tertanam. Mungkin saluran komunikasi yang rendah upaya.

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

Mungkin juga akun Twitter? Hal ini dapat digunakan untuk berbagi posting blog baru (untuk tetap up to date).

Saya pikir kelompok kerja yang disematkan akan dengan senang hati membantu di sini. Kami memiliki akun Twitter @rustembedded dan tentu saja dapat memasukkan berita terkait AVR di buletin juga.

Saya juga telah membuat label O-AVR beberapa waktu lalu, jadi jangan ragu untuk menggunakan pelacak masalah Rust untuk masalah khusus AVR juga (tetapi perlu diingat bahwa ada 1,5 ribu orang yang menonton repo). Selain itu, Anda mungkin ingin berkoordinasi di rust-lang Zulip, karena di situlah sebagian besar tim Rust berada. Kami juga sedang dalam proses meningkatkan "grup target" yang berfokus pada target Rust tertentu (mis. Windows atau Arm), AVR mungkin juga cocok untuk itu. Jangan ragu untuk menghubungi Zulip untuk ini.

Memperbarui.

Ada dua hal yang tersisa sebelum libcore dapat dikompilasi untuk AVR pada cabang stock rust-lang/master:

1. Ada satu permintaan tarik yang memperbaiki serangkaian bug "ruang alamat yang dilemparkan tidak valid" pada AVR, terkait bagaimana pointer fungsi untuk arsitektur Harvard harus ditandai sebagai addrspace(1) dibandingkan dengan target Von-Neumann yang baik-baik saja dengan default Rust saat ini dari addrspace(0) . rust-lang/rust#73270 - saat ini sedang dalam peninjauan kode.

~2. Ada satu bug lain yang memblokir contoh blink agar tidak berfungsi - avr-rust/rust#92. Ada tambalan yang belum di-upstream yang akan memperbaikinya - https://reviews.llvm.org/D68524. Ini akan di-upstream dan kemudian di-ceri ke dalam garpu LLVM Rust segera setelah melewati unit dan tes integrasi.~ telah digabungkan ke LLVM hulu

Setelah kedua hal ini dilakukan, target Rust AVR yang di-upstream akan dapat mengkompilasi kode AVR ke level yang sama dengan fork avr-rust/rust saat ini, dan kemudian kita dapat memulai proses memperbarui contoh blink , arduino peti, dokumentasi, panduan, untuk cabang upstream. Kemudian cabang hulu harus siap untuk penggunaan eksperimental.

Satu lagi TODO:

1. ~Tambahkan pipa AVR untuk sintaks perakitan inline baru di Rust hulu~
   
   
   
   • ~Setelah sintaks perakitan inline baru didukung, peti Arduino harus diperbarui untuk menggunakannya
     
     setelah peti Arduino diperbarui, perbarui peti kedip ke versi baru.~ Kita dapat menggunakan makro lama melalui llvm_asm! untuk saat ini karena masih ada di malam hari.
   
   
2. Patch kebenaran AVR Cherry-pick (kebanyakan Ayke) dari master LLVM ke garpu Rust LLVM hulu (EDIT: PR: https://github.com/rust-lang/llvm-project/pull/66)

Inilah cabang dengan semuanya: https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. Cabang ini cukup untuk mengkompilasi libcore.

Itu dibangun dari hulu rust-lang/master tetapi juga termasuk patch LLVM yang belum di-upstream D68524 , Rust PR yang belum digabungkan rust-lang/rust#73270, dan 46 komitmen terkait AVR dari LLVM hulu secara otomatis dipilih melalui skrip (cabang LLVM: https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate). Perhatikan bahwa tidak semua 46 diperlukan, daftar akhir akan lebih kecil.

Pembaruan : Membuka permintaan tarik yang mencakup semua perbaikan LLVM hulu.

Berikut adalah daftar lengkap dari pekerjaan yang tersisa sebelum program kedipan LED dapat dikompilasi dan dijalankan dengan sukses.

Pekerjaan yang tersisa

• [x] Tanah Rust PR rust-lang/rust#73270 . Permintaan tarikan ini memperbaiki serangkaian bug "ruang alamat yang dilemparkan tidak valid" pada AVR, yang berkaitan dengan bagaimana penunjuk fungsi untuk arsitektur Harvard harus ditandai sebagai addrspace(1) dibandingkan dengan target Von-Neumann yang baik-baik saja dengan default addrspace(0) Rust saat ini. . Saat ini sedang dalam peninjauan kode.
• [x] Tanah Karat LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Ini menarik semua perbaikan AVR yang diperlukan dari LLVM upstream ke fork LLVM Rust. Pada akhirnya, ada ~17~ 16 perbaikan LLVM yang perlu dipilih.
• [x] Land Rust PR rust-lang/rust#73658 yang memperbarui versi submodul LLVM . The Rust compiler docs memiliki petunjuk untuk melakukan hal ini. Saat ini sedang dalam peninjauan kode .
• [x] Land Rust PR ~rust-lang/rust#74625~ rust-lang/rust#74631 . Di 79a42e37084d0 Rust mulai meneruskan argumen --eh-frame-hdr tanpa syarat ke linker. Linker AVR-GCC tidak mendukung flag ini dan kasus khusus untuk menghindari melewatinya ditambahkan untuk AVR, mirip dengan pengecualian yang ada untuk Windows. Solaris, dan UEFI.

Mungkin lebih baik menambahkan perkakas langsung ke Kargo (ada masalah pelacakan untuk ini).

Saya berasumsi ini adalah masalah yang benar: rust-lang/cargo#4959.

cargo build -Z build-std=core telah bekerja dengan baik untuk kasus contoh AVR saya.

@shepmaster yang sepertinya membuat saya lebih dekat, terima kasih! Sepertinya saya terjebak pada hal-hal bitcast sekarang, jadi saya akan menunggu untuk digabungkan (karena saya tampaknya kehilangan file yang diperlukan untuk membangun PR, dan IDK apa yang saya lakukan).

Dalam proses menggunakan -Z build-std=core saya perlu menyediakan target tiga kali lipat, jadi saya menjalankan rustc +master --print target-list | grep avr , dan menemukan avr-unknown-unknown . Tetapi masalah yang diarsipkan avr-llvm/llvm#35 tampaknya membuatnya terdengar seperti triple sebenarnya adalah avr-atmel-none (yang lebih masuk akal bagi saya). Apakah ada sesuatu yang perlu diperbarui di sini, atau saya melewatkan sesuatu?

avr-unknown-unknown benar.

Pertanyaan-pertanyaan terbuka

* 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?

Saya tidak berpikir ini terlalu penting di sisi pengguna. Ini cukup mudah ditemukan melalui ddg dan/atau minggu ini.
Apa pun yang membuatnya lebih mudah bagi para pengembang.

Pertanyaan-pertanyaan terbuka

* 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?

Saya tidak berpikir ini terlalu penting di sisi pengguna. Ini cukup mudah ditemukan melalui ddg dan/atau minggu ini.
Apa pun yang membuatnya lebih mudah bagi para pengembang.

Saya pikir instruksi untuk mengkompilasi Rust dengan AVR harus ada di https://docs.rust-embedded.org/

Baiklah, perbarui waktu.

Semua tambalan yang diperlukan untuk AVR ada di kompiler Rust nightly saat ini mulai dari rustc 1.47.0-nightly (0820e54a8 2020-07-23) nighty hari ini. Kompilator Rust nightly, tanpa modifikasi, sekarang dapat mengkompilasi contoh kedipan LED dengan sukses dan menghasilkan file AVR ELF.

• Halaman arahan proyek baru yang terpusat dibuat di https://avr-rust.com/
• Buku baru - Buku Panduan AVR-Rust telah dibuat, dihosting di halaman GitHub di book.avr-rust.com.
• Repositori fork avr-rust/rust tidak digunakan lagi. Repositori belum diarsipkan karena ada masalah yang harus dimigrasikan sebelum dikunci dan ditutup secara permanen.
• Xargo tidak lagi diperlukan - flag -Z build-std di upstream Rust menggantikan kebutuhannya di AVR. Garpu kargo tidak lagi diperlukan - kargo hulu akan cukup.

Kompiler malam Rust sekarang dapat dianggap sebagai saluran yang direkomendasikan untuk Rust dengan dukungan AVR.

Saya menutup masalah ini sekarang - kami berhasil!

Langkah-langkah untuk melaporkan bug dapat ditemukan di Buku Panduan AVR .

Buku Panduan AVR dan contoh kedipan di https://github.com/avr-rust/blink adalah sumber terbaik untuk mulai menggunakan target.

Terima kasih yang mendalam dan mendalam kepada semua orang yang mendiskusikan dan mendukung proyek melalui upaya upstreaming ini - ini sangat dihargai.

SIRIP

Wow wow wow.

Terima kasih untuk semua orang yang berkontribusi pada ini – saya sudah menantikan hari ini sejak selamanya!

Dylan McKay sebelum porting rust ke avr

Dan kemudian

Terima kasih untuk semua kerja keras pria! :-) Istirahatlah dengan baik!