+1! Avr rust embutido no compilador apropriado seria muito útil. Está quase livre de bugs agora.

Não totalmente livre de bugs :)

Vou atualizar a descrição para incluir algumas informações sobre o estado dos bugs wrt de backend

Quase embora 😄. Só faltam alguns

Em geral, aceitamos bem as plataformas upstream em rust-lang / rust, desde que não nos sobrecarreguem de manutenção! Alguns pensamentos específicos do que você está pensando:

• Selecionar commits LLVM de vez em quando é totalmente OK, acho que vocês já passaram pelo processo algumas vezes também :)
• A falta de intrínsecos no compiler-rt está bem para nós, você tem a opção de implementá-los no Rust também por meio do projeto compilador embutido.
• O patch que você tem parece muito bom, embora eu ache que gostaríamos de trabalhar mais com os vários #[cfg] no libcore. Esses itens foram deixados de fora devido a "bugs no LLVM" ou porque, fundamentalmente, não têm suporte no AVR? O primeiro seria melhor feito "consertando o LLVM" de alguma forma, enquanto o último torna as coisas mais complicadas.

Em geral, atualmente temos todas as plataformas com a mesma interface uniforme de libcore / libstd, mas não está claro se isso permanecerá verdadeiro à medida que continuarmos pegando mais plataformas.

O patch que você tem parece muito bom, embora eu ache que gostaríamos de trabalhar mais com os vários # [cfg] no libcore. Esses itens foram deixados de fora devido a "bugs no LLVM" ou porque, fundamentalmente, não têm suporte no AVR?

É por causa de bugs no LLVM.

A única dúvida em minha mente é sobre o suporte dos tipos i128 / u128 - acho que para AVR, eles não são realmente úteis. O suporte de i128 em libcore está atualmente comentado por causa de um bug, mas pode haver outros bugs não descobertos, pois não é um codepath bem testado e realmente exerce o alocador de registro como o AVR apenas tem 32 bytes de registradores de uso geral.

Ainda é bastante provável que possamos fazer com que i128 funcione no AVR, não sei muito sobre os problemas específicos que ele aciona no back-end.

Eu acho que a melhor maneira de avançar seria propor o patch para real assim que a libcore _compilar_ sem modificações, ou pelo menos sem muitas.

Eu acho que a melhor maneira de avançar seria propor o patch para real, uma vez que o libcore compilar sem modificações, ou pelo menos sem muitas.

Parece razoável para mim!

A única dúvida em minha mente é sobre o suporte dos tipos i128 / u128 - acho que para AVR, eles não são realmente úteis.

Meu principal medo de não oferecer suporte a i128 no AVR é ​​que isso terá um efeito assustador na adoção de inteiros de 128 bits para fins de compatibilidade com AVR ou outras plataformas embarcadas. Por exemplo, se houver uma biblioteca que usa números inteiros de 128 bits, os usuários do AVR que quiserem usá-la irão arquivar problemas para interromper o uso. Isso pode tornar inteiros de 128 bits não "seguros" para uso em código Rust que se esforça para ser portátil, o que eu não gostaria que acontecesse.

um efeito assustador na adoção de inteiros de 128 bits para fins de compatibilidade com AVR ou outras plataformas incorporadas

Não acho que seja um grande negócio aqui. Dispositivos embarcados pequenos já têm limitações gigantescas (sem stdin / stdout, geralmente sem alocador, etc.) que tornam muito difícil simplesmente inserir em uma biblioteca arbitrária. Recentemente, descobri que double AVR GCC é, na verdade, um apelido para float ! Não sei se vamos manter essa estranheza ou não, mas afetaria as caixas muito mais do que i128 .

Acho que sempre teremos recursos especiais que são usados ​​para fazer uma caixa adequada para embutidos, assim como fazemos para no-std.

sem stdin / stdout, geralmente sem alocador, etc.

Você está descrevendo o ecossistema #![no_std] . Existem bibliotecas que visam este ecossistema. E a regra geral para esse ecossistema é tomar libcore como um dado, o que também inclui i128 . Cada alvo que não oferece suporte a i128 tem um efeito de refrigeração maior dentro desse ecossistema, porque a "participação de mercado" de um alvo incorporado é maior dentro do subconjunto de todo o ecossistema Rust, onde a família x86 não é um jogador muito relevante .

Não sei se vamos manter essa estranheza ou não, mas afetaria as caixas muito mais do que i128.

Interessante! Eu concordo que se nós apelidássemos de f64 a f32 (ou não fornecesse), isso afetaria mais o ecossistema. No entanto, se podemos nos esforçar para ter consistência, por que não deveríamos? Definitivamente, é possível implementarmos i128 .

Definitivamente, é possível implementarmos o i128.

Com certeza, e percebo que não afirmei claramente que acho que devemos implementar o i128 para AVR . No entanto, qualquer código que realmente use um i128 em um AVR será muito difícil.

No entanto, se podemos nos esforçar para ter consistência, por que não deveríamos?

Coerência com o quê , é a questão. Consistência com GCC ( f64 == f32 ) ou com todos os outros alvos de Rust ( f64 ! = f32 )?

Você está descrevendo o ecossistema #! [No_std].

Sim, é por isso que eu disse "recursos especiais que são usados ​​para fazer uma caixa adequada para embutidos, assim como fazemos para no-std." 😇

Um problema maior que está em minha mente desde que originalmente lançamos o patch usize 16 bits é que, fundamentalmente, os programadores de Rust e Rust tendem a assumir que usize é o "nativo" tamanho de um registro. AFAIK, isso é verdade para todas as outras plataformas Rust, mas não para AVR.

