+1! Avr rust integrado en el compilador propiamente dicho sería muy útil. Ahora está casi libre de errores.

No completamente libre de errores :)

Actualizaré la descripción para incluir información sobre el estado de los errores de backend wrt

Casi aunque 😄. Solo un par para ir

En general, damos la bienvenida a las plataformas upstream en rust-lang / rust siempre que no supongan una carga de mantenimiento para nosotros. Algunos pensamientos específicos de lo que estás pensando:

• Seleccionar los compromisos de LLVM de vez en cuando está totalmente bien, creo que todos ustedes también han pasado por el proceso varias veces :)
• Está bien que nos falten elementos intrínsecos en compiler-rt, usted tiene la opción de implementarlos en Rust también a través del proyecto compiler-builtins.
• El parche que tiene se ve bastante bien, aunque creo que nos gustaría trabajar más a través de los diferentes #[cfg] en libcore. ¿Se omiten estos elementos debido a "errores en LLVM" o porque fundamentalmente no son compatibles con AVR? El primero se haría mejor "arreglando LLVM" de alguna manera, mientras que el segundo complica las cosas.

En general, actualmente tenemos todas las plataformas con la misma interfaz uniforme de libcore / libstd, pero no está claro que seguirá siendo así a medida que sigamos adquiriendo más plataformas.

El parche que tiene se ve bastante bien, aunque creo que nos gustaría trabajar más a través de los distintos # [cfg] en libcore. ¿Se omiten estos elementos debido a "errores en LLVM" o porque fundamentalmente no son compatibles con AVR?

Es por errores en LLVM.

La única pregunta en mi mente es sobre el soporte de los tipos i128 / u128 ; creo que para AVR, estos no son realmente útiles. El soporte de i128 en libcore está comentado actualmente debido a un error, pero puede haber otros errores no descubiertos ya que no es una ruta de código bien probada, y realmente ejercita el asignador de registros como el AVR solamente tiene 32 bytes de registros de propósito general.

Sin embargo, todavía es bastante probable que podamos hacer que i128 funcione en AVR, no sé demasiado de los problemas específicos que desencadena en el backend.

Creo que la mejor manera de avanzar sería proponer el parche de verdad una vez que libcore _does_ se compile sin modificaciones, o al menos sin muchas.

Creo que la mejor manera de avanzar sería proponer el parche de verdad una vez que libcore se compile sin modificaciones, o al menos sin muchas.

¡Me parece razonable!

La única pregunta en mi mente es sobre la compatibilidad con los tipos i128 / u128; creo que para AVR, estos no son realmente útiles.

Mi principal temor de no admitir i128 en AVR es que tendrá un efecto escalofriante en la adopción de enteros de 128 bits en aras de la compatibilidad con AVR u otras plataformas integradas. Por ejemplo, si hay una biblioteca que usa números enteros de 128 bits, los usuarios de AVR que deseen usarla presentarán problemas para eliminar el uso. Esto podría hacer que los enteros de 128 bits no sean "seguros" para usar en el código Rust que se esfuerza por ser portátil, lo que no me gustaría que sucediera.

un efecto escalofriante en la adopción de enteros de 128 bits en aras de la compatibilidad con AVR u otras plataformas integradas

No creo que sea un gran problema aquí. Los dispositivos integrados pequeños ya tienen limitaciones gigantes (sin stdin / stdout, generalmente sin asignador, etc.) que hacen que sea realmente difícil colocar una biblioteca arbitraria. ¡Recientemente aprendí que double AVR GCC es en realidad un alias de float ! No sé si vamos a mantener esa extrañeza o no, pero afectaría a las cajas mucho más que i128 .

Creo que siempre vamos a tener características especiales que se utilizan para hacer una caja adecuada para empotrar, al igual que lo hacemos para no-std.

sin stdin / stdout, generalmente sin asignador, etc.

Estás describiendo el ecosistema #![no_std] . Hay bibliotecas que apuntan a este ecosistema. Y la regla general para ese ecosistema es tomar libcore como un hecho, que también incluye i128 . Cada objetivo que no admite i128 tiene un efecto de enfriamiento mayor dentro de este ecosistema, porque la "cuota de mercado" de un objetivo integrado es mayor dentro del subconjunto de todo el ecosistema de Rust, donde la familia x86 no es un jugador muy relevante. .

No sé si mantendremos esa extrañeza o no, pero afectaría a las cajas mucho más que al i128.

¡Interesante! Estoy de acuerdo en que si tuviéramos un alias de f64 a f32 (o no lo proporcionáramos), afectaría más al ecosistema. Sin embargo, si podemos luchar por la coherencia, ¿por qué no deberíamos hacerlo? Definitivamente es posible para nosotros implementar i128 .

Definitivamente es posible para nosotros implementar i128.

Absolutamente, y me doy cuenta de que no dije claramente que creo que deberíamos implementar i128 para AVR . Sin embargo, cualquier código que realmente use un i128 en un AVR será un mundo de dolor.

Sin embargo, si podemos luchar por la coherencia, ¿por qué no deberíamos hacerlo?

Coherencia con qué , es la cuestión. ¿Coherencia con GCC ( f64 == f32 ) o con cualquier otro objetivo de Rust ( f64 ! = f32 )?

Estás describiendo el ecosistema #! [No_std].

Sí, por eso dije "características especiales que se utilizan para hacer una caja adecuada para empotrar, al igual que lo hacemos para no-std". 😇

Un problema mayor que ha estado en mi mente desde que obtuvimos originalmente el parche usize 16 bits es que, fundamentalmente, los programadores de Rust y Rust tienden a asumir que usize es el "nativo" tamaño de un registro. AFAIK, esto es cierto para todas las otras plataformas de objetivos de Rust, pero no para AVR.

