Brinquedo do dia: fiz uma ferramenta de code coverage para Assembly Z80!
Mês passado eu tinha feito um parser de json em Assembly Z80, e fiz um monte de unit tests para garantir que estava direitinho. Mas aí eu pensei que só unit test não é suficiente, eu precisava também de code coverage para garantir que não esqueci de testar nenhum code path.
Escrever a ferramenta foi fácil, um plug-in em TCL pro openmsx e um script python para gerar o html. O que eu não esperava é que eu fosse realmente achar um bug com ele!
A história é que eu otimizei esse parser por espaço, e usei um monte de truques bem sujos para isso. Um deles é esse aí da foto, que eu chamo de "saltar no meio". Funciona assim: a rotina get_json_action tem dois entry points, um que chama com o registro A zerado (get_token_type), e outra que chama com o A não-zero (get_token_value).
O natural seria a primeira ter um XOR A para zerar o registrador, e a segundo um LD A,1 ou algo do tipo para setar com não-zero. Mas eu fiz diferente: usei os opcodes 3E AF em seguida. Se você executar a partir do 3E, o Z80 entende como LD A, 0xAF, que é não-zero. Se você rodar a partir do AF, ele entende como XOR A, que é zero. Eu saltei no meio do opcode e salvei alguns bytes assim.
O problema é que o wiring estava errado! Na hora de inicializar os ponteiros, eu fiz get_token_value = get_token_type + 1, quando deveria ser get_token_type - 1. E os unit tests não pegaram, porque, por coincidência, no turboR o registro A sempre estava não-zero naquele ponto. Ia passar batido, se a ferramenta de coverage não tivesse me avisado que aquele 3E nunca estava sendo executado!
Para quem ficou curioso, aqui o report mostrando o erro:
http://www.ilafox.com.br/ricbit/coverage_error.html
E os scripts de coverage estão no repositório do msxjson:
https://github.com/ricbit/msxjson
Mês passado eu tinha feito um parser de json em Assembly Z80, e fiz um monte de unit tests para garantir que estava direitinho. Mas aí eu pensei que só unit test não é suficiente, eu precisava também de code coverage para garantir que não esqueci de testar nenhum code path.
Escrever a ferramenta foi fácil, um plug-in em TCL pro openmsx e um script python para gerar o html. O que eu não esperava é que eu fosse realmente achar um bug com ele!
A história é que eu otimizei esse parser por espaço, e usei um monte de truques bem sujos para isso. Um deles é esse aí da foto, que eu chamo de "saltar no meio". Funciona assim: a rotina get_json_action tem dois entry points, um que chama com o registro A zerado (get_token_type), e outra que chama com o A não-zero (get_token_value).
O natural seria a primeira ter um XOR A para zerar o registrador, e a segundo um LD A,1 ou algo do tipo para setar com não-zero. Mas eu fiz diferente: usei os opcodes 3E AF em seguida. Se você executar a partir do 3E, o Z80 entende como LD A, 0xAF, que é não-zero. Se você rodar a partir do AF, ele entende como XOR A, que é zero. Eu saltei no meio do opcode e salvei alguns bytes assim.
O problema é que o wiring estava errado! Na hora de inicializar os ponteiros, eu fiz get_token_value = get_token_type + 1, quando deveria ser get_token_type - 1. E os unit tests não pegaram, porque, por coincidência, no turboR o registro A sempre estava não-zero naquele ponto. Ia passar batido, se a ferramenta de coverage não tivesse me avisado que aquele 3E nunca estava sendo executado!
Para quem ficou curioso, aqui o report mostrando o erro:
http://www.ilafox.com.br/ricbit/coverage_error.html
E os scripts de coverage estão no repositório do msxjson:
https://github.com/ricbit/msxjson
Nenhum comentário:
Postar um comentário