Rust 1.87.0: 10 лет Rust, анонимные каналы, безопасный вызов встроенных интринсиков

[AbitLogic]

Обновили бы русский rust book, а то там люди до сих пор листают 1.67

[ptr128]

Я уже теряю надежду увидеть в Rust стабильный ABI, вместо костыля abi_stable с extern "C".

Я понимаю, что консольные утилиты можно собирать и со статическим связыванием. Но что-то более-менее серьёзное без динамического связывания нежизнеспособно.

Уже молчу о стандарте языка, который всё более востребован в связи все с более частой необходимостью использовать GCC или форки rustc для компиляции под RISC-V или иные платформы, для которых LLVM по ряду причин не имеет стабильного кодогенератора.

[AbitLogic]

А можно поподробнее чего там llvm не имеет, мы применяем для ARM, пока никаких проблем не встречали, чего там не так с risc-v? А то может пора следить за gccrs, а мужики то и не знают

[ptr128]

А можно поподробнее чего там llvm не имеет, мы применяем для ARM, пока никаких проблем не встречали

С ARM у LLVM всё хорошо, за исключением поддержки сопроцессоров. Но это отдельная история. Тот же PIO в RP2040 можно и на ассемблере программировать. С Integer Divider в RP2040 ситуация хуже, так как совершенно непонятно, как в Rust отсчитать восемь тактов.

Куда веселее, когда в CPU/SoC ядра и ARM, и RISC-V.

чего там не так с risc-v?

Если упрощенно, то или поддержка экспериментальная (как у E), или через ассемблер (как у H и Q).

Если копнуть глубже, то есть проблемы с оптимизацией. Например, IR в LLVM хорошо ложится на флаги (ZNCV), которые есть в ARM и amd64, но которых в принципе нет в RISC-V.

Если упрощенно, то выражение if a > b { ... } else { ... } ; при целочисленных a и b для IR две команды, а для RISC-V - одна.

По этой причине, например, Milk-V предлагают GCC toolchain.

Для Espressif тоже есть тонкости. Требуется:

• Espressif Rust fork with support for Espressif targets

• nightly toolchain with support for RISC-V targets

• LLVM fork with support for Xtensa targets

• GCC toolchain that links the final binary

может пора следить за gccrs

Они неизбежно отстают от rustc, разработчики которого считают rustc референсной реализацией Rust, что особенно заметно при попытке использовать std library. В случае no_std явных проблем нет.

Например, ESP32-C5 rustc вообще пока не поддерживается и судьба его неясна, так как в LLVM поддержки Xhwlp нет даже в планах, а Zcmt поддерживается только ассемблером. При этом Espressif кодогенератор GCC для него уже опубликовал, следовательно gccrs должен работать. Но я не пробовал, так как ESP32-C5 официально стал доступен только с 1 мая 2025 года.