O ASM662 é um montador/desmontador (assembler/disassembler) para Oki 66201/66207/66301 que ainda está em desenvolvimento. É lançado sob a licença BSD, pelo que pode usar o código para o que desejar. A melhor forma de obter o código mais recente é através do CVS, mas são lançados periodicamente executáveis para Windows: http://web.archive.org/web/20260228000421/https://sourceforge.net/projects/pgmfi/ Também funciona aparentemente nos chips NEC 66911 usados nas ECUs P13/P14/P0D.

Novidades#

8 de outubro de 2003#

A versão 1.2 do asm662 para Win32 foi lançada. Este código encontra-se na mesma fase experimental mencionada abaixo -- os argumentos adicionais da linha de comandos são endereços a não considerar como tabelas. ---

Notas#

Estou a trabalhar no sentido de obter uma desmontagem (disassembly) perfeitamente relocável de várias ROMs, começando pela P30, e para esse fim o código do desmontador no CVS está numa fase experimental. Pode fornecer argumentos adicionais na linha de comandos que são endereços que o programa não deve considerar como ponteiros para tabelas de ROM, ex.: dasm662 p30.bin p30.asm 5e20 5e59 7133 72fa ---

Um problema com a desmontagem/análise de código na arquitetura Oki 66k é que o mesmo opcode pode ter significados diferentes em tempo de execução (runtime), dependendo de um flag de estado chamado DD. O desmontador rastreia este flag de uma forma ingénua que funciona na maioria das vezes. Não lida corretamente com duas estruturas de código: saltos indiretos (indirect jumps) e chamadas de subrotinas. Saltos indiretos não ocorrem em lado nenhum nas ROMs P28, P30, P72, mas ocorrem na P13 (pelo menos). Como tenho trabalhado maioritariamente com a P30, estou a ignorar o problema por agora. As chamadas de subrotinas ''que alteram o DD antes de retornar'' ocorrem, no entanto, em todas as ROMs, e isso causa imprecisões na desmontagem (mas gera sempre código que será remontado na mesma sequência de bytes, por isso é seguro de usar mesmo que não seja 100% correto). É capaz de detetar violações do flag DD em alguns casos porque certos opcodes/instruções requerem que o DD tenha um determinado valor, emitindo assim um aviso caso não tenha, alterando-o para que seja consistente e, em seguida, gerando a mnemónica de instrução corrigida. Para lidar adequadamente com chamadas de subrotinas, seria necessário adiar a desmontagem após uma instrução de chamada (call) até determinar qual o impacto da subrotina no DD (e no LRB e USP, mas não vou entrar por aí agora) antes da instrução RT. Ainda não tive oportunidade de o tornar tão inteligente. Se eu for tão longe na análise de código, começará a invadir o reino da descompilação em vez da desmontagem, e muitas outras coisas tornam-se possíveis.