Coherencia con qué, es la cuestión. ¿Consistencia con GCC (f64 == f32) o con cualquier otro objetivo de Rust (f64! = F32)?

El nombre f64 indica literalmente que tiene 64 bits. Si no respeta el nombre, perderá su significado como en C.

Buenos puntos aquí, puedo ver la preocupación en torno a los enteros de 128 bits. Definitivamente creo que deberían ser compatibles, aunque no deberíamos fomentar su uso. Odiaría ver que las cajas tengan que agregar indicadores de características para cosas como las implicaciones de rasgos en los tipos i128 . Esto realmente no debería ser un problema porque el enlazador debería recortar todas las cosas del i128 no utilizadas.

El problema de f32 / 64 es interesante. Mi principal preocupación al hacer que f64 sea realmente de 64 bits es que significa que C FFI podría ser muy frágil. Si los desarrolladores no saben que AVR-GCC usa dobles de 32 bits, entonces las llamadas a través de FFI podrían leer la memoria no inicializada o segfault.

Me imagino que podríamos resolver esto más o menos esperando que los usuarios usen tipos de la caja libc lugar. Podríamos agregar una funcionalidad específica de AVR para establecer c_double en f32 . Creo que podemos esperar razonablemente que la gente use la caja libc en sus enlaces FFI.

Algo para recordar para la fusión, es necesario actualizar el tipo c_int utilizado en la firma main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Editar: abrió un problema para esto ya que también afecta a MSP430: https://github.com/rust-lang/rust/issues/44934

utilizado en la firma principal ()

@mattico Quizás he estado haciendo las cosas de una manera extraña, pero ninguno de mis códigos ha hecho uso de main de Rust :

#[no_mangle]
pub extern fn main() {

Más importante aún, en realidad no podemos volver porque no hay nada para volver a. Cada programa debe ejecutarse para siempre.

@mattico Definitivamente tendremos que modificar libc para que los tipos coincidan con GCC para AVR

Oh, absolutamente, no sé si main nos afectará en absoluto.

@shepmaster Incluso en plataformas no integradas, el tamaño de argc en main no importa dado que nos hemos equivocado todo este tiempo y nadie se ha dado cuenta, excepto al inspeccionar el IR. ¿Puede haber algunos RTOS que utilicen un punto de entrada main () estándar para sus procesos? Independientemente, es bastante fácil de arreglar.

Probablemente hubiera tomado la misma cantidad de tiempo enviar una corrección que escribir esto, ahora que lo pienso 😄

¿Son solo los problemas de libcore los que impiden esta fusión? Solo para que sepamos dónde concentrar los esfuerzos.

Los únicos problemas que he tenido con libcore son errores extraños del enlazador causados ​​por no sé qué y también errores de desplazamiento de bits de 32 bits (creo que falta el intrínseco). Sin embargo, no sé si están bloqueando la fusión.

chocol4te: ¿Son solo los problemas de libcore los que impiden esta fusión? Solo para que sepamos dónde concentrar los esfuerzos.

Sí, todo el trabajo requerido aquí debe realizarse dentro de LLVM .

Restioson: Los únicos problemas que he tenido con libcore son errores extraños en el enlazador causados ​​por No sé qué y también errores de desplazamiento de bits de 32 bits (creo que falta el intrínseco).

Eso es porque todo el código que hace que el backend de AVR se ahogue está comentado :)

Restioson: No sé si están bloqueando la fusión.

No directamente, pero sería bueno haberlo arreglado antes de que se fusione el backend. Hay un par de errores realmente molestos como este que deberíamos considerar corregir antes de fusionarnos, pero es posible que no necesariamente lo retrasen.

@dylanmckay LLVM6 se ha fusionado https://github.com/rust-lang/rust/pull/47828 : ¿qué significa eso para este RFC?

@kellerkindt todos los problemas enumerados en "Problemas actuales en el backend de AVR" siguen siendo ciertos. Es probable que el HEAD actual de avr-rust pueda volver a basarse y el interesante código específico de Rust se fusione, pero todavía no funciona.

Personalmente sigo a favor de

Creo que la mejor manera de avanzar sería proponer el parche de verdad una vez que libcore se compile sin modificaciones, o al menos sin muchas.

Aunque tener que evitar rebases adicionales es bueno.

Me pregunto cuál es el estado actual de Rust en AVR, ahora que estamos medio año después en el desarrollo. Dirijo un pequeño grupo de proyectos Arduino en mi ciudad, y me encantaría poder usar Rust en su lugar.

¡Buenas noticias!

Creo que la mejor manera de avanzar sería proponer el parche de verdad una vez que libcore se compile sin modificaciones, o al menos sin muchas.

¡Este es ahora el caso!

La bifurcación avr-rust actual no contiene ninguna modificación a libcore .

Las modificaciones necesarias para admitir AVR de stock Rus son:

