[Desafio do Mês] Assembly para a arquitetura RX

- por Sergio Prado

Categorias: Desafios Tags: , ,

Estava fazendo uma limpeza no meu armário de bugigangas e encontrei diversos kits de desenvolvimento sem uso, muitos deles duplicados. Aparentemente as placas estão se reproduzindo lá dentro! :)

Por mais acumulador de placas que eu seja, não faz nenhum sentido deixá-las empoeirando no armário. É hora de dar um melhor uso para elas. E elas irão para vocês, leitores. Apresento-lhes uma nova initiativa do blog, o “Desafio do Mês”.

DESAFIO DO MÊS

A idéia é lançar aqui no blog um desafio por mês. Aqueles que resolverem o desafio irão concorrer a um prêmio, que pode ser um kit de desenvolvimento, um livro ou algum outro item como vagas para os meus treinamentos.

Se apenas uma pessoa resolver o desafio, o prêmio vai para ela. Se mais de uma pessoa resolver o desafio, o prêmio será sorteado entre elas.

E vou além. Vou criar e manter um ranking de pontuação de todos que participarem dos desafios.

Cada desafio resolvido por completo valerá 10 pontos. Um desafio resolvido de forma incompleta valerá 5 pontos (isso pode ser interpretativo, mas prometo deixar as regras claras em cada desafio e ser um ditador benevolente quando necessário).

Se você participar e resolver o desafio proposto, mesmo não ganhando o prêmio no sorteio, irá pontuar. No final do ano, aqueles que tiverem a maior pontuação irão concorrer a um prêmio especial! Além de ficar famoso(a), muito famoso(a)…

Qual o meu objetivo com tudo isso? Me livrar das placas?

Claro que não. Muitos de nós temos um dia-a-dia muito corrido, e na maioria das vezes não temos a oportunidade (e a motivação) de nos atualizar e estudar algo novo e diferente. Esta é a proposta dos desafios. Nos motivar a aprender algo novo e diferente. O prêmio é apenas uma (boa) consequência. Lembre-se da famosa frase atribuída a Ralph Waldo Emerson: “Life is a journey, not a destination.” :)

Prometo desafios interessantes, com temas relacionados a sistemas operacionais, linguagens de programação, segurança, ferramentas de desenvolvimento, protocolos de comunicação, arquitetura de hardware, etc. Espero que todos nós possamos aprender bastante com o processo, e nos divertir, claro!

Mas chega de enrolação. Vamos ao primeiro desafio do ano.

ASSEMBLY PARA A ARQUITETURA RX

Começaremos com a linguagem Assembly para a família de microcontroladores RX da Renesas.

O desafio é escrever uma rotina em Assembly para ordenar de forma crescente um vetor de número inteiros positivos de 32 bits. Para a implementação, assuma que o registrador R5 contém o endereço de memória inicial dos elementos a serem ordenados e o registrador R6 possui a quantidade de elementos a serem ordenados.

O código precisa ser compatível com o conjunto de instruções RXv1 e compilável com o compilador CC-RX da Renesas.

Atualização 1: Usuários Linux podem baixar a versão sem IDE do compilador e instalar com o Wine. Testei em uma máquina com o Ubuntu 14.04 64 bits e funcionou perfeitamente.

Cada instrução Assembly deverá estar comentada e documentada. E não vale comentários do tipo “movendo conteúdo do registrador X para o registrador Y”. Isso já estará implícito nos mnemônicos do código Assembly. Espero comentários do tipo “salvando o elemento X do vetor no registrador Y” ou “comparando o elemento X com o elemento X-1”.

Para te ajudar, estude a seção “2.CPU” do manual de usuário do RX62N e a seção “5. Assembly Language Specifications” do manual do compilador CC-RX.

Aqueles que resolverem o desafio com a menor quantidade de instruções de máquina ganharão 10 pontos e concorrerão ao prêmio. Aqueles que resolverem o desafio, mas utilizarem mais instruções de máquina, ganharão 5 pontos, mas não concorerão ao prêmio. E nada de enrolação, hein pessoal! Como já disse uma vez Linus Torvalds, “Talk is cheap. Show me the code.”

