+1! Avr rust, встроенный в компилятор, был бы очень полезен. Теперь в нем почти нет ошибок.

Не совсем без ошибок :)

Я обновлю описание, чтобы включить в него некоторую информацию о состоянии ошибок серверной части.

Почти хоть. Осталась пара

В целом, мы очень приветствуем платформы, расположенные выше по течению в ржавчине / ржавчине, если они не возлагают на нас бремя обслуживания! Некоторые конкретные мысли из того, о чем вы думаете:

• LLVM, выбирающий вишню, время от времени совершает коммиты - это нормально, я думаю, вы все уже прошли через этот процесс несколько раз :)
• Отсутствие встроенных функций в compiler-rt нас устраивает, у вас есть возможность реализовать их в Rust также через проект compiler-builtins.
• Патч, который у вас есть, выглядит довольно хорошо, хотя я думаю, что мы хотели бы больше поработать с различными #[cfg] в libcore. Эти элементы упущены из-за «ошибок в LLVM» или потому, что они принципиально не поддерживаются AVR? Первое лучше всего было бы сделать, как-то «исправив LLVM», тогда как второе усложняет задачу.

В общем, в настоящее время у нас есть все платформы с одним и тем же унифицированным интерфейсом libcore / libstd, но неясно, что останется верным, поскольку мы продолжаем набирать больше платформ.

Патч, который у вас есть, выглядит довольно хорошо, хотя я думаю, что мы хотели бы больше поработать с различными # [cfg] в libcore. Эти элементы упущены из-за «ошибок в LLVM» или потому, что они принципиально не поддерживаются AVR?

Это из-за ошибок в LLVM.

Единственный вопрос, который у меня в голове, касается поддержки типов i128 / u128 - я думаю, что для AVR это бесполезно. Поддержка i128 в libcore в настоящее время закомментирована из-за ошибки, но могут быть и другие неоткрытые ошибки, поскольку это не хорошо протестированный кодовый путь, и он действительно использует распределитель регистров только как AVR имеет 32 байта регистров общего назначения.

По-прежнему вполне вероятно, что мы могли бы заставить i128 работать над AVR, хотя я не слишком много знаю о конкретных проблемах, которые он вызывает в бэкэнде.

Я думаю, что лучший способ продвинуться вперед - это предложить исправление на самом деле после того, как libcore _does_ скомпилируется без изменений или, по крайней мере, без многих.

Я думаю, что лучший способ продвинуться вперед - это предложить исправление по-настоящему, как только libcore будет компилироваться без изменений или, по крайней мере, без многих.

Для меня это звучит разумно!

Единственный вопрос, который у меня в голове, касается поддержки типов i128 / u128 - я думаю, что для AVR это не очень полезно.

Мой главный страх не поддерживать i128 на AVR заключается в том, что это окажет сдерживающее влияние на принятие 128-битных целых чисел ради совместимости с AVR или другими встраиваемыми платформами. Например, если есть библиотека, которая использует 128-битные целые числа, пользователи AVR, которые захотят ее использовать, будут сообщать о проблемах, чтобы отказаться от использования. Это может сделать 128-битные целые числа небезопасными для использования в коде Rust, который стремится быть переносимым, чего я бы не хотел.

сдерживающий эффект на принятие 128-битных целых чисел ради совместимости с AVR или другими встраиваемыми платформами

Я не думаю, что здесь это так уж важно. Маленькие встроенные устройства уже имеют огромные ограничения (нет stdin / stdout, как правило, нет распределителя и т. Д.), Из-за которых очень сложно просто добавить произвольную библиотеку. Недавно я узнал, что double AVR GCC на самом деле является псевдонимом для float ! Я не знаю, собираемся ли мы сохранить эту странность или нет, но это повлияет на ящики гораздо больше, чем i128 .

Я думаю, что у нас всегда будут специальные функции, которые помогут сделать ящик подходящим для встраиваемых систем, как мы это делаем для no-std.

нет stdin / stdout, обычно нет распределителя и т. д.

Вы описываете экосистему #![no_std] . Существуют библиотеки, ориентированные на эту экосистему. И общее правило для этой экосистемы - принимать libcore как данность, что также включает i128 . Каждая цель, которая не поддерживает i128 имеет больший сдерживающий эффект внутри этой экосистемы, потому что «рыночная доля» встроенной цели больше внутри подмножества всей экосистемы Rust, где семейство x86 не очень актуальный игрок. .

Я не знаю, собираемся ли мы сохранить эту странность или нет, но это повлияет на ящики гораздо больше, чем на i128.

Интересный! Я согласен с тем, что если бы мы использовали псевдоним f64 для f32 (или не предоставляли его), это больше повлияло бы на экосистему. Однако, если мы можем стремиться к последовательности, почему бы и нет? У нас определенно возможно реализовать i128 .

У нас, безусловно, есть возможность реализовать i128.

Совершенно верно, и я понимаю, что не сказал четко, что я думаю, что мы должны реализовать i128 для AVR . Однако любой код, который на самом деле использует i128 на AVR, будет мучиться.

Однако, если мы можем стремиться к последовательности, почему бы и нет?

Согласованность с чем , вот в чем вопрос. Согласованность с GCC ( f64 == f32 ) или с любой другой целью Rust ( f64 ! = f32 )?

Вы описываете экосистему #! [No_std].

Да, именно поэтому я сказал «специальные функции, которые используются, чтобы сделать ящик подходящим для встраиваемых систем, точно так же, как мы делаем для no-std». 😇