• Las funciones de inicialización de backend de AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} se declaran y se llaman.
• Se ha agregado una especificación de objetivo de avr de base mínima avr-unknown-unknown . Esto modela el comportamiento predeterminado de avr-gcc de construir para el mínimo común denominador a menos que se especifique explícitamente. A diferencia de avr-gcc que admite explícitamente el argumento -mmcu=<avr mcu name> , no se ha agregado ningún argumento de línea de comando específico de AVR para AVR. Esto significa que se debe escribir un archivo JSON de especificación de destino personalizado para cada proyecto. Sin embargo, este es el caso de muchos proyectos integrados de Rust.
• En la bifurcación, el backend AVR LLVM siempre se compila y se vincula en la comprobación predeterminada de Rust y se agrega al archivo config.toml.example . ¿Debería incluirse AVR en el flujo ascendente de Rust de forma predeterminada, o también debería incluirse?
• Lógica específica de AVR agregada al compilador donde sea necesario para todos los nuevos objetivos
• Se ha agregado la convención de llamadas "avr-interrupt" . Esto permite extern "avr-interrupt" fn my_isr_handler() { .. } . Esto probablemente necesitaría pasar por el proceso de RFC para estabilizarse, pero podría estar equivocado.
• Se ha agregado soporte para una compilación condicional en la CPU, al estilo #[cfg(target_cpu = "...")] . La implementación se puede encontrar aquí . La implementación de esto es independiente del objetivo y, por lo tanto, también funciona para la compilación condicional basada en CPU para otras arquitecturas, como ARM. Esto permite que la caja ruduino incluya condicionalmente un módulo específico del dispositivo que exponga todos los IO, registros y módulos que son compatibles con el silicio. Definitivamente, esto debe pasar por el proceso de RFC antes de ascender.

Probablemente sea hora de que envíe un RFC a LLVM-dev con respecto a la promoción del backend a un estado no experimental.

Puede ver el conjunto completo de cambios de Rust ascendente a avr-rust aquí .

Todavía hay un par de parches LLVM de los últimos dos meses que hemos seleccionado en este momento, pero los esfuerzos iniciales de Rust para separar la versión emscripten de LLVM de la versión de LLVM utilizada para todos los demás objetivos han hecho que sea realmente fácil de llevar estos cambios en el repositorio rust-lang/llvm , ya que ahora se actualiza con regularidad.

Los <4 parches LLVM seleccionados con precisión que tenemos están actualmente en revisión en LLVM ascendente, por lo que una vez que un revisor encuentra suficiente tiempo, esos parches flotarán automáticamente en Rust ascendente. Upstream Rust también tiene parches específicos de Rust específicos del objetivo, por lo que los parches LLVM seleccionados probablemente no sean realmente un bloqueador para fusionar avr-rust upstream

¿Alguna actualización sobre el estado de Rust en AVR?

¡También me interesa saber! Por ahora, decidí piratear la pastilla azul STM32, pero definitivamente me gustaría volver a arduino una vez que el soporte para avr en rust esté listo.

A @slowtec también nos encantaría usar Rust para nuestros proyectos de AVR y, por supuesto,

Bump, me encantaría que se hiciera oficial el apoyo. Intentaré usar la bifurcación para un proyecto.