Coerência com o quê, é a questão. Consistência com GCC (f64 == f32) ou com todos os outros alvos Rust (f64! = F32)?

O nome f64 literalmente indica que tem 64 bits. Se você não obedecer ao nome, ele se tornará sem sentido, assim como em C.

Pontos positivos aqui, posso ver a preocupação em torno dos inteiros de 128 bits. Definitivamente acho que eles devem ser apoiados, embora não devamos encorajar seu uso. Eu odiaria ver caixas tendo que adicionar sinalizadores de recursos para coisas como impls de características em tipos i128 . Isso realmente não deve ser um problema, porque todas as coisas i128 não utilizadas devem ser eliminadas pelo vinculador.

O problema f32 / 64 é interessante. Minha principal preocupação em fazer f64 na verdade de 64 bits é que isso significa que C FFI pode ser muito frágil. Se os desenvolvedores não souberem que o AVR-GCC usa duplos de 32 bits, as chamadas por meio de FFI podem ler a memória não inicializada ou falha de segmento.

Imagino que poderíamos resolver isso mais ou menos esperando que os usuários usassem tipos da caixa libc . Poderíamos adicionar uma funcionalidade específica do AVR para definir c_double como f32 . Acho que podemos esperar que as pessoas usem a caixa libc em suas ligações FFI.

Algo a ser lembrado para a fusão, é necessário atualizar o tipo c_int usado na assinatura main() : https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

Editar: abriu um problema para isso, pois afeta o MSP430 também: https://github.com/rust-lang/rust/issues/44934

usado na assinatura principal ()

@mattico Talvez eu só tenha feito as coisas de uma maneira estranha, mas nenhum do meu código fez uso do main de Rust :

#[no_mangle]
pub extern fn main() {

Mais importante, nós realmente não pode voltar porque não há nada para onde voltar. Todo programa precisa ser executado para sempre.

@mattico Nós ainda teremos definitivamente que modificar libc para que os tipos correspondam a GCC para AVR

Oh, absolutamente, eu simplesmente não sei se main vai nos impactar em tudo.

@shepmaster Mesmo em plataformas não embarcadas, o tamanho de argc no main não importa, visto que erramos todo esse tempo e ninguém percebeu, exceto ao inspecionar o IR. Pode haver algum RTOS que usa um ponto de entrada main () padrão para seus processos? Independentemente disso, é fácil de corrigir.

Provavelmente levaria o mesmo tempo para enviar uma correção e digitar isso, agora que pensei sobre isso 😄

São apenas os problemas da libcore que impedem essa fusão? Só para sabermos onde concentrar os esforços.

Os únicos problemas que tive fora do libcore são erros estranhos do linker causados ​​por não sei o quê e também erros de bitshifting de 32 bits (falta de intrínseco, eu acho). Não sei se eles estão bloqueando a fusão.

chocol4te: São apenas os problemas da libcore que impedem essa fusão? Só para sabermos onde concentrar os esforços.

Sim - todo o trabalho necessário aqui precisa ser feito no LLVM .

Restioson: Os únicos problemas que tive fora do libcore são erros estranhos do linker causados ​​por não sei o quê e também erros de bitshifting de 32 bits (falta intrínseca, eu acho).

Isso porque todo o código que faz o backend do AVR engasgar está comentado :)

Restioson: Não sei se eles estão bloqueando a fusão.

Não diretamente, mas seria bom ter corrigido antes de o back-end ser mesclado. Existem alguns bugs realmente irritantes como este que devemos considerar consertar antes de fazer a fusão, mas eles podem não necessariamente impedi-los.

@dylanmckay LLVM6 foi mesclado https://github.com/rust-lang/rust/pull/47828 - o que isso significa para este RFC?

@kellerkindt todos os problemas listados em "Problemas atuais no back-end do AVR" ainda são verdadeiros. É provável que o HEAD atual do avr-rust possa ser rebaseado e o código específico do Rust interessante mesclado, mas isso ainda não faz o código funcionar.

Eu pessoalmente ainda sou a favor de

Eu acho que a melhor maneira de avançar seria propor o patch para real, uma vez que o libcore compilar sem modificações, ou pelo menos sem muitas.

Embora seja bom evitar rebasing extra.

Eu me pergunto o estado atual do Rust no AVR, agora que estamos meio ano depois em desenvolvimento. Eu gerencio um pequeno grupo de projetos do Arduino em minha cidade, e eu adoraria poder usar o Rust em seu lugar.

Então, boas notícias!

Eu acho que a melhor maneira de avançar seria propor o patch para real, uma vez que o libcore compilar sem modificações, ou pelo menos sem muitas.

Agora é esse o caso!

O fork avr-rust atual não contém nenhuma modificação em libcore .

As modificações necessárias para suportar AVR da Rus de estoque são:

• As funções de inicialização de backend do AVR LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} são declaradas e chamadas.
• Uma especificação de destino de AVR de base mínima avr-unknown-unknown foi adicionada. Isso modela o comportamento padrão de construção do avr-gcc para o menor denominador comum, a menos que seja explicitamente especificado. Ao contrário de avr-gcc que suporta explicitamente o argumento -mmcu=<avr mcu name> , nenhum argumento de linha de comando específico do AVR foi adicionado para o AVR. Isso significa que um arquivo JSON de especificação de destino customizado deve ser gravado para cada projeto. No entanto, este é o caso de muitos projetos incorporados do Rust.
• Na bifurcação, o backend AVR LLVM é sempre compilado e vinculado no checkout padrão do Rust e adicionado ao arquivo config.toml.example . O AVR deve ser incluído no Rust upstream por padrão ou também deve ser opcional?
• Lógica específica do AVR adicionada ao compilador quando necessário para todos os novos alvos
• A convenção de chamadas "avr-interrupt" foi adicionada. Isso permite extern "avr-interrupt" fn my_isr_handler() { .. } . Isso provavelmente precisaria passar pelo processo de RFC para se estabilizar, mas posso estar errado.
• Suporte para uma compilação condicional na CPU, a la #[cfg(target_cpu = "...")] foi adicionado. A implementação pode ser encontrada aqui . A implementação disso é independente do destino e, portanto, funciona para compilação condicional baseada na CPU para outras arquiteturas também, como ARM. Isso permite que a caixa ruduino inclua condicionalmente um módulo específico do dispositivo que expõe todos os IOs, registradores e módulos que são suportados no silício. Isso definitivamente precisa passar pelo processo RFC antes do envio.

Provavelmente é hora de eu enviar um RFC para o LLVM-dev sobre a promoção do back-end ao status não experimental.

Você pode ver o conjunto completo de alterações de Rust upstream para avr-rust aqui .

Ainda há alguns patches de LLVM dos últimos dois meses que escolhemos a dedo no momento, mas os esforços do Rust upstream para separar a versão emscripten do LLVM da versão do LLVM usada para todos os outros destinos tornou muito fácil de trazer essas mudanças em rust-lang/llvm repo, já que agora é atualizado regularmente.

Os <4 patches LLVM escolhidos a dedo que temos estão atualmente em revisão no LLVM upstream e, portanto, assim que um revisor encontrar tempo suficiente, esses patches irão flutuar automaticamente no Rust upstream. Upstream Rust também tem patches específicos de Rust específicos para o alvo e, portanto, patches LLVM escolhidos a dedo provavelmente não são realmente um bloqueador para mesclar avr-rust upstream

Alguma atualização sobre o status do Rust no AVR?

Também estou interessado em saber! Por enquanto, mudei para hackear o STM32 blue pill, mas definitivamente gostaria de voltar ao arduino assim que o suporte para avr in rust estiver pronto.

Nós @slowtec também adoraríamos usar o Rust para nossos projetos AVR e, claro,

Bump, adoraria ver o suporte oficializado. Vou tentar usar o fork para um projeto.