Atualização 2: Ao dizer que o código com a menor quantidade de instruções de máquina irá ganhar o desafio, significa que o código será compilado, e aquele que gerar o menor arquivo-objeto ganhará os 10 pontos.

Envie sua solução do desafio para o e-mail contato@sergioprado.org. Aceitarei submissões até o dia 22/01, e o resultado será divulgado no dia 27/01.

O prêmio para o desafio? Alêm do aprendizado e da diversão, esta belezura aqui:

Esta placa é baseada no microcontrolador RX62N, um microcontrolador de 32 bits da Renesas que opera à 100MHz e tem 512KB de flash e 96KB de RAM. Possui diversos periféricos e interfaces de comunicação, incluindo Ethernet, CAN, USB (host, device e OTG), botões, leds, acelerômetro de 3 eixos, sensor de temperatura, micro SD, porta serial, flash externa de 128Mb, saída de áudio, speaker, microfone, trimpot, display LCD, além de diversos conectores de expansão!

Aqui está uma visão legal dos periféricos da placa.

Qualquer problema ou dúvida é só escrever nos comentários desta publicação.

Bom, agora é estudar os manuais e escovar alguns bits…

Bons estudos e boa sorte!

Sergio Prado

  • Marcos Souza

    Olá Sergio, tentei encontrar instalador para Linux do compilador e do e² studio, mas eles não existem. Até consegui instalar o e² com o wine, mas o cc-rx não é possível.

    Precisamos mesmo de uma maquina Windows para podermos rodar os exemplos?

    Obrigado!

    • Marcos Souza

      Parece que só preciso do asrx.exe mesmo (IDE parece ser desnecessário..), vou começar a brincar com ele agora!

  • George Tavares

    Sergio, vai ter alguma lista de test cases para a rotina que possamos no basear?

    • Olá George! Não preparei nenhum test case para o exercício. Não pretendo executar ou emular o código. Irei fazer apenas uma inspeção visual e compilar para verificar a quantidade de instruções de máquina geradas. Um abraço!

      • George Tavares

        Entao a metrica nao eh numero de instrucoes assembly, e sim tamanho do codigo objeto. Assim, uma instrucao assembly que ocupa 3 bytes conta como 3.

        • Exato George! Vou tentar deixar isso mais claro na publicação. Um abraço!

  • Daniel Rosa Franzini

    Duas sugestões: 1.) Suportar também o toolchain GNU com o AS da KPIT (se for possível) e 2.) Premiar também o código que for mais rápido para algum conjunto de test-vectors que seja adequado para isso. Apenas o menor código objeto pode não ser sempre a melhor opção.

    • Obrigado pelas sugestões Daniel! Seria injusto com os outros participantes mudar as regras agora, há poucos dias do final da promoção, mas suas dicas estão anotadas para a próxima promoção. Um abraço!

    • George Tavares

      Ola Daniel.
      Em geral, codigos de melhor performance, otimizando lacos e mantendo o pipeline do processador sempre cheio envolve tecnicas como loop unrolling, o que acaba gerando mais instrucoes de maquina, independente do algoritmo escolhido.
      Isso com certeza eh importante em rotinas core do sistema que esta sendo construido. Entretanto tambem devemos lembrar que dispositivos embarcados possuem restricoes a quantidade de memoria disponivel, e tamanho de codigo objeto final. Assim rotinas que nao sao acessadas com frequencia, eu realmente escolheria versoes nao otimizadas ocupando menos espaco na esperanca de poder usar componentes com menos memoria para guardar o codigo objeto. Esta eu acredito ser a validade do exercicio proposto pelo Sergio.

Navegue
Creative Commons Este trabalho de Sergio Prado é licenciado pelo
Creative Commons BY-NC-SA 3.0.