Actualización: en este momento, estamos actualizando la bifurcación a una versión más nueva de Rust (avr-rust / rust # 137). Hay dos errores que hemos encontrado y que hemos detectado.

LLVM ERROR: se agotaron los registros durante la asignación de registros

Esto se ha corregido en el tronco LLVM en llvm / llvm-project @ 45eb4c7e55341c0b83a21dedecc092e273795eda. Estoy seleccionando esto en nuestra bifurcación LLVM ahora. Este error fue históricamente el mayor problema en el backend, surgiendo en la mayoría de los códigos con muchos punteros.

ERROR LLVM: No se puede seleccionar: t2: i16 = addrspacecast [1 -> 0] undef: i16
t1: i16 = indef
En función: _ZN4core3ptr87_ $ LT $ impl $ u20 $ core..fmt..Debug $ u20 $ for $ u20 $ inseguro $ u20 $ fn $ LP $ A $ RP $$ u20 $. $ GT $$ u20 $ Ret $ GT $ 3fmt17h0fdf8ca7140def9b

Éste es más difícil de arreglar. Se debe a que Rust maneja mal los punteros de función en las arquitecturas de Harvard, donde hay dos espacios de direcciones de puntero separados para acceder a la memoria principal y la memoria del programa.

La explicación está mejor hecha por @ ecstatic-morse

El problema subyacente es que * const T siempre tiene addrspace (0). Creo que las conversiones explícitas (ptr como * const T) deberían preservar el espacio de direcciones de su entrada aquí.

El error está expuesto por la implementación std::fmt::Debug para funciones y punteros de función. Rust emite una desreferencia de puntero con un tipo de puntero de destino de addrspace(0)* i16 , utilizando rutinas LLVM que insertarán implícitamente un bitcast (iN -> iM bits) o un espacio de direcciones emitido si es necesario. En el caso de punteros de función, Rust debería codificar un puntero addrspace(1)* i16 , de modo que LLVM no tenga que mapear ( addrspacecast ) punteros PROGMEM a punteros RAM una tarea imposible porque no hay mapeo de memoria y los espacios de direcciones no se superponen.

Este error es el principal bloqueador.

Espero que Rust aguas arriba se extraiga del maestro LLVM (AFAICT, es más o menos en la versión 8.0) para que podamos eliminar un montón de selecciones de cereza.

Recientemente obtuve las https://github.com/dylanmckay/avr-compiler-integration-tests/ pruebas exitosas usando un emulador AVR, lo cual es genial porque no hay otro conjunto de pruebas que realmente ejecute el ensamblaje AVR escupido por LLVM. Configuré un corredor de GitLab para ejecutar pruebas para cada confirmación de AVR-Rust (a través de un espejo de repositorio de GitLab), pero no es muy útil porque GitLab no admite compilaciones de CI en solicitudes de extracción, ya que el código real está alojado en un repositorio bifurcado.

Gracias por la actualización @dylanmckay. Todos apreciamos el esfuerzo que ha puesto en esto.

Ahora hemos actualizado la bifurcación en la parte superior de Rust base rust-lang / rust @ fb7cca33f , el programa blink se compila con éxito.

¿Se detuvo este problema?

¿Tiene alguna actualización sobre esto? ¿Sigue estancado el PR en el tema del espacio de direcciones?

Hola @dylanmckay , perdón por molestarme con esto ... ¿hay alguna actualización sobre el tema?

Hola a todos, aquí hay algunos comentarios míos.

Correcciones de selección de cerezas

Casi todos los arreglos requeridos para que libcore funcione se han transmitido al maestro LLVM y actualmente existen en la bifurcación rust-lang / llvm. Ayer comencé un PR para actualizar la bifurcación AVR a 1.39.0 (avr-rust / rust # 155), solo tuve que seleccionar una solución que aún no estaba allí: avr-rust / llvm @ 4350776601bc671e6e055bfbe32add34b70d2635.

libcore no se puede compilar sin modificaciones

Ya no necesitamos una bifurcación libcore personalizada para usar AVR. Actualmente solo hay una modificación a libcore en la bifurcación avr-rust: avr-rust / rust @ 44240ac59c5949b8a9fd191f5cd666d0206fbe85 : reescribe un lanzamiento de puntero para obtener la generación de infrarrojos correcta.

Dependemos de

Cualquier operación en punteros de función que no sea 'llamar' accede a la RAM, no a la memoria del programa (avr-rust # 68)

Esto ha sido arreglado.

Los cambios de 32 bits generan llamadas a una rutina del compilador-rt que no existe (avr-llvm / llvm # 163)

Este sigue siendo un tema doloroso. Sospecho que la mejor solución será escribir un código de reducción personalizado en el backend de LLVM AVR que reduzca estos cambios al ensamblaje puro, eliminando cualquier dependencia de ABI en compiler-rt o libgcc. No estoy seguro de cuánto más grande podría ser el tamaño del código generado, puede que no sea una buena idea.

Preguntas antes de upstream

RFC y convenciones de llamadas inestables

Publiqué este comentario en el hilo

Se ha agregado la convención de llamada "avr-interrupt". Esto permite extern "avr-interrupt" fn my_isr_handler () {..}. Esto probablemente necesitaría pasar por el proceso de RFC para estabilizarse, pero podría estar equivocado.

¿Se pueden agregar convenciones de llamadas inestables sin pasar por el proceso de RFC?

Actualmente, tenemos "avr-interrupt" y "avr-non-blocking-interrupt" debajo de la puerta de función #![feature(abi_avr_interrupt)] . ¿Podrían estos ser transmitidos como convenciones de llamadas inestables, a la espera de una RFC de estabilización futura?

Buildbots

La actualización de un backend LLVM requiere la configuración de un buildbot dedicado que ejecute pruebas para ese backend y su mantenimiento. ¿Es este el caso de Rust? ¿Cómo nos aseguramos de que el conjunto de pruebas se ejecute en modo AVR en cada pulsación? ¿Qué hicieron otros backends (como WASM)?

Distribución

¿"Fusionar la bifurcación avr-rust en sentido ascendente" significa simplemente fusionar las dos bifurcaciones en una, pero todavía requiere una compilación desde la fuente? Quizás sea posible distribuir un backend, pero ¿solo por la noche? ¿Qué hicieron los otros backends?

Aparte de eso, los parches específicos de avr-rust son muy delgados, sin ningún truco retorcido hoy en día.

El conjunto de parches completo se puede ver aquí https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support

Mi conjunto de parches WIP 1.39.0 rebase (que es en su mayoría idéntico) se puede encontrar aquí https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support-1.39.0-4560ea788c . Esto debería fusionarse con avr-rust / master en los próximos días.

No puedo pensar en nada específico que bloquee esto; tal vez, es hora de enviar parches y ver cómo va.

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

Mencioné este problema anteriormente, pero no creo que bloquee el upstreaming del backend de AVR. Deberíamos poder conseguir una versión funcional y útil de rustc con AVR sin él. Estoy seguro de que hay soluciones y trucos que podemos hacer al respecto. detección de dispositivos en cajas de AVR mientras tanto, después de que el backend se haya fusionado hipotéticamente, y antes de que una API oficial de consulta de cpu de destino aterrice en Rust oficial.

¡El Vive! Gracias por la actualización @dylanmckay , progreso emocionante.

¡Buen trabajo @dylanmckay! Gracias por mantenernos informados.

Un poco fuera de tema, pero: ¿rustc for avr podría hacer FFI con bibliotecas C?
Hay muchas bibliotecas maduras ya disponibles para avr pero escritas en C / C ++.
Sería genial poder crear algunos envoltorios de estilo óxido para ellos y reutilizarlos en nuestros proyectos de rust avr.

Rust ya puede hacer FFI con C en general.

¡Sí, y eso es realmente genial! Sin embargo, la pregunta es: ¿se traduce a rust-avr?

Siempre que el C ABI de LLVM para AVR coincida con el de gcc, debería funcionar

¿Se pueden agregar convenciones de llamadas inestables sin pasar por el proceso de RFC?

Mi voto es sí , ya que el cambio para admitir las convenciones de llamadas AVR es básicamente solo darles un nombre y asignarlos al número LLVM. No se necesitan cambios fundamentales en el código, ya que ya tenemos soporte para convenciones inestables.

La actualización de un backend LLVM requiere la configuración de un buildbot dedicado que ejecute pruebas para ese backend y su mantenimiento. ¿Es este el caso de Rust? ¿Cómo nos aseguramos de que el conjunto de pruebas se ejecute en modo AVR en cada pulsación? ¿Qué hicieron otros backends (como WASM)?

El sistema de niveles de Rust está un poco definido, pero creo que lo correcto es fusionar el código específico de AVR . Entonces AVR será de nivel 3 , lo que significa que no se construye ni se prueba automáticamente, solo se queda en el código. Como mínimo, esto significa que esos archivos se mantendrán actualizados con los cambios del compilador.

¿"Fusionar la bifurcación avr-rust en sentido ascendente" significa simplemente fusionar las dos bifurcaciones en una, pero todavía requiere una compilación desde la fuente?

Que yo sepa, sería enviar el compromiso como un PR. Nuestra bifurcación personalizada efectivamente moriría / se convertiría en un lugar para rastrear detalles específicos de AVR hasta que se convierta en un objetivo más ampliamente utilizado.

quizás, es hora de enviar parches

Creo que sí.

@edvorg muy en el tema de la OMI

Un poco fuera de tema, pero: ¿rustc for avr podría hacer FFI con bibliotecas C?
Hay muchas bibliotecas maduras ya disponibles para avr pero escritas en C / C ++.

Sí ... sobre todo. La convención de llamadas de AVR implementada por el backend de AVR está diseñada para coincidir con la de AVR-GCC (documentada aquí ). Hay algunas peculiaridades, pero el parche LLVM D68524 que necesito revisar debería solucionarlas.

Los sitios de llamada de Rust siempre podrán invocar correctamente las funciones compiladas de Rust o avr-clang (ya que avr-clang C usa la misma implementación de convención de llamadas extern "C" que la interfaz de Rust), y la interacción con AVR-GCC _ debería_ funcionar, especialmente para firmas de funciones simples, pero a veces puede ahogarse (consulte la descripción de D68524 para obtener más detalles).

Algún avance en esto ?
Sólo curioso.

Solicitud enviada para convertir el backend de LLVM AVR en un backend oficial: https://reviews.llvm.org/D75099

@dylanmckay Si se acepta, ¿cuáles son las piezas restantes para cerrar este problema?

@dylanmckay Si se acepta, ¿cuáles son las piezas restantes para cerrar este problema?

Técnicamente, Rust funcionará con backends oficiales y experimentales. He obtenido el número 69478 para el upstreaming de la mayor parte del backend.

No estoy seguro de si la fusión de AVR como un objetivo de Nivel 3 se basa en que AVR se convierta en un backend oficial de LLVM; pensamientos bienvenidos.

Pensando en ello, la distinción oficial versus experimental de LLVM se puede mapear en el sistema de niveles de Rust, del cual Rust tiene tres niveles y LLVM tiene dos. Un backend oficial de LLVM corresponde a una combinación de Niveles 1 y 2, básicamente, incluidos en conjuntos de pruebas y lanzamientos oficiales. Un backend experimental LLVM, por lo que puedo decir, es semánticamente el mismo que un backend de Rust Tier 3; incluido en el árbol de fuentes, no incluido en las versiones de forma predeterminada, no incluido en las pruebas de CI predeterminadas, etc.

Entonces supongo que las únicas piezas restantes para cerrar este problema serán las que surjan en la revisión del código de # 69478.

tl; dr, el backend de AVR se convertiría en un objetivo ascendente de nivel 3 en rust-lang / rust # 69478 si se fusionara, matando así la bifurcación.

La única diferencia entre la bifurcación avr-rust / rust y # 69478 es la marca target_cpu cfg que existe en la bifurcación AVR pero no en sentido ascendente. Lo he dejado fuera del PR inicial.

cuales son las piezas restantes

Estoy bastante seguro de que todavía hay una serie de errores de compilación de varios tipos de código, por lo que todavía se necesita más gente para probar cosas y minimizar los errores y corregirlos.

Sin embargo, levantarse al vapor bajará el listón para que la gente pruebe cosas, ya que pueden obtener un Rust normal todas las noches en lugar de compilar la bifurcación generalmente desactualizada.

Una vez que se transmita como un objetivo de nivel 3, ¿el desarrollo de AVR funcionará con la función -Z build-std cargo, o requerirá xargo? ¿El LLD que se envía con Rust es compatible con AVR o se requerirán enlazadores GNU?

¿Funcionará el desarrollo de AVR con la función -Z build-std cargo, o requerirá xargo? ¿El LLD que se envía con Rust es compatible con AVR o se requerirán enlazadores GNU?

No puedo decir que no funcionen, pero todo lo que he hecho ha utilizado enlazadores Xargo y GNU.

Los enlazadores GNU son difíciles de configurar en Windows y xargo requiere una herramienta más para instalar, por eso pregunto.

¿El LLD que se envía con Rust es compatible con AVR o se requerirán enlazadores GNU?

LLD solo tiene un soporte muy básico para vincular AVR, todavía no puede vincular ningún programa real. Por lo tanto, se requerirá avr-ld .

Por eso estoy preguntando.

No se equivoque, también creo que ese es el objetivo final correcto, simplemente puede que no sea el estado actual del mundo. Honestamente, estaría feliz de hacer que los gastos generales sean cada vez más bajos. Fusionarlo es solo el primer paso hacia eso.

El backend AVR ahora se ha habilitado como un objetivo LLVM oficial: tada: LLVM master contiene ahora soporte AVR por defecto. La primera versión de LLVM que incluye AVR de forma predeterminada será LLVM 11 en aproximadamente 6 meses.

¡Bonito! Gracias por todo el esfuerzo que está poniendo en esto.

¡Muy genial!

Felicitaciones @dylanmckay por este increíble logro. La comunidad le agradece su trabajo en esto.

He estado siguiendo este problema por un tiempo y, aunque sé que esto es mayormente fuera de tema, me interesa lo que esto significa para el usuario promedio que no proviene de la fuente ... ¿Es un proceso complicado obtener un ¿Arduino Uno en funcionamiento con Rust nativo usando esto? Lo que más me interesa es esto, ya que Rust tiene suficientes protecciones que probablemente no puedo causar tantos momentos uy xP

@ Jimmio92 Por lo que puedo decir, sí. Como en "sí, es complicado". O al menos largo y tedioso, incluso si no es particularmente complicado, ya que todavía tiene que construir esta bifurcación personalizada del compilador Rust desde la fuente, lo que también implica construir LLVM desde la fuente. Eso suele llevar un par de horas, si todo va bien.

_{Mi experiencia personal con LLVM es, sin embargo, que la mayoría de las veces, simplemente no le gusta algo en su sistema (al menos ciertamente en macOS, es más fácil en Linux y ciertamente ni siquiera sueña con hacer esto en Windows), por lo que inevitablemente terminará masajeando las rutas de instalación y las bibliotecas personalizadas hasta que tenga éxito o se rinda.}

Lo que significan las (excelentes) noticias anteriores es solo esto: los desarrolladores de LLVM ahora están apuntando / respaldando AVR oficialmente (?), Y la próxima versión de LLVM incluirá soporte AVR. No hay nada que decir que Rust ahora también admite o admitirá AVR a corto plazo. Si observa los problemas y los comentarios anteriores, puede ver que tomará mucho trabajo hasta que el soporte de AVR "simplemente funcione" con una cadena de herramientas estándar de Rust.

¿Hay algún proceso / ejemplo en el que pueda analizar las correcciones AVR seleccionadas desde el maestro LLVM en la bifurcación Rust LLVM?

Además, ¿Rust todavía rastrea LLVM master? Por lo que parece, rastrea la versión actual más algunas correcciones seleccionadas. ¿Se siguen aceptando los RP para actualizar la versión LLVM a master?

@dylanmckay

Además, ¿Rust todavía rastrea LLVM master?

Como habrás notado, ahora rastrea los lanzamientos.

¿Se siguen aceptando los RP para actualizar la versión LLVM a master?

No lo creo pero cc @nikic

@dylanmckay hay un montón de correcciones en la bifurcación LLVM de Rust en comparación con la versión 10.0: https://github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05

¿Hay algún proceso / ejemplo en el que pueda analizar las correcciones AVR seleccionadas desde el maestro LLVM en la bifurcación Rust LLVM?

Hay instrucciones disponibles aquí: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

Además, ¿Rust todavía rastrea LLVM master? Por lo que parece, rastrea la versión actual más algunas correcciones seleccionadas. ¿Se siguen aceptando los RP para actualizar la versión LLVM a master?

Actualmente, Rust realiza un seguimiento de las versiones de LLVM, porque esto permite a las personas realizar fácilmente LTO en varios idiomas con una versión de clang correspondiente. Entonces, la respuesta predeterminada aquí es probablemente "no".

Dicho esto, se ha debatido sobre la actualización a LLVM master para mitigar las regresiones en tiempo de compilación de LLVM 10. Actualmente estoy trabajando en eso con fines de evaluación. Sin embargo, creo que es más seguro asumir que esto no sucederá y enviar selecciones selectivas contra nuestra bifurcación LLVM 10 (¿hay muchas?)

¡La bifurcación se ha fusionado! Escribiré una actualización adecuada esta tarde.

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

Escribiré una actualización adecuada esta tarde.

Estoy interesado en dicha actualización. ¿Dónde planeas publicarlo @dylanmckay (así que sé dónde buscar: levemente_smiling_face :)?

¡He estado esperando ansiosamente esta adición al ecosistema de Rust durante literalmente años! Sin embargo, mis ingenuos intentos de usar esto en el maestro parecen defectuosos.

Construí master rust con el estándar ./x.py build , vinculado como cadena master herramientas src/main.rs para usar llvm_asm! ):

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

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

Esto falla con:

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

Supongo que todavía se requiere una configuración que me falta.

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

No esperaría que nada funcione ahora, ya que libcore es parte de lo que está mal compilado.

La horquilla AVR rustc se ha fusionado aguas arriba.

La bifurcación aguas arriba no se puede utilizar en general todavía. Hay algunas cosas que deben suceder primero.

Las correcciones ascendentes de AVR LLVM que Rust aún no tiene deben ser seleccionadas

Para responder a la pregunta de @nikic , hay un máximo de 20 confirmaciones LLVM que deben seleccionarse.

He estado usando un script para seleccionar automáticamente _todos_ los compromisos de AVR desde LLVM en sentido ascendente en una bifurcación local.
Este es un gran martillo y habrá correcciones seleccionadas que son innecesarias: hay correcciones LLVM ascendentes que deben llevarse a Rust ascendentes antes de que el backend se vuelva utilizable. será necesario filtrarlos y recogerlos para llevarlos río arriba de Rust.

Compilación del programa de parpadeo de LED AVR desde la rama principal de Rust aguas arriba

Como el esfuerzo aguas arriba ha estado sucediendo durante algunos meses, la bifurcación avr-rust aguas abajo
todavía está en una versión particularmente antigua de Rust. Desde entonces, ha habido al menos un cambio en el flujo ascendente de Rust que requiere generalización para admitir AVR sin afectar los errores de afirmación de LLVM. Abrí la solicitud de extracción # 73270 para solucionarlo.

No estoy seguro de si ha habido otros cambios en Rust aguas arriba que necesiten cambios para AVR, probablemente no.

Una vez que haya hecho funcionar el programa blink, publicaré otra actualización porque en ese momento, el soporte AVR ascendente debería estar listo para su uso / experimentación.

¿Dónde debe producirse / publicarse la comunicación AVR?

@wezm plantea un buen punto: no hay necesariamente un canal de comunicación "bendecido" para las actualizaciones. Este boleto ha funcionado bien, pero inevitablemente se cerrará pronto.

El canal AVR-Rust Gitter es la opción existente más natural. Me gusta la idea de una lista de correo (pero no me gusta la idea de alojar un servidor de correo si es posible). El canal de Gitter tiene discusiones en él, por lo que quizás sería útil algo como una lista de correo.
Quizás crear un blog sería bueno para centralizar anuncios / actualizaciones. Me gustaría tener un "medio oficial" para que las personas que quieran actualizaciones informales no se lo pierdan. Supongo que un blog requiere una verificación constante de nuevas publicaciones, mientras que una lista de correo notifica inherentemente
todos los que estén interesados. Sugerencias bienvenidas.

Preguntas abiertas

• ¿Deben trasladarse los problemas de GitHub en la bifurcación avr-rust al repositorio de Rust ascendente?
  ** Independientemente, se deben plantear nuevos problemas en el repositorio ascendente; el antiguo rastreador de problemas deberá cerrarse.
  
  
  
  • ¿Dónde deberían estar las instrucciones para compilar Rust con AVR?
  
  

Las cosas más importantes para el futuro (lea: prioridades)

• Empaquetado y distribución de binarios AVR Rust. Compilar Rust puede ser un gran dolor de cabeza para el usuario ocasional,
  muchas distribuciones parecen tener problemas de vez en cuando en ciertos flujos de trabajo. Varios errores OOM notificados erróneamente como
  errores del compilador. La barrera de entrada es innecesariamente alta y debe ser más baja, solo descargue y listo.
  Seguimiento de https://github.com/avr-rust/rust/issues/162
• Crear una lista de configuraciones "admitidas", o al menos probadas. Necesitamos una tabla de (rustc version, Xargo version) así que
  que los cambios en las API de Rust privadas de las que depende Xargo no rompan la cadena de herramientas de AVR Rust en la actualización.
  Xargo está en modo de mantenimiento: cargo-xbuild parece bastante limitado (lo probé hace unas semanas, no recuerdo el motivo),
  es posible que debamos bifurcar Xargo. Quizás sea mejor agregar las herramientas directamente a Cargo (hay un problema de seguimiento para esto).
• Configurar algún tipo de página de inicio para el proyecto, incluidos enlaces para descargar
• Prueba de integración (en un AVR emulado / simulado, en cada confirmación)

Por el momento, me aseguraré de volver a publicar las actualizaciones en este problema de GitHub, hasta que se pueda encontrar un medio mejor. También los publicaré en Gitter.

Quizás crear un blog sería bueno para centralizar anuncios / actualizaciones. Me gustaría tener un "medio oficial" para que las personas que quieran actualizaciones informales no se lo pierdan. Supongo que un blog requiere una verificación constante de nuevas publicaciones, mientras que una lista de correo notifica inherentemente
todos los que estén interesados. Sugerencias bienvenidas.

Mi preferencia personal está fuertemente a favor de un blog (con un canal RSS). Creo que los blogs suelen aparecer mejor en los resultados de los motores de búsqueda y es más agradable vincularlos que los hilos de las listas de correo. La fuente RSS resuelve el aspecto de verificación / notificación.

No estoy 100% seguro de que sea el mejor lugar para hacerlo, pero está el blog Embedded WG. Podría ser un canal de comunicación de bajo esfuerzo.

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

¿Quizás también una cuenta de Twitter? Se puede usar para compartir nuevas publicaciones de blog (para mantenerse actualizado).

Creo que el grupo de trabajo integrado estaría encantado de ayudar aquí. Tenemos una cuenta de Twitter @rustembedded y ciertamente también podemos incluir noticias relacionadas con AVR en el boletín.

También creé la etiqueta O-AVR un tiempo, así que siéntase libre de usar el rastreador de problemas de Rust para problemas específicos de AVR también (pero tenga en cuenta que hay 1.5k personas viendo el repositorio). Además de eso, es posible que desee coordinar en Zulip, ya que allí es donde reside la mayoría de los equipos de Rust. También estamos en el proceso de aumentar los "grupos objetivo" que se centran en objetivos específicos de Rust (por ejemplo, Windows o Arm), AVR también podría ser una buena opción para eso. No dude en comunicarse con Zulip para esto.

Actualizar.

Quedan dos cosas antes de que libcore se pueda compilar para AVR en una rama rust-lang / master de stock:

1. Hay una solicitud de extracción que corrige una serie de errores de "conversión de espacio de direcciones inválido" en AVR, que relacionan cómo los punteros de función para las arquitecturas de Harvard deben etiquetarse como addrspace(1) comparación con los objetivos de Von-Neumann que están bien con el valor predeterminado actual de Rust de addrspace(0) . rust-lang / rust # 73270: actualmente se encuentra en revisión de código.

~ 2. Hay otro error que bloquea el funcionamiento del ejemplo blink : avr-rust / rust # 92. Hay un parche que aún no se ha actualizado y que lo solucionará: https://reviews.llvm.org/D68524. Esto se transmitirá y luego se seleccionará en la bifurcación LLVM de Rust muy pronto una vez que pase contra la unidad y las pruebas de integración. ~ Se ha fusionado en LLVM ascendente.

Una vez que se hayan hecho estas dos cosas, el objetivo Rust AVR actualizado podrá compilar el código AVR al mismo nivel que la bifurcación avr-rust / rust actual, y luego podemos comenzar el proceso de actualización del ejemplo blink , arduino caja, documentación, guías, para la rama ascendente. Entonces, la rama ascendente debería estar lista para uso experimental.

Un TODO más:

1. ~ Agregue plomería AVR para la nueva sintaxis de ensamblaje en línea en Rust upstream ~
   
   
   
   • ~ Una vez que se admite la nueva sintaxis de ensamblaje en línea, la caja Arduino debe actualizarse para usarla
     
     Una vez que se haya actualizado la caja de Arduino, actualice la caja de parpadeo a la nueva versión. ~ Podemos usar la macro anterior a través de llvm_asm! por ahora, ya que todavía existe en la noche.
   
   
2. Cherry-pick parches de corrección AVR (en su mayoría Ayke) desde el maestro LLVM hasta la bifurcación Rust LLVM ascendente (EDITAR: PR: https://github.com/rust-lang/llvm-project/pull/66)

Aquí está la rama con todo: https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. Esta rama es suficiente para compilar libcore.

Está construido a partir de upstream rust-lang/master pero también incluye el parche LLVM aún no actualizado

Actualización : se abrió una solicitud de extracción que incluye todas las correcciones de LLVM ascendentes.

Aquí hay una lista exhaustiva del trabajo restante antes de que el programa de parpadeo de LED se pueda compilar y ejecutar correctamente.

Trabajo restante

• [x] Land Rust PR rust-lang / rust # 73270 . Esta solicitud de extracción corrige una serie de errores de "conversión de espacio de direcciones no válida" en AVR, que relacionan cómo los punteros de función para las arquitecturas de Harvard deben etiquetarse como addrspace (1) en comparación con los objetivos de Von-Neumann que están bien con el valor predeterminado actual de Rust de addrspace (0) . Actualmente se encuentra en revisión de código.
• [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Esto extrae todas las correcciones de AVR requeridas desde LLVM ascendente a la bifurcación LLVM de Rust. Al final, hubo ~ 17 ~ 16 arreglos de LLVM que debían seleccionarse con precisión.
• [x] Land Rust PR rust-lang / rust # 73658 que actualiza la versión del submódulo LLVM . Los documentos del compilador de Rust tienen instrucciones para hacer esto. Actualmente se encuentra en revisión de código .
• [x] Land Rust PR ~ rust-lang / rust # 74625 ~ rust-lang / rust # 74631 . En 79a42e37084d0, Rust comenzó a pasar incondicionalmente el argumento --eh-frame-hdr al vinculador. El vinculador AVR-GCC no es compatible con este indicador, por lo que se agrega un caso especial para evitar pasarlo para AVR, similar a las exclusiones existentes para Windows. Solaris y UEFI.

Quizás sea mejor agregar las herramientas directamente a Cargo (hay un problema de seguimiento para esto).

Supongo que este es el problema correcto: rust-lang / cargo # 4959.

cargo build -Z build-std=core ha funcionado bien para mis casos de ejemplo de AVR.

@shepmaster que parece acercarme de todos modos, ¡gracias! Parece que estoy atascado en las cosas de bitcast ahora, así que esperaré a que se fusione (ya que parece que me falta un archivo necesario para construir el PR, e IDK lo que estoy haciendo).

En el proceso de uso de -Z build-std=core necesitaba proporcionar un triple objetivo, así que ejecuté rustc +master --print target-list | grep avr y encontré avr-unknown-unknown . Pero el problema archivado avr-llvm / llvm # 35 parece hacer que parezca que el triple debería ser avr-atmel-none (que de todos modos tiene más sentido para mí). ¿Es necesario actualizar algo aquí o me falta algo?

avr-unknown-unknown es correcto.

Preguntas abiertas

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

No creo que esto importe demasiado por parte del usuario. Esto fue bastante fácil de encontrar a través de ddg y / o this-week-in-rust.
Lo que sea más fácil para los desarrolladores.

Preguntas abiertas

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

No creo que esto importe demasiado por parte del usuario. Esto fue bastante fácil de encontrar a través de ddg y / o this-week-in-rust.
Lo que sea más fácil para los desarrolladores.

Creo que las instrucciones para compilar Rust con AVR deberían estar de alguna manera en https://docs.rust-embedded.org/

Muy bien, actualiza la hora.

Todos los parches necesarios para AVR existen en el compilador nocturno actual de Rust a partir de la noche de hoy rustc 1.47.0-nightly (0820e54a8 2020-07-23) . El compilador nocturno de Rust, sin modificaciones, ahora puede compilar el ejemplo de parpadeo de LED con éxito y generar un archivo AVR ELF.

• Nueva página de inicio del proyecto centralizada creada en https://avr-rust.com/
• Un nuevo libro: se ha creado la guía AVR-Rust , alojada en las páginas de GitHub en book.avr-rust.com.
• El repositorio de horquillas avr-rust / rust ha quedado obsoleto. El repositorio aún no se ha archivado porque hay problemas existentes que deben migrarse antes de que se bloqueen y cierren permanentemente.
• Xargo ya no es necesario: la bandera -Z build-std en el flujo ascendente de Rust reemplaza la necesidad en AVR. Ya no se requiere una horquilla de carga, la carga corriente arriba es suficiente.

El compilador nocturno de Rust ahora puede considerarse el canal recomendado para Rust con soporte AVR.

Estoy cerrando este problema ahora, ¡lo logramos!

Los pasos para informar errores se pueden encontrar en la Guía de AVR .

La guía AVR y el ejemplo de parpadeo en https://github.com/avr-rust/blink son los mejores recursos para comenzar a usar el objetivo.

Un profundo agradecimiento a todos los que discutieron y apoyaron el proyecto a través de este esfuerzo de upstreaming - es muy apreciado.

ALETA

Wow wow wow.

Gracias por todos los que contribuyeron a esto. ¡He esperado este día desde siempre!

Dylan McKay antes de portar rust a avr

Y después

¡Gracias por todo el trabajo duro, hombre! :-) ¡Tomar un buen descanso!