Atualização: no momento, estamos atualizando o fork para uma versão mais recente do Rust (avr-rust / rust # 137). Encontramos dois bugs que encontramos.

ERRO LLVM: esgotou os registros durante a alocação de registro

Isso foi corrigido no tronco LLVM em llvm / llvm-project @ 45eb4c7e55341c0b83a21dedecc092e273795eda. Estou escolhendo isso em nosso fork do LLVM agora. Este bug foi historicamente o maior ponto problemático no back-end, surgindo na maioria dos códigos com muitos ponteiros.

ERRO LLVM: Não é possível selecionar: t2: i16 = addrspacecast [1 -> 0] undef: i16
t1: i16 = undef
Em função: _ZN4core3ptr87_ $ LT $ impl $ u20 $ core..fmt..Debug $ u20 $ por $ u20 $ inseguro $ u20 $ fn $ LP $ A $ RP $$ u20 $. $ GT $$ u20 $ Ret $ GT $ 3fmt17h0fdf8ca7140def9b

Este é mais difícil de consertar. É causado por ponteiros de função de manipulação incorreta do Rust em arquiteturas de Harvard, onde há dois espaços de endereço de ponteiro separados para acessar a memória principal e a memória do programa.

A explicação é melhor feita por @ ecstatic-morse

O problema subjacente é que * const T sempre tem addrspace (0). Acho que as conversões explícitas (ptr as * const T) devem preservar o espaço de endereço de sua entrada aqui.

O bug é exposto pela implementação std::fmt::Debug para funções e ponteiros de função. Rust emite uma desreferência de ponteiro com um tipo de ponteiro de destino de addrspace(0)* i16 , usando rotinas LLVM que irão inserir implicitamente um bitcast (iN -> bits iM) ou um espaço de endereço convertido, se necessário. No caso de ponteiros de função, Rust deve codegen um ponteiro addrspace(1)* i16 , de modo que o LLVM não precise mapear ( addrspacecast ) ponteiros PROGMEM para ponteiros RAM uma tarefa impossível porque não há mapeamento de memória e os espaços de endereço não se sobrepõem.

Este bug é o principal bloqueador.

Espero que o Rust upstream extraia do mestre LLVM (AFAICT, está praticamente na versão 8.0) para que possamos remover um monte de seleções.

Recentemente, tive os https://github.com/dylanmckay/avr-compiler-integration-tests/ testes bem-sucedidos usando um emulador de AVR, o que é ótimo porque não há nenhum outro conjunto de testes que realmente execute o assembly AVR gerado pelo LLVM. Eu configurei um executor GitLab para executar testes para cada confirmação AVR-Rust (por meio de um espelho de repositório GitLab), mas não é muito útil porque GitLab não oferece suporte a compilações de CI em solicitações pull, já que o código real é hospedado em um repositório bifurcado.

Obrigado pela atualização @dylanmckay. Todos nós apreciamos o esforço que você fez nisso.

Nós agora atualizamos o fork ontop do Rust base rust-lang / rust @ fb7cca33f , o programa blink é compilado com sucesso.

Este problema parou?

Você tem alguma atualização sobre isso? O PR ainda está travado na questão do espaço de endereço?

Ei @dylanmckay , desculpe por incomodar com isso .. há alguma atualização sobre o problema?

Olá a todos, aqui estão alguns comentários meus

Correções de colheita seletiva

Quase todos os reparos necessários para fazer libcore funcionar foram transferidos para o mestre LLVM e atualmente existem no fork rust-lang / llvm. Ontem eu comecei um PR para atualizar o garfo AVR para 1.39.0 (avr-rust / rust # 155), eu só tive que escolher uma correção que ainda não estava lá - avr-rust / llvm @ 4350776601bc671e6e055bfbe32add34b70d2635.

libcore não pode ser compilado sem modificação

Não exigimos mais um fork do libcore personalizado para usar o AVR. Atualmente, há apenas uma modificação em libcore no garfo avr-rust - avr-rust / rust @ 44240ac59c5949b8a9fd191f5cd666d0206fbe85 - reescrever um lançamento de ponteiro para obter a geração de IR correta.

Dependemos do

Quaisquer operações em ponteiros de função diferentes de 'chamar' acessam a RAM, não a memória do programa (avr-rust # 68)

Isso foi corrigido.

Deslocamentos de 32 bits geram chamadas para uma rotina compilador-rt que não existe (avr-llvm / llvm # 163)

Este ainda é um problema doloroso. Eu suspeito que a melhor correção será escrever um código de redução personalizado no back-end LLVM AVR que reduz essas mudanças para montagem pura, removendo qualquer dependência ABI no compilador-rt ou libgcc. Não tenho certeza de quanto maior o tamanho do código gerado pode ser, pode não ser uma boa ideia.

Perguntas antes do upstream

RFCs e convenções de chamada instáveis

Eu postei este comentário no tópico

A convenção de chamada "avr-interrupt" foi adicionada. Isso permite extern "avr-interrupt" fn my_isr_handler () {..}. Isso provavelmente precisaria passar pelo processo de RFC para se estabilizar, mas posso estar errado.

As convenções de chamada instáveis ​​podem ser adicionadas sem passar pelo processo RFC?

Atualmente, temos "avr-interrupt" e "avr-non-blocking-interrupt" sob o portão de recursos #![feature(abi_avr_interrupt)] . Eles poderiam ser upstreamed como convenções de chamada instáveis, enquanto se aguarda um RFC de estabilização futuro?

Buildbots

O upstream de um back-end LLVM requer a configuração de um buildbot dedicado que executa testes para esse back-end e a sua manutenção. É este o caso com Rust? Como podemos garantir que o conjunto de testes seja executado no modo AVR em cada push? O que outros back-ends (como WASM) fazem?

Distribuição

"Mesclar o garfo avr-rust upstream" significa simplesmente mesclar os dois garfos em um, mas ainda exigindo uma compilação do código-fonte? Talvez seja possível distribuir um back-end, mas apenas todas as noites? O que os outros back-ends fizeram?

Fora isso, os patches específicos do avr-rust são muito finos, sem nenhum hack desagradável hoje em dia.

O patchset completo pode ser visto aqui https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support

Meu patchset de rebase WIP 1.39.0 (que é praticamente idêntico) pode ser encontrado aqui https://github.com/rust-lang/rust/compare/master...avr-rust : avr-support-1.39.0-4560ea788c . Isso deve ser mesclado com avr-rust / master nos próximos dias.

Não consigo pensar em nada específico que esteja bloqueando isso - talvez seja hora de enviar patches e ver como funciona?

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

Mencionei esse problema acima, mas não acho que ele bloqueie o upstreaming do back-end do AVR. Devemos ser capazes de conseguir uma versão funcional e útil do rustc com AVR sem ele. Tenho certeza de que existem soluções alternativas e hacks que podemos fazer. entretanto, a detecção de dispositivos em caixas AVR após o back-end ter sido hipoteticamente fundido e antes de uma API de consulta de CPU alvo oficial chegar ao Rust oficial.

Ele vive! Obrigado pela atualização @dylanmckay , progresso emocionante.

Ótimo trabalho @dylanmckay! Obrigado por manter-nos informados.

Um pouco fora do assunto, mas: o rustc for avr seria capaz de fazer FFI com bibliotecas C?
Existem muitas bibliotecas maduras já disponíveis para avr, mas escritas em C / C ++.
Seria ótimo poder criar alguns invólucros do tipo ferrugem para eles e reutilizá-los em nossos projetos rust avr.

Rust já pode fazer FFI com C em geral.

Sim e isso é ótimo! A questão é: isso se traduz em rust-avr?

Contanto que o C ABI do LLVM para AVR corresponda ao do gcc, ele deve funcionar

As convenções de chamada instáveis ​​podem ser adicionadas sem passar pelo processo RFC?

Meu voto é sim , já que a mudança para suportar as convenções de chamada do AVR é ​​basicamente dar a eles um nome e mapeá-los para o número LLVM. Não há necessidade de mudanças fundamentais no código, pois já temos suporte para convenções instáveis.

O upstream de um back-end LLVM requer a configuração de um buildbot dedicado que executa testes para esse back-end e a sua manutenção. É este o caso com Rust? Como podemos garantir que o conjunto de testes seja executado no modo AVR em cada push? O que outros back-ends (como WASM) fazem?

O sistema de camadas do Rust é um pouco vagamente definido, mas acho que a coisa certa é mesclar o código específico do AVR . Então o AVR será o nível 3 , o que significa que não é construído ou testado automaticamente, apenas pendurado no código. No mínimo, isso significa que esses arquivos serão mantidos atualizados com as alterações do compilador.

"Mesclar o garfo avr-rust upstream" significa simplesmente mesclar os dois garfos em um, mas ainda exigindo uma compilação do código-fonte?

Pelo que sei, seria enviar o único compromisso como RP. Nosso fork personalizado efetivamente morreria / se tornaria um lugar para rastrear detalhes específicos do AVR até que se tornasse um alvo mais amplamente utilizado.

talvez seja hora de enviar patches

Eu penso que sim.

@edvorg muito no tópico IMO

Um pouco fora do assunto, mas: o rustc for avr seria capaz de fazer FFI com bibliotecas C?
Existem muitas bibliotecas maduras já disponíveis para avr, mas escritas em C / C ++.

Sim .. principalmente. A convenção de chamada AVR implementada pelo backend AVR é ​​projetada para corresponder ao AVR-GCC (documentado aqui ). Existem algumas peculiaridades, mas o patch D68524 do LLVM que preciso revisar deve corrigi-las.

Callites do Rust sempre serão capazes de invocar corretamente as funções compiladas do Rust ou avr-clang (já que o avr-clang C usa a mesma implementação de convenção de chamada extern "C" que o front-end do Rust) e a interoperação com AVR-GCC _deve_ funcionar, especialmente para assinaturas de funções simples, mas às vezes pode engasgar (consulte a descrição do D68524 para obter mais detalhes).

Alguma atualização disso ?
Apenas curioso.

Solicitação enviada para tornar o backend LLVM AVR um backend oficial - https://reviews.llvm.org/D75099

@dylanmckay Se aceito, quais são as peças restantes para encerrar este problema?

@dylanmckay Se aceito, quais são as peças restantes para encerrar este problema?

Tecnicamente, o Rust trabalhará com back-ends oficiais e experimentais. Levantei # 69478 para upstreaming da maior parte do back-end.

Não tenho certeza se a fusão do AVR como um alvo Tier 3 pressupõe que o AVR se torne um back-end oficial do LLVM - bem-vindos.

Pensando nisso, a distinção oficial versus experimental do LLVM pode ser mapeada no sistema de camadas do Rust, do qual Rust tem três camadas e o LLVM tem duas. Um back-end oficial do LLVM corresponde a uma mistura de Tiers 1 e 2 - basicamente, incluídos em suítes de teste e lançamentos oficiais. Um back-end experimental LLVM, até onde eu posso dizer, é semanticamente igual a um backend Rust Tier 3; incluído na árvore de origem, não incluído nas versões por padrão, nenhuma inclusão nos testes de CI padrão, etc.

Então, suponho que as únicas peças restantes para encerrar esse problema serão aquelas que surgirem na revisão do código de # 69478.

tl; dr o back-end do AVR se tornaria um alvo de upstream de Nível 3 em rust-lang / rust # 69478 se mesclado, eliminando assim o fork.

A única diferença entre o fork do avr-rust / rust e # 69478 é o sinalizador target_cpu cfg que existe no fork do AVR, mas não no upstream. Eu deixei isso de fora do PR inicial.

quais são as peças restantes

Tenho certeza de que ainda há uma série de erros de compilação de vários tipos de código, então ainda precisa de mais pessoas para tentar coisas e minimizar bugs e corrigi-los.

Ser upsteamed irá baixar a barra para que as pessoas experimentem coisas, já que elas podem apenas obter um Rust normal todas as noites em vez de compilar o fork geralmente desatualizado.

Depois de ser upstreamed como um alvo de nível 3, o desenvolvimento do AVR funcionará com o recurso -Z build-std do cargo ou exigirá o xargo? O LLD que vem com o Rust tem suporte para AVR ou os linkers GNU serão necessários?

o desenvolvimento do AVR funcionará com o recurso -Z build-std do cargo ou exigirá o xargo? O LLD que vem com o Rust tem suporte para AVR ou os linkers GNU serão necessários?

Não posso dizer que não funcionarão, mas tudo o que fiz usou vinculadores Xargo e GNU.

Os linkers GNU são difíceis de configurar no Windows e o xargo requer mais uma ferramenta para instalar, é por isso que estou perguntando.

O LLD que vem com o Rust tem suporte para AVR ou os linkers GNU serão necessários?

LLD só tem suporte muito básico para vincular AVR, ele não pode vincular nenhum programa real ainda. Portanto, avr-ld será necessário.

é por isso que estou perguntando.

Não se engane, também acho que esse é o objetivo final correto, mas pode não ser o estado atual do mundo. Honestamente, eu ficaria feliz em tornar a sobrecarga cada vez mais baixa. A fusão é apenas o primeiro passo para isso.

O backend AVR agora foi habilitado como um destino LLVM oficial: tada: O mestre LLVM contém suporte AVR por padrão agora. O primeiro lançamento do LLVM a incluir AVR por padrão será o LLVM 11 em cerca de 6 meses.

Agradável! Obrigado por todo o esforço que você está colocando nisso.

Muito legal!

Parabéns @dylanmckay por essa conquista incrível. A comunidade agradece por seu trabalho nisso.

Eu tenho acompanhado este problema por um tempo agora e embora eu saiba que a maior parte do assunto está fora do assunto, estou interessado no que isso significa para o usuário médio-não-da-origem ... É um processo complicado obter um Arduino Uno instalado e funcionando com Rust nativo usando isso? Estou mais interessado nisso, pois Rust tem proteções suficientes e provavelmente não posso causar tantos momentos ops xP

@ Jimmio92 Pelo que posso dizer, sim. Como em "sim, é complicado". Ou pelo menos longa e tediosa, mesmo que não seja particularmente complicada, já que você ainda tem que construir este fork personalizado do compilador Rust a partir do código-fonte, o que também envolve construir o LLVM a partir do código-fonte. Isso geralmente leva algumas horas, se tudo correr bem.

_{Minha experiência pessoal com LLVM é, no entanto, que na maioria das vezes, ele simplesmente não gosta de algo no seu sistema (pelo menos certamente no macOS - é mais fácil no Linux e certamente nem sonho em fazer isso no Windows), então, inevitavelmente, você acaba massageando os caminhos de instalação e as bibliotecas personalizadas até ter sucesso ou desistir.}

O que as (excelentes) notícias acima significam é apenas isto: os desenvolvedores do LLVM agora estão direcionando / apoiando o AVR oficialmente (?), E o próximo lançamento do LLVM incluirá suporte a AVR. Não há nada a dizer que o Rust agora também oferece suporte ou oferecerá suporte a AVR no curto prazo. Se você olhar os problemas e os comentários acima, verá que vai dar muito trabalho até que o suporte a AVR "simplesmente funcione" com um conjunto de ferramentas Rust padrão.

Existe um processo / exemplo que eu poderia olhar para a escolha de correções de AVR do mestre LLVM para o fork do Rust LLVM?

Além disso, o Rust ainda rastreia o mestre LLVM? Pelo que parece, ele rastreia o lançamento atual mais algumas correções escolhidas a dedo. Os PRs para atualizar a versão do LLVM para master ainda são aceitos?

@dylanmckay

Além disso, o Rust ainda rastreia o mestre LLVM?

Como você notou, agora ele rastreia os lançamentos.

Os PRs para atualizar a versão do LLVM para master ainda são aceitos?

Acho que não, mas cc @nikic

@dylanmckay, há um monte de correções no fork do LLVM do Rust em comparação com a versão 10.0: https://github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05

Existe um processo / exemplo que eu poderia olhar para a escolha de correções de AVR do mestre LLVM para o fork do Rust LLVM?

Existem instruções disponíveis aqui: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

Além disso, o Rust ainda rastreia o mestre LLVM? Pelo que parece, ele rastreia o lançamento atual mais algumas correções escolhidas a dedo. Os PRs para atualizar a versão do LLVM para master ainda são aceitos?

Rust atualmente rastreia lançamentos de LLVM, porque isso permite que as pessoas executem LTO entre linguagens facilmente com uma versão clang correspondente. Portanto, a resposta padrão aqui é provavelmente "não".

Dito isso, tem havido alguma discussão sobre a atualização para o mestre LLVM para mitigar as regressões de tempo de compilação do LLVM 10. Atualmente estou trabalhando nisso para fins de avaliação. Eu acho que é mais seguro presumir que isso não vai acontecer, e enviar algumas escolhas certas contra nosso fork do LLVM 10 (há muitos deles?)

A bifurcação foi mesclada! Vou escrever uma atualização adequada esta tarde

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

Vou escrever uma atualização adequada esta tarde

Estou interessado na referida atualização. Onde você planeja postar @dylanmckay (então eu sei onde procurar: ligeiramente_smiling_face :)?

Estou esperando ansiosamente por essa adição ao ecossistema Rust há literalmente anos! Minhas tentativas ingênuas de usar isso no master parecem falhas, entretanto.

Eu construí o master rust com o ./x.py build padrão, vinculado ao conjunto de ferramentas master , e tentei construir o exemplo avr-rust / blink (após atualizar 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

Isso falha com:

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

Estou assumindo que ainda há uma configuração necessária, que estou faltando.

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

Eu não esperava que muito de nada funcionasse agora, pois a libcore é parte do que está mal compilado.

O AVR rustc fork foi integrado antes.

A bifurcação upstream ainda não pode ser usada em geral. Existem algumas coisas que precisam acontecer primeiro.

Correções de upstream do AVR LLVM que o Rust ainda não precisa ser selecionadas

Para responder à pergunta de @nikic , há no máximo 20 commits de LLVM que precisam ser selecionados.

Tenho usado um script para selecionar automaticamente _todos_ os commits do AVR do upstream do LLVM em um fork local.
Este é um grande martelo e haverá correções escolhidas a dedo que são desnecessárias - há correções LLVM upstream que precisam ser puxadas para Rust upstream antes que o back-end se torne utilizável. eles precisarão ser filtrados e selecionados a montante de Rust.

Compilar o programa de piscar do LED AVR do ramal mestre Rust upstream

Como o esforço upstream vem acontecendo há alguns meses, a bifurcação avr-rust downstream
ainda está em uma versão particularmente antiga do Rust. Desde então, houve pelo menos uma mudança no Rust upstream que requer generalização para suportar AVR sem atingir erros de asserção do LLVM. Abri a solicitação pull # 73270 para corrigi-lo.

Não tenho certeza se houve outras mudanças no Rust upstream que precisam de mudanças para AVR - provavelmente não.

Depois de fazer o programa blink funcionar, postarei outra atualização porque, nesse ponto, o suporte AVR upstream deve estar pronto para uso / experimentação.

Onde a comunicação AVR deve ocorrer / ser postada

@wezm, você levantou um bom ponto - não existe necessariamente um canal de comunicação "abençoado" para atualizações. Este ingresso tem servido bem, mas será inevitavelmente fechado em breve.

O canal AVR-Rust Gitter é a escolha mais natural existente. Gosto da ideia de uma lista de e-mail (mas não gosto da ideia de hospedar um servidor de e-mail, se possível). O canal Gitter tem discussões, então talvez algo como uma lista de discussão seja útil.
Talvez a criação de um blog seja bom para centralizar anúncios / atualizações. Eu gostaria de ter um "meio oficial" para que as pessoas que desejam atualizações casuais não percam. Suponho que um blog requer verificação constante de novas postagens, enquanto uma lista de e-mails notifica inerentemente
todo mundo que está interessado. Sugestões bem-vindas.

Perguntas abertas

• Os problemas do GitHub no fork do avr-rust devem ser movidos para o repositório Rust upstream?
  ** Independentemente disso, novos problemas devem ser levantados no repositório upstream - o rastreador de problemas antigo precisará ser encerrado.
  
  
  
  • Onde devem as instruções para compilar o Rust com AVR?
  
  

As coisas mais importantes para o futuro (leia-se: prioridades)

• Empacotamento e distribuição de binários do AVR Rust. Compilar Rust pode ser uma grande dor de cabeça para o usuário casual,
  muitas distros parecem ter problemas de vez em quando em certos fluxos de trabalho. Vários erros OOM relatados incorretamente como
  bugs do compilador. A barreira de entrada é desnecessariamente alta e precisa ser menor - basta fazer o download e pronto.
  Rastreado por https://github.com/avr-rust/rust/issues/162
• Construir uma lista de configurações "suportadas", ou pelo menos testadas. Precisamos de uma mesa de (rustc version, Xargo version) então
  que mudanças para APIs Rust privadas das quais o Xargo depende não quebram o conjunto de ferramentas AVR Rust na atualização.
  O Xargo está em modo de manutenção - cargo-xbuild parece bastante limitado (tentei há algumas semanas, não consigo lembrar o motivo),
  podemos precisar de um fork do Xargo. Talvez seja melhor adicionar as ferramentas diretamente no Cargo (há um problema de rastreamento para isso).
• Configurando algum tipo de homepage para o projeto, incluindo links para download
• Teste de integração (em um AVR emulado / simulado, a cada confirmação)

Por enquanto, vou repostar as atualizações neste problema do GitHub, até que uma mídia melhor seja encontrada. Vou postá-los no Gitter também.

Talvez a criação de um blog seja bom para centralizar anúncios / atualizações. Eu gostaria de ter um "meio oficial" para que as pessoas que desejam atualizações casuais não percam. Suponho que um blog requer verificação constante de novas postagens, enquanto uma lista de e-mails notifica inerentemente
todo mundo que está interessado. Sugestões bem-vindas.

Minha preferência pessoal é fortemente a favor de um blog (com feed RSS). Acho que os blogs geralmente aparecem melhor nos resultados de pesquisas e são mais agradáveis ​​para vincular do que tópicos de listas de discussão. O feed RSS resolve o aspecto de verificação / notificação.

Não tenho 100% de certeza se é o melhor lugar para isso, mas existe o blog do Embedded WG. Pode ser um canal de comunicação de baixo esforço.

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

Talvez também uma conta no Twitter? Ele pode ser usado para compartilhar novas postagens de blog (para se manter atualizado).

Acho que o grupo de trabalho incorporado ficaria feliz em ajudar aqui. Temos uma conta no Twitter @rustembedded e certamente podemos incluir notícias relacionadas ao AVR no boletim informativo.

Eu também criei o rótulo O-AVR algum tempo, então fique à vontade para usar o rastreador de problemas do Rust para problemas específicos do AVR (mas esteja ciente de que 1,5 mil pessoas assistem ao repo). Além disso, você pode querer coordenar no Rust-lang Zulip, já que é onde reside a maioria das equipes Rust. Também estamos no processo de aumentar os "grupos-alvo" que se concentram em alvos Rust específicos (por exemplo, Windows ou Arm), o AVR pode ser uma boa opção para isso também. Sinta-se à vontade para entrar em contato com a Zulip para isso.

Atualizar.

Existem duas coisas restantes antes de libcore poder ser compilado para AVR em um branch stock rust-lang / master:

1. Há um pull request que corrige uma série de bugs de "elenco de espaço de endereço inválido" no AVR, relacionando como os ponteiros de função para arquiteturas de Harvard devem ser marcados como addrspace(1) comparação com os alvos de Von-Neumann que estão bem com o padrão atual de Rust de addrspace(0) . rust-lang / rust # 73270 - está atualmente em revisão de código.

~ 2. Há um outro bug bloqueando o funcionamento do exemplo blink - avr-rust / rust # 92. Há um patch que ainda não foi atualizado e que corrigirá isso - https://reviews.llvm.org/D68524. Isso será feito o upstream e então selecionado no fork do LLVM de Rust muito em breve, uma vez que passe nos testes de unidade e integração. ~ Foi fundido no LLVM upstream

Assim que essas duas coisas forem feitas, o alvo Rust AVR upstream será capaz de compilar o código AVR no mesmo nível que o atual avr-rust / rust fork, e podemos então começar o processo de atualização do exemplo blink , arduino engradado, documentação, guias, para o branch upstream. Então, o branch upstream deve estar pronto para uso experimental.

Mais um TODO:

1. ~ Adicionar encanamento AVR para a nova sintaxe de montagem embutida no Rust upstream ~
   
   
   
   • ~ Uma vez que a nova sintaxe de montagem inline é suportada, a caixa do Arduino deve ser atualizada para usá-la
     
     uma vez que a caixa do Arduino tenha sido atualizada, atualize a caixa do blink para a nova versão. ~ Podemos usar a macro antiga via llvm_asm! por enquanto, pois ela ainda existe durante a noite.
   
   
2. Patches de correção de AVR selecionados (principalmente de Ayke) do LLVM master para upstream Rust LLVM fork (EDITAR: PR: https://github.com/rust-lang/llvm-project/pull/66)

Aqui está o branch com tudo: https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. Este branch é suficiente para compilar libcore.

Ele é construído a partir de rust-lang/master upstream, mas também inclui o patch D68524 do LLVM ainda não upstream, Rust PR rust-lang / rust # 73270 não mesclado e 46 commits relacionados a AVR do LLVM upstream selecionados automaticamente por meio de script (ramificação LLVM: https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate). Observe que nem todos os 46 são necessários, a lista final será menor.

Atualização : aberta uma solicitação de pull que inclui todas as correções de LLVM upstream.

Aqui está uma lista exaustiva do trabalho restante antes que o programa de piscar de LED possa ser compilado e executado com êxito.

Trabalho restante

• [x] Land Rust PR rust-lang / rust # 73270 . Esta solicitação de pull corrige uma série de bugs de "elenco de espaço de endereço inválido" no AVR, relacionando como os ponteiros de função para arquiteturas de Harvard devem ser marcados como addrspace (1) em comparação com os alvos Von-Neumann que estão bem com o padrão atual de Rust de addrspace (0) . Ele está atualmente em revisão de código.
• [x] Land Rust LLVM PR https://github.com/rust-lang/llvm-project/pull/66 . Isso traz todas as correções de AVR necessárias do LLVM upstream para o fork do LLVM de Rust. No final, houve ~ 17 ~ 16 correções de LLVM que precisaram ser escolhidas a dedo.
• [x] Land Rust PR rust-lang / rust # 73658 que atualiza a versão do submódulo LLVM . A documentação do compilador Rust tem instruções para fazer isso. Ele está atualmente em revisão de código .
• [x] Land Rust PR ~ rust-lang / rust # 74625 ~ rust-lang / rust # 74631 . Em 79a42e37084d0, Rust começou a passar incondicionalmente o argumento --eh-frame-hdr para o vinculador. O vinculador AVR-GCC não oferece suporte a esse sinalizador e, portanto, um caso especial para evitar a passagem é adicionado para AVR, semelhante às exclusões existentes para Windows. Solaris e UEFI.

Talvez seja melhor adicionar as ferramentas diretamente no Cargo (há um problema de rastreamento para isso).

Estou assumindo que este é o problema correto: rust-lang / cargo # 4959.

cargo build -Z build-std=core funcionou bem para meus casos de exemplo de AVR.

@shepmaster que parece estar me aproximando de qualquer maneira, obrigado! Parece que estou preso no bitcast agora, então vou esperar que ele seja mesclado (já que parece que está faltando um arquivo necessário para construir o PR, e IDK o que estou fazendo).

No processo de usar -Z build-std=core eu precisava fornecer um triplo de destino, então executei rustc +master --print target-list | grep avr e encontrei avr-unknown-unknown . Mas o problema arquivado avr-llvm / llvm # 35 parece fazer parecer que o triplo deveria de fato ser avr-atmel-none (o que faz mais sentido para mim de qualquer maneira). Algo precisa ser atualizado aqui ou estou faltando alguma coisa?

avr-unknown-unknown está correto.

Perguntas abertas

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

Não acho que isso importe muito do lado do usuário. Isso foi fácil de encontrar por meio de ddg e / ou esta semana em ferrugem.
O que quer que torne isso mais fácil para os desenvolvedores.

Perguntas abertas

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

Não acho que isso importe muito do lado do usuário. Isso foi fácil de encontrar por meio de ddg e / ou esta semana em ferrugem.
O que quer que torne isso mais fácil para os desenvolvedores.

Acho que as instruções para compilar Rust com AVR devem estar de alguma forma em https://docs.rust-embedded.org/

Tudo bem, hora de atualização.

Todos os patches necessários para AVR existem no compilador noturno Rust atual a partir da rustc 1.47.0-nightly (0820e54a8 2020-07-23) . O compilador noturno Rust, sem modificação, agora pode compilar o exemplo de piscar de LED com sucesso e gerar um arquivo AVR ELF.

• Nova página de destino do projeto centralizado criada em https://avr-rust.com/
• Um novo livro - o Guia do AVR-Rust foi criado, hospedado nas páginas do GitHub em book.avr-rust.com.
• O repositório de fork do avr-rust / rust tornou-se obsoleto. O repositório ainda não foi arquivado, pois há problemas existentes que devem ser migrados antes de serem bloqueados e fechados permanentemente.
• O Xargo não é mais necessário - o sinalizador -Z build-std no Rust upstream substitui a necessidade dele no AVR. Um garfo de carga não é mais necessário - carga a montante bastará.

O compilador noturno Rust agora pode ser considerado o canal recomendado para Rust com suporte a AVR.

Estou encerrando este problema agora - nós resolvemos!

As etapas para relatar bugs podem ser encontradas no Guia do

O AVR Guidebook e o exemplo blink em https://github.com/avr-rust/blink são os melhores recursos para começar a usar o alvo.

Um profundo, profundo agradecimento a todos que discutiram e apoiaram o projeto através deste esforço de upstreaming - é muito apreciado.

FIN

Uau uau uau.

Obrigado a todos que contribuíram para isso - estou ansioso por este dia desde sempre!

Dylan McKay antes de transportar a ferrugem para avr

E depois

Obrigado por todo o trabalho duro cara! :-) Descanse bem!