Completando as informações do meu post sobre um código estranho gerado pelo compilador IAR para o microcontrolador MS430, seguem o resultado de alguns testes adicionais e a comprovação que era realmente um bug do compilador.
Ainda utilizando a versão 4.11B do compilador, experimentei mudar o nível de otimização (o default é Low). Praticamente não fez diferença, exceto pela troca de CLRC + RRC.B por RRA.W nos níveis mais altos de otimização. Aliás, se tem uma sequência melhor para fazer uma operação não vejo porque não usá-la sempre; este mudança não parece estar ligada às opções ligadas no nível seguinte (commom subexpression optimization e code motion).
Parti então para a instalação da versão mais recente (4.20.1). Um ponto positivo é que cada versão instala por padrão em um diretório diferente e elas parecem conviver sem problemas. Esta versão gerou o mesmo código que a versão antiga (3.42A).
Passando um pente fino nos Release Notes da 4.20.1, encontrei na lista de correções:
EW20239: Incorrect code could sometimes be generated when accessing parts of volatile objects. Instead of accessing all bits in the object part, the code would only access a single bit. Typically, this would occur when using volatile in combination with bitfields.
O registrador P1OUT é realmente volatile e o código estava acessando um bit ao invés de todos, apesar de eu não estar usando bitfields mas sim constantes explícitas. Portanto acho que o meu problema se encaixa nesta correção.
Fica a preocupação de um bug destes, que envolve uma operação que considero comum, ter passado pelos testes e ter ido a campo.
2 comentários:
Realmente, é um fato preocupante. Utilizamos o compilador para nos poupar do trabalho de aprender várias arquiteturas diferentes e economizar nos códigos, apesar da maioria das pessoas de hoje não entender muito bem o processo interno de um compilador. De fato, para muitos, é perda de tempo. Sendo assim, continuamos a acreditar na tarefa mágica deste software, mais do que deveríamos, mas por um lado, se não fosse assim, qual seria o objetivo de um compilador se não a linha de produção em massa, portabilidade e facilidade de implementação, segurança de código, etc...? Um erro destes pode fazer o "Spoke-o-dometer" não funcionar hoje, mas pode tirar vidas amanhã, dependendo da área de aplicação na qual o software irá rodar. O erro é de quem?
Exagerei um pouco mas é isso mesmo... hehe
Obrigado por compartilhar a experiência...
Grande abraço
Breno.
No passado tive algumas experiências traumáticas com o compilador SDCC com o 89C2051 e uns tempos depois também tive problemas curiosamente com o MSP430 também!
Sem contar detalhes que não são necessariamente "erros do compilador" mas que é algo que ele poderia ser um pouco mais esperto como:
- desperdício de memória por causa da ordem de variáveis com tipos diferentes
- geração de código desnecessário em determinadas contruções, que parece ser o caso que você apresentou acima.
Porém já vi casos que notoriamente parecia haver uma sacanagem embutida, onde na versão "trial" para o compilador:
a) i+=1
b) i++;
eram tratados de forma diferente e na versão final ambos viravam "inc" e "common subexpression elimination" mesmo sem as chaves de otimização ligadas eram aplicado.
[]s
Postar um comentário