Более серьезная проблема, которая была в моей голове с тех пор, как мы изначально выпустили 16-битный патч usize заключается в том, что, по сути, программисты Rust и Rust склонны предполагать, что usize - это "родной" размер реестра. AFAIK, это верно для всех других платформ, на которые ориентирован Rust, но не для AVR.

Согласованность с чем, вот в чем вопрос. Согласованность с GCC (f64 == f32) или с любой другой целью Rust (f64! = F32)?

Имя f64 буквально указывает на то, что оно имеет 64 бита. Если вы не соблюдаете имя, оно теряет смысл, как и в C.

Хорошие моменты здесь, я вижу беспокойство по поводу 128-битных целых чисел. Я определенно считаю, что их следует поддерживать, хотя мы не должны поощрять их использование. Мне бы не хотелось, чтобы в ящики добавляли флаги функций для таких вещей, как trait impls в типах i128 . На самом деле это не должно быть проблемой, потому что все неиспользуемые материалы i128 должны быть удалены компоновщиком.

Проблема с f32 / 64 - интересная. Моя основная забота о том, чтобы сделать f64 на самом деле 64-битным, заключается в том, что это означает, что C FFI может быть очень хрупким. Если разработчики не знают, что AVR-GCC использует 32-битные двойники, тогда вызовы через FFI могут читать неинициализированную память или segfault.

Я полагаю, что мы могли бы решить эту проблему более или менее, ожидая, что вместо этого пользователи будут использовать типы из ящика libc . Мы могли бы добавить специфичную для AVR функциональность, чтобы установить c_double в f32 . Я думаю, мы можем разумно ожидать, что люди будут использовать ящик libc в своих привязках FFI.

Что нужно помнить для слияния, необходимо обновить тип c_int используемый в подписи main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Изменить: открыл проблему для этого, поскольку она также влияет на MSP430: https://github.com/rust-lang/rust/issues/44934

используется в сигнатуре main ()

@mattico Может быть, я просто делал что-то странным образом, но ни один из моих кодов не использовал main Rust :

#[no_mangle]
pub extern fn main() {

Что еще более важно, мы не можем вернуться , потому что нет ничего , чтобы вернуться. Каждая программа должна работать вечно.

@mattico Нам все равно придется изменить libc, чтобы типы соответствовали GCC для AVR

О, совершенно точно, я просто не знаю, что main вообще на нас повлияет.

@shepmaster Даже на argc в main не имеет значения, учитывая, что все это время мы ошибались, и никто этого не заметил, кроме как при проверке IR. Может быть какая-то ОСРВ использует стандартную точку входа main () для своих процессов? Тем не менее, это достаточно легко исправить.

Вероятно, чтобы отправить исправление, потребовалось бы столько же времени, сколько и напечатать это, теперь, когда я думаю об этом 😄

Это просто проблемы с libcore препятствуют этому слиянию? Просто чтобы мы знали, на чем сосредоточить усилия.

Единственные проблемы, которые у меня были с libcore, - это странные ошибки компоновщика, вызванные тем, что я не знаю, а также 32-битные ошибки сдвига бит (я думаю, отсутствует внутренняя). Я не знаю, блокируют ли они слияние.

chocol4te: Это только проблемы с libcore препятствуют слиянию? Просто чтобы мы знали, на чем сосредоточить усилия.

Да, вся необходимая работа здесь должна выполняться в LLVM .

Restioson: Единственные проблемы, которые у меня были вне libcore, - это странные ошибки компоновщика, вызванные тем, что я не знаю что, а также 32-битные ошибки сдвига битов (я думаю, отсутствует внутренняя).

Это потому, что весь код, который делает дросселирование бэкэнда AVR, закомментирован :)

Restioson: Я не знаю, блокируют ли они слияние.

Не напрямую, но было бы неплохо исправить это до объединения серверной части. Есть пара действительно досадных ошибок, подобных этой, которые мы должны рассмотреть перед тем, как объединиться, но они не обязательно останутся незамеченными.

@dylanmckay LLVM6 объединен https://github.com/rust-lang/rust/pull/47828 - что это значит для этого RFC?

@kellerkindt, все проблемы, перечисленные в разделе «Текущие проблемы в

Я лично все еще за

Я думаю, что лучший способ продвинуться вперед - это предложить исправление по-настоящему, как только libcore будет компилироваться без изменений или, по крайней мере, без многих.

Хотя необходимость избегать лишнего перебазирования - это хорошо.

Мне интересно текущее состояние Rust на AVR сейчас, когда мы полгода спустя в разработке. У меня в городе есть небольшая группа проектов Arduino, и мне бы очень понравилось использовать Rust.

Итак, хорошие новости!

Я думаю, что лучший способ продвинуться вперед - это предложить исправление по-настоящему, как только libcore будет компилироваться без изменений или, по крайней мере, без многих.

Вот и дело!

Текущая вилка avr-rust не содержит никаких модификаций libcore .

Модификации, необходимые для поддержки AVR со стоковой Rus:

• Объявляются и вызываются бэкэнд-функции инициализации AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} .
• Добавлена ​​спецификация цели базового минимума avr avr-unknown-unknown . Это моделирует поведение avr-gcc по умолчанию для построения с наименьшим общим знаменателем, если явно не указано иное. В отличие от avr-gcc который явно поддерживает аргумент -mmcu=<avr mcu name> , для AVR не был добавлен аргумент командной строки, специфичный для AVR. Это означает, что для каждого проекта должен быть написан файл JSON с настраиваемой целевой спецификацией. Однако это верно для многих встраиваемых проектов Rust.
• В вилке бэкэнд AVR LLVM всегда компилируется и связывается в стандартной проверке Rust и добавляется в файл config.toml.example . Должен ли AVR быть включен в исходный Rust по умолчанию или он также должен быть включен?
• Специальная логика AVR добавлена ​​в компилятор, где это необходимо для всех новых целей
• Добавлено соглашение о вызовах "avr-interrupt" . Это позволяет extern "avr-interrupt" fn my_isr_handler() { .. } . Для стабилизации, вероятно, потребуется пройти RFC-процесс, но я могу ошибаться.
• Добавлена ​​поддержка условной компиляции на CPU по типу #[cfg(target_cpu = "...")] . Реализацию можно найти здесь . Реализация этого не зависит от цели и, таким образом, работает для условной компиляции на основе ЦП и для других архитектур, таких как ARM. Это позволяет ящику ruduino условно включать специфичный для устройства модуль, который предоставляет все операции ввода-вывода, регистры и модули, которые поддерживаются в кристалле. Это определенно необходимо пройти через RFC перед апстримом.

Вероятно, пора послать RFC в LLVM-dev относительно перевода бэкэнда в неэкспериментальный статус.

Вы можете увидеть полный набор изменений с исходной версии Rust на avr-rust здесь .

Есть еще пара исправлений LLVM за последние два месяца, которые мы выбрали на данный момент, но усилия Rust в восходящем направлении по отделению версии LLVM emscripten от версии LLVM, используемой для всех других целей, сделали ее действительно простой. эти изменения в репо rust-lang/llvm , так как теперь оно регулярно обновляется в восходящем направлении.

Имеющиеся у нас <4 выбранных патчей LLVM в настоящее время находятся на рассмотрении в исходной версии LLVM, и поэтому, как только рецензент найдет достаточно времени, эти исправления автоматически переместятся в исходную версию Rust. В Upstream Rust также есть целевые патчи, специфичные для Rust, и поэтому выбранные патчи LLVM, вероятно, на самом деле не являются блокировщиком для слияния avr-rust upstream.

Есть новости о статусе Rust на AVR?

Также интересно узнать! На данный момент я решил взломать синюю таблетку STM32, но я определенно хотел бы вернуться к Arduino, как только будет готова поддержка avr в ржавчине.

Мы, @slowtec , также хотели бы использовать Rust для наших проектов AVR, и, конечно же, мы будем открывать исходный код для

Бамп, хотелось бы, чтобы поддержка стала официальной. Попробую использовать вилку для проекта.

Обновление: на данный момент мы обновляем вилку до более новой версии Rust (avr-rust / rust # 137). Мы обнаружили две ошибки, которые мы обнаружили.

ОШИБКА LLVM: закончились регистры во время распределения регистров

Это было исправлено в магистрали LLVM в llvm / llvm-project @ 45eb4c7e55341c0b83a21dedecc092e273795eda. Сейчас я добавляю это в нашу вилку LLVM. Эта ошибка исторически была самой большой проблемой в серверной части, возникающей в большинстве кодов с большим количеством указателей.

ОШИБКА LLVM: невозможно выбрать: t2: i16 = addrspacecast [1 -> 0] undef: i16
t1: i16 = undef
В функции: _ZN4core3ptr87_ $ LT $ impl $ u20 $ core..fmt..Debug $ u20 $ for $ u20 $ unsafe $ u20 $ fn $ LP $ A $ RP $$ u20 $. $ GT $$ u20 $ Ret $ GT $ 3fmt17h0fdf8ca7140def9b

Это сложнее исправить. Это вызвано неправильной обработкой указателей функций в Rust на гарвардских архитектурах, где есть два отдельных адресных пространства указателей для доступа к основной памяти и памяти программ.

Лучшее объяснение дает @ ecstatic-morse

Основная проблема заключается в том, что * const T всегда имеет addrspace (0). Я думаю, что явные приведения (ptr as * const T) должны сохранять здесь адресное пространство своего ввода.

Ошибка обнаруживается реализацией std::fmt::Debug для функций и указателей на функции. Rust генерирует разыменование указателя с типом целевого указателя addrspace(0)* i16 , используя процедуры LLVM, которые при необходимости будут неявно вставлять побитовое преобразование (iN -> iM биты) или преобразование адресного пространства. В случае указателей на функции Rust должен кодировать указатель addrspace(1)* i16 , чтобы LLVM не отображал ( addrspacecast ) указатели PROGMEM на указатели RAM - это невыполнимая задача, потому что нет отображения памяти. и адресные пространства не перекрываются.

Эта ошибка является основным блокирующим устройством.

Я надеюсь, что восходящий поток Rust будет извлекать из мастера LLVM (AFAICT, это в значительной степени в версии 8.0), чтобы мы могли удалить кучу вишневых решений.

Недавно я получил https://github.com/dylanmckay/avr-compiler-integration-tests/ тесты, успешно завершившиеся с использованием эмулятора AVR, и это здорово, потому что нет другого набора тестов, который фактически выполняет сборку AVR, выдаваемую LLVM. Я настроил бегун GitLab для запуска тестов для каждой фиксации AVR-Rust (через зеркало репозитория GitLab), но это не очень полезно, потому что GitLab не поддерживает сборки CI для запросов на вытягивание, поскольку фактический код размещается в раздвоенный репозиторий.

Спасибо за обновление @dylanmckay. Мы все ценим ваши усилия.

Теперь мы обновили вилку на базе Rust rust-lang / rust @ fb7cca33f , программа blink успешно компилируется.

Эта проблема остановилась?

У вас есть новости по этому поводу? Связь с общественностью по-прежнему зашла в тупик по вопросу адресного пространства?

Привет, @dylanmckay , извините за

Всем привет, вот несколько моих комментариев

Исправления, связанные с сбором вишни

Почти все исправления, необходимые для работы libcore были переданы на главный сервер LLVM и в настоящее время существуют в вилке rust-lang / llvm. Вчера я начал пиар, чтобы обновить вилку AVR до 1.39.0 (avr-rust / rust # 155), мне нужно было выбрать только одно исправление, которого еще не было - avr-rust / llvm @ 4350776601bc671e6e055bfbe32add34b70d2635.

libcore нельзя скомпилировать без изменений

Нам больше не требуется настраиваемая вилка libcore для использования AVR. В настоящее время существует только одна модификация libcore в вилке avr-rust - avr-rust / rust @ 44240ac59c5949b8a9fd191f5cd666d0206fbe85 - переписать приведение указателя, чтобы получить правильную генерацию IR.

Мы зависим от xargo для компиляции двоичных файлов AVR-Rust - это станет проще с продолжающимися инициативами Cargo с поддержкой std (включая рабочую группу). В настоящее время AVR требует скомпилированного sysroot для каждого типа MCU - в данный момент мы используем Xargo для ленивой компиляции, но это будет намного проще, когда Cargo сможет изначально компилировать core / std для желаемых целевых спецификаций.

Любые операции с указателями функций, кроме «call», обращаются к ОЗУ, а не к программной памяти (avr-rust # 68)

Это было исправлено.

32-битные сдвиги генерируют вызовы несуществующей подпрограммы compiler-rt (avr-llvm / llvm # 163)

Это по-прежнему болезненный вопрос. Я подозреваю, что лучшим решением будет написать собственный понижающий код в бэкэнде LLVM AVR, который понижает эти сдвиги до чистой сборки, удаляя любую зависимость ABI от compiler-rt или libgcc. Я не уверен, насколько больше может быть размер сгенерированного кода, это может быть не очень хорошей идеей.

Вопросы перед апстримом

RFC и нестабильные соглашения о вызовах

Я разместил этот комментарий в ветке

Добавлено соглашение о вызовах "avr-interrupt". Это позволяет использовать extern "avr-interrupt" fn my_isr_handler () {..}. Для стабилизации, вероятно, потребуется пройти RFC-процесс, но я могу ошибаться.

Можно ли добавить нестабильные соглашения о вызовах без прохождения RFC-процесса?

В настоящее время у нас есть "avr-interrupt" и "avr-non-blocking-interrupt" под воротами функции #![feature(abi_avr_interrupt)] . Могут ли они быть названы нестабильными соглашениями о вызовах в ожидании будущей стабилизации RFC?

Buildbots

Для апстриминга серверной части LLVM требуется настройка специального сборочного робота, который запускает тесты для этой серверной части и поддерживает его. Это случай с Rust? Как мы гарантируем, что набор тестов запускается в режиме AVR при каждом нажатии? Чем занимались другие серверы (например, WASM)?

Распределение

Означает ли «слияние апстрима вилки avr-rust» просто объединение двух вилок в одну, но при этом требуется сборка из исходных кодов? Возможно, серверная часть будет распространяться, но только по ночам? Что сделали другие серверные ВМ?

В остальном, патчи, специфичные для avr-rust, очень тонкие, без каких-либо грубых хаков в настоящее время.

Полный набор патчей можно увидеть здесь https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support

Мой набор обновлений WIP 1.39.0 (который в основном идентичен) можно найти здесь https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support-1.39.0-4560ea788c . Это должно быть объединено с avr-rust / master в ближайшие несколько дней.

Я не могу придумать ничего конкретного, что блокирует это - возможно, пора отправить патчи и посмотреть, как это пойдет?

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

Я упоминал об этой проблеме выше, но я не думаю, что она блокирует апстрим бэкэнда AVR. Мы должны получить работающую, полезную версию rustc с AVR и без него. Я уверен, что есть обходные пути и приемы, которые мы можем исправить. обнаружение устройств в ящиках AVR после того, как бэкэнд был гипотетически объединен, и до того, как официальный API запросов target-cpu попадет в официальный Rust.

Он живет! Спасибо за обновление @dylanmckay ,

Отличная работа @dylanmckay! Спасибо, что держали нас в курсе.

Немного не по теме, но: сможет ли rustc для avr выполнять FFI с библиотеками C?
Для avr уже доступно множество зрелых библиотек, написанных на C / C ++.
Было бы здорово создать для них несколько оберток в стиле ржавчины и повторно использовать их в наших проектах ржавчины avr.

Rust уже может делать FFI с C в целом.

Да, и это действительно здорово! Однако возникает вопрос: можно ли это перевести на rust-avr?

Пока C ABI LLVM для AVR совпадает с ABI gcc, он должен работать

Можно ли добавить нестабильные соглашения о вызовах без прохождения RFC-процесса?

Мой голос - да , поскольку изменение для поддержки соглашений о вызовах AVR в основном просто дает им имя и сопоставляет их с номером LLVM. Никаких фундаментальных изменений кода не требуется, поскольку у нас уже есть поддержка нестабильных соглашений.

Для апстриминга серверной части LLVM требуется настройка специального сборочного робота, который запускает тесты для этой серверной части и поддерживает его. Это случай с Rust? Как мы гарантируем, что набор тестов запускается в режиме AVR при каждом нажатии? Чем занимались другие серверы (например, WASM)?

Ярусная система Rust определена немного неточно, но я думаю, что правильнее всего будет объединить код, специфичный для AVR . Тогда AVR будет уровня 3 , что означает, что он не создается или не тестируется автоматически, а просто зависает в коде. По крайней мере, это означает, что эти файлы будут обновляться с изменениями компилятора.

Означает ли «слияние апстрима вилки avr-rust» просто объединение двух вилок в одну, но при этом требуется сборка из исходных кодов?

Насколько мне известно, это было бы отправить одну фиксацию в качестве PR. Наша кастомная вилка фактически умрет / станет местом для отслеживания специфичных для AVR деталей, пока она не станет более широко используемой целью.

возможно пришло время подавать патчи

Я так думаю.

@edvorg очень по теме ИМО

Немного не по теме, но: сможет ли rustc для avr выполнять FFI с библиотеками C?
Для avr уже доступно множество зрелых библиотек, написанных на C / C ++.

Да .. в основном. Соглашение о вызовах AVR, реализуемое серверной частью AVR, разработано для соответствия правилам AVR-GCC (задокументировано здесь ). Есть некоторые причуды, но исправление LLVM D68524, которое мне нужно просмотреть, должно исправить их.

Сайты вызовов Rust всегда смогут правильно вызывать скомпилированные функции Rust или avr-clang (поскольку avr-clang C использует ту же реализацию соглашения о вызовах extern "C" что и интерфейс Rust), и взаимодействие с AVR-GCC _должно_ работать, особенно для простых сигнатур функций, но иногда он может задыхаться (подробности см. в описании D68524).

Есть новости по этому поводу?
Просто любопытно.

Отправлен запрос на превращение бэкэнда LLVM AVR в официальный бэкэнд - https://reviews.llvm.org/D75099

@dylanmckay Если будет принято, что еще нужно сделать, чтобы закрыть эту проблему?

@dylanmckay Если будет принято, что еще нужно сделать, чтобы закрыть эту проблему?

Технически Rust будет работать как с официальными, так и с экспериментальными серверами. Я поднял # 69478 для апстриминга основной части серверной части.

Я не уверен, что слияние AVR в качестве цели уровня 3 основано на том, что AVR станет официальным сервером LLVM - мысли приветствуются.

Если подумать, официальное отличие LLVM от экспериментального можно сопоставить с многоуровневой системой Rust, из которой Rust имеет три уровня, а LLVM - два. Официальный бэкэнд LLVM соответствует сочетанию уровней 1 и 2 - в основном, он включен в комплекты тестов и официальные выпуски. Экспериментальный бэкэнд LLVM, насколько я могу судить, семантически совпадает с бэкэндом Rust Tier 3; включены в дерево исходных текстов, не включены в выпуски по умолчанию, не включены в тесты CI по умолчанию и т. д.

Тогда я полагаю, что единственными оставшимися частями для решения этой проблемы будут те, которые упоминаются в обзоре кода # 69478.

tl; dr бэкэнд AVR станет восходящей целью уровня 3 в rust-lang / rust # 69478 в случае слияния, тем самым убивая вилку.

Единственная разница между вилкой avr-rust / rust и # 69478 - это флаг target_cpu cfg, который существует в вилке AVR, но не в восходящем направлении. Я исключил это из первоначального PR.

какие оставшиеся части

Я почти уверен, что все еще существует ряд ошибок компиляции различных типов кода, поэтому все еще нужно больше людей, чтобы попробовать что-то, минимизировать ошибки и исправить их.

Однако переход на новую партию снизит планку, чтобы люди попробовали что-то, так как они могут просто получить обычный ночной Rust вместо компиляции обычно устаревшего форка.

После того, как он станет целью уровня 3, будет ли разработка AVR работать с функцией Cargo -Z build-std или потребуется xargo? Имеет ли LLD, поставляемый с Rust, поддержку AVR, или потребуются линкеры GNU?

будет ли разработка AVR работать с функцией Cargo -Z build-std или для этого потребуется xargo? Имеет ли LLD, поставляемый с Rust, поддержку AVR, или потребуются линкеры GNU?

Я не могу сказать, что это не сработает, но все, что я делал, использовал линкеры Xargo и GNU.

Компоновщики GNU сложно настроить в Windows, а xargo требует установки еще одного инструмента, поэтому я спрашиваю.

Имеет ли LLD, поставляемый с Rust, поддержку AVR, или потребуются линкеры GNU?

LLD имеет только базовую поддержку для связывания AVR, он пока не может связывать какие-либо реальные программы. Следовательно, потребуется avr-ld .

вот почему я спрашиваю.

Не заблуждайтесь, я тоже считаю, что это правильная конечная цель, просто это может быть не текущее состояние мира. Честно говоря, я был бы счастлив делать накладные расходы все ниже и ниже. Объединение всего этого - лишь первый шаг к этому.

Бэкэнд AVR теперь включен в качестве официальной цели LLVM: tada: Мастер LLVM теперь по умолчанию содержит поддержку AVR. Первым выпуском LLVM, который будет включать AVR по умолчанию, будет LLVM 11 примерно через 6 месяцев.

Хороший! Спасибо за все усилия, которые вы прилагаете к этому.

Очень круто!

Поздравляем @dylanmckay с этим невероятным достижением. Сообщество благодарит вас за вашу работу над этим.

Я уже некоторое время слежу за этой проблемой, и хотя я знаю, что это в основном не по теме, мне интересно, что это означает для среднего пользователя, не являющегося источником ... Это сложный процесс, чтобы получить Arduino Uno работает с нативным Rust, используя это? Меня больше всего интересует это, поскольку у Rust достаточно защиты, я, вероятно, не смогу вызвать столько же моментов упс xP

@ Jimmio92 Насколько я могу судить, да. Как "да, это сложно". Или, по крайней мере, долгим и утомительным, даже если не особо сложным, поскольку вам все равно придется собрать этот собственный форк компилятора Rust из исходного кода, что также влечет за собой сборку LLVM из исходного кода. Обычно это занимает пару часов, если все идет хорошо.

_{Однако мой личный опыт работы с LLVM заключается в том, что в большинстве случаев ему просто не нравится что-то в вашей системе (по крайней мере, конечно, в macOS - это проще в Linux и, конечно, даже не мечтайте делать это в Windows), так что вы неизбежно в конечном итоге будете массировать пути установки и пользовательские библиотеки, пока не добьетесь успеха или не сдадитесь.}

Приведенные выше (отличные) новости означают только одно: разработчики LLVM теперь официально нацелены / поддерживают AVR (?), А следующий выпуск LLVM будет включать поддержку AVR. Ничего не сказано, что Rust теперь также поддерживает или будет поддерживать AVR в краткосрочной перспективе. Если вы посмотрите на проблемы и приведенные выше комментарии, вы увидите, что потребуется много работы, пока поддержка AVR «просто не заработает» со стандартным набором инструментов Rust.

Есть ли процесс / пример, с помощью которого я мог бы взглянуть на исправления AVR, отобранные мастером LLVM, в вилку Rust LLVM?

Кроме того, отслеживает ли Rust мастер LLVM? Судя по всему, он отслеживает текущий выпуск и некоторые избранные исправления. Принимаются ли PR на обновление версии LLVM до master?

@dylanmckay

Кроме того, отслеживает ли Rust мастер LLVM?

Как вы заметили, сейчас он отслеживает релизы.

Принимаются ли PR на обновление версии LLVM до master?

Я так не думаю, но cc @nikic

@dylanmckay есть множество исправлений в LLVM-форке Rust по сравнению с выпуском 10.0: https://github.com/rust-lang/llvm-project/commit/rustc/10.0-2020-05-05

Есть ли процесс / пример, с помощью которого я мог бы взглянуть на исправления AVR, отобранные мастером LLVM, в вилку Rust LLVM?

Инструкции доступны здесь: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

Кроме того, отслеживает ли Rust мастер LLVM? Судя по всему, он отслеживает текущий выпуск и некоторые избранные исправления. Принимаются ли PR на обновление версии LLVM до master?

В настоящее время Rust отслеживает выпуски LLVM, потому что это позволяет людям легко выполнять межъязыковую LTO с соответствующей версией clang. Так что ответ по умолчанию здесь, вероятно, «нет».

Тем не менее, было некоторое обсуждение обновления до LLVM master для смягчения регрессий времени компиляции LLVM 10. В настоящее время я работаю над этим в целях оценки. Я думаю, что безопаснее предположить, что этого не произойдет, и представить вишневый выбор против нашей вилки LLVM 10 (а их много?)

Вилка объединена! Я напишу правильное обновление сегодня днем

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

Я напишу правильное обновление сегодня днем

Я заинтересован в указанном обновлении. Где вы планируете разместить это на @dylanmckay (чтобы я знал, где искать:

Я с нетерпением ждал этого дополнения к экосистеме Rust буквально годы! Однако мои наивные попытки использовать это на мастере кажутся ошибочными.

Я построил master rust с помощью стандартной ./x.py build , связанной как toolchain master , а затем попытался построить пример avr-rust / blink (после обновления src/main.rs для использования llvm_asm! ):

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

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

Это не удается:

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

Я предполагаю, что все еще требуется конфигурация, которую мне не хватает.

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

Я бы не ожидал, что сейчас что-то будет работать, поскольку libcore - это часть того, что неправильно скомпилировано.

Вилка AVR rustc была объединена с восходящей цепью.

Форк восходящего потока пока не используется. Сначала нужно сделать несколько вещей.

Исправления апстрима AVR LLVM, которых еще нет в Rust, нужно тщательно подбирать

Чтобы ответить на вопрос @nikic , нужно выбрать не более 20 коммитов LLVM.

Я использовал скрипт для автоматического выбора вишневого _все_ AVR коммитов из восходящего потока LLVM в локальную вилку.
Это большой молоток, и в нем будут исправления, выбранные из вишенки, которые не нужны - есть исправления LLVM, которые нужно вытащить в исходный код Rust, прежде чем бэкэнд станет пригодным для использования. их нужно будет отфильтровать и собрать в восходящий поток Rust.

Компиляция программы мигания светодиодов AVR из основной ветки Rust.

Поскольку усилия по разведке и добыче ведутся уже несколько месяцев, нижняя вилка avr-rust
все еще работает на особенно старой версии Rust. С тех пор в вышестоящем Rust произошло как минимум одно изменение, которое требует обобщения для поддержки AVR без появления ошибок утверждения LLVM. Я открыл запрос на перенос № 73270, чтобы исправить это.

Я не уверен, были ли другие изменения в исходном Rust, которые нуждаются в изменениях для AVR - скорее всего, нет.

Как только у меня заработает программа мигания, я опубликую еще одно обновление, потому что к этому моменту восходящая поддержка AVR должна быть готова для использования / экспериментов.

Где должно происходить / размещаться сообщение AVR

@wezm вы подняли хороший вопрос - не обязательно иметь "благословенный" канал связи для обновлений. Этот билет хорошо себя зарекомендовал, но вскоре он неизбежно будет закрыт.

Канал AVR-Rust Gitter - наиболее естественный из существующих вариантов. Мне нравится идея списка рассылки (но мне не нравится идея разместить почтовый сервер, если это возможно). На канале Gitter есть обсуждения, поэтому, возможно, будет полезно что-то вроде списка рассылки.
Возможно, создание блога было бы полезным для централизации объявлений / обновлений. Я хотел бы иметь "официальную среду", чтобы люди, которым нужны случайные обновления, не пропустили. Я полагаю, что блог требует постоянной проверки наличия новых сообщений, тогда как список рассылки по сути уведомляет
всем кому интересно. Предложения приветствуются.

Открытые вопросы

• Следует ли переносить проблемы GitHub на вилке avr-rust в вышестоящий репозиторий Rust?
  ** Тем не менее, в репозитории апстрима должны возникать новые проблемы - старый трекер проблем необходимо будет отключить.
  
  
  
  • Где должна жить инструкция по компиляции Rust с AVR?
  
  

Самое важное на будущее (читай: приоритеты)

• Упаковка и распространение двоичных файлов AVR Rust. Компиляция Rust может стать большой головной болью для обычного пользователя,
  во многих дистрибутивах время от времени возникают проблемы с определенными рабочими процессами. Несколько ошибок OOM неверно указаны как
  ошибки компилятора. Барьер для входа излишне высок и должен быть ниже - просто скачайте и работайте.
  Отслеживается https://github.com/avr-rust/rust/issues/162
• Составление списка «поддерживаемых» или, по крайней мере, протестированных конфигураций. Нам нужна таблица (rustc version, Xargo version) поэтому
  изменения частных API-интерфейсов Rust, от которых зависит Xargo, не нарушают работу инструментария AVR Rust при обновлении.
  Xargo находится в режиме обслуживания - cargo-xbuild кажется довольно ограниченным (я пробовал его несколько недель назад, не могу вспомнить причину),
  нам может понадобиться форк Xargo. Возможно, лучше добавить инструменты прямо в Cargo (для этого есть проблема с отслеживанием).
• Создание какой-то домашней страницы для проекта, включая ссылки для скачивания
• Интеграционное тестирование (на эмулируемом / смоделированном AVR, при каждой фиксации)

На данный момент я обязательно буду размещать обновления в этом выпуске GitHub, пока не будет найден лучший носитель. Я тоже опубликую их в Gitter.

Возможно, создание блога было бы полезным для централизации объявлений / обновлений. Я хотел бы иметь "официальную среду", чтобы люди, которым нужны случайные обновления, не пропустили. Я полагаю, что блог требует постоянной проверки наличия новых сообщений, тогда как список рассылки по сути уведомляет
всем кому интересно. Предложения приветствуются.

Я лично предпочитаю вести блог (с RSS-потоком). Я думаю, что блоги обычно лучше отображаются в результатах поисковых систем, и на них лучше давать ссылки, чем на цепочки списков рассылки. RSS-канал решает проблему проверки / уведомления.

Я не уверен на 100%, что это лучшее место для этого, но есть блог Embedded WG. Может быть, канал связи не требует больших усилий.

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

Может быть, еще и аккаунт в Твиттере? Его можно использовать для публикации новых сообщений в блогах (чтобы оставаться в курсе).

Думаю, встроенная рабочая группа будет рада помочь здесь. У нас есть аккаунт в Твиттере @rustembedded, и мы, конечно же, можем включать в информационный бюллетень новости, связанные с AVR.

Я также недавно создал лейбл O-AVR , так что не стесняйтесь использовать трекер проблем Rust и для проблем, связанных с AVR (но имейте в виду, что 1,5 тысячи человек смотрят репо). В дополнение к этому, вы можете захотеть скоординировать свои действия с rust-lang Zulip, поскольку именно там проживает большинство команд Rust. Мы также находимся в процессе наращивания «целевых групп», которые сосредотачиваются на конкретных целях Rust (например, Windows или Arm), AVR может также хорошо подойти для этого. Не стесняйтесь обращаться за этим на Zulip.

Обновлять.

Осталось две вещи, прежде чем libcore можно будет скомпилировать для AVR в стандартной ветке rust-lang / master:

1. Существует один запрос на вытягивание, который исправляет серию ошибок «недопустимое приведение адресного пространства» в AVR, касающихся того, как указатели функций для архитектур Гарварда должны быть помечены как addrspace(1) по сравнению с целями Фон-Неймана, которые подходят для текущего значения по умолчанию в Rust. из addrspace(0) . rust-lang / rust # 73270 - в настоящее время код проверяется

~ 2. Есть еще одна ошибка, блокирующая работу примера blink - avr-rust / rust # 92. Существует еще не запущенный патч, который исправит это - https://reviews.llvm.org/D68524. Это будет апстримингово, а затем очень скоро будет добавлено в

Как только эти две вещи будут выполнены, цель AVR с апстримом Rust сможет скомпилировать код AVR до того же уровня, что и текущий форк avr-rust / rust, и затем мы сможем начать процесс обновления примера blink , arduino crate, документация, руководства для восходящей ветки. Затем восходящая ветвь должна быть готова к экспериментальному использованию.

Еще одно ТОДО:

1. ~ Добавить соединение AVR для нового синтаксиса встроенного ассемблера в восходящем потоке Rust ~
   
   
   
   • ~ После поддержки нового синтаксиса встроенной сборки необходимо обновить ящик Arduino, чтобы использовать его.
     
     как только ящик Arduino будет обновлен, обновите ящик мигания до новой версии. ~ Мы можем использовать старый макрос через llvm_asm! сейчас, поскольку он все еще существует в ночное время.
   
   
2. Исправления ошибок AVR Cherry-pick (в основном, Ayke) от мастера LLVM до восходящей ветки Rust LLVM (РЕДАКТИРОВАТЬ: PR: https://github.com/rust-lang/llvm-project/pull/66)

Вот ветка со всем: https://github.com/dylanmckay/rust/commit/dylan/avr-workable-upstream-candidate. Этой ветки достаточно для компиляции libcore.

Он построен из апстрима rust-lang/master но также включает в себя еще не прошедший апстрим патч LLVM

Обновление : открыт запрос на вытягивание, который включает все исправления LLVM восходящего направления.

Вот исчерпывающий список того, что осталось сделать, прежде чем программа мигания светодиода может быть скомпилирована и успешно запущена.

Оставшаяся работа

• [x] Land Rust PR ржавчина / ржавчина # 73270 . Этот запрос на перенос исправляет серию ошибок «недопустимое приведение адресного пространства» в AVR, относящихся к тому, как указатели функций для архитектур Гарварда должны быть помечены как addrspace (1) по сравнению с целями Фон-Неймана, которые подходят для текущего Rust по умолчанию addrspace (0). . В настоящее время он находится на проверке кода.
• [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Это втягивает все необходимые исправления AVR из восходящего потока LLVM в вилку Rust LLVM. В итоге осталось ~ 17 ~ 16 исправлений LLVM, которые нужно было тщательно отобрать.
• [x] Land Rust PR rust-lang / rust # 73658, обновляющий версию подмодуля LLVM . В документации компилятора Rust есть инструкции для этого. В настоящее время он находится на проверке кода .
• [x] Land Rust PR ~ ржавчина / ржавчина # 74625 ~ ржавчина / ржавчина # 74631 . В 79a42e37084d0 Rust начал безоговорочно передавать аргумент --eh-frame-hdr компоновщику. Компоновщик AVR-GCC не поддерживает этот флаг, поэтому для AVR добавлен специальный случай, позволяющий избежать его передачи, аналогично существующим исключениям для Windows. Solaris и UEFI.

Возможно, лучше добавить инструменты прямо в Cargo (для этого есть проблема с отслеживанием).

Я предполагаю, что это правильный вопрос: rust-lang / cargo # 4959.

cargo build -Z build-std=core хорошо сработал для моих примеров AVR.

@shepmaster, который все равно меня сближает, спасибо! Мне просто кажется, что сейчас я застрял на биткастах, поэтому я буду ждать, пока они будут объединены (поскольку мне кажется, что мне не хватает файла, необходимого для создания PR, и IDK того, что я делаю).

В процессе использования -Z build-std=core мне нужно было указать целевую тройку, поэтому я запустил rustc +master --print target-list | grep avr и нашел avr-unknown-unknown . Но заархивированный выпуск avr-llvm / llvm # 35, кажется, заставляет звучать так, как будто тройка на самом деле должна быть avr-atmel-none (что в любом случае имеет для меня больше смысла). Здесь что-то нужно обновить, или я что-то упускаю?

avr-unknown-unknown правильно.

Открытые вопросы

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

Я не думаю, что это имеет большое значение для пользователя. Это было достаточно легко найти с помощью ddg и / или this-week-in-rust.
Что бы ни облегчало разработчикам.

Открытые вопросы

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

Я не думаю, что это имеет большое значение для пользователя. Это было достаточно легко найти с помощью ddg и / или this-week-in-rust.
Что бы ни облегчало разработчикам.

Я думаю, что инструкции по компиляции Rust с AVR должны быть как-то на https://docs.rust-embedded.org/

Хорошо, обнови время.

Все необходимые патчи для AVR существуют в текущем ночном компиляторе Rust на сегодняшний день rustc 1.47.0-nightly (0820e54a8 2020-07-23) . Компилятор Rust nightly без изменений теперь может успешно скомпилировать пример мигания светодиода и сгенерировать файл AVR ELF.

• Новая централизованная целевая страница проекта, созданная по адресу https://avr-rust.com/
• Создана новая книга - Руководство по AVR-Rust , размещенная на страницах GitHub по адресу book.avr-rust.com.
• Репозиторий вилок avr-rust / rust устарел. Репозиторий еще не заархивирован, так как есть существующие проблемы, которые следует перенести, прежде чем они будут окончательно заблокированы и закрыты.
• Xargo больше не требуется - флаг -Z build-std в восходящем Rust заменяет его необходимость в AVR. Грузовая вилка больше не требуется - подойдет груз вверх по течению.

Ночной компилятор Rust теперь может считаться рекомендуемым каналом для Rust с поддержкой AVR.

Сейчас закрываю этот вопрос - мы сделали!

Инструкции по сообщению об ошибках можно найти в Руководстве по

Руководство AVR и пример мигания на https://github.com/avr-rust/blink - лучшие ресурсы для начала использования цели.

Глубокая, глубокая благодарность всем, кто обсуждал и поддерживал проект посредством этих усилий по развитию - это очень ценно.

ПЛАВНИК

Вау вау вау.

Спасибо всем, кто способствовал этому - я с нетерпением жду этого дня с незапамятных времен!

Дилан Маккей перед портированием ржавчины на avr

И после

Спасибо за все трудолюбие, мужик! :-) Хорошо отдохни!