.png)
A veces uno se pregunta cómo pudo terminar cazando un bug que parece imposible. Eso me pasó al contribuir con un prototipo para MiniScript 2.0, un entorno con lenguaje ensamblador, ensamblador y una VM para ejecutar bytecode. Ya había agregado un ejemplo de factorial y soporte en el ensamblador y la VM para las operaciones MULT y DIV. Redspark, desde la comunidad, amplió la VM con más opcodes de comparación, y al añadir hoy el soporte de esos mismos opcodes en el ensamblador, apareció el fallo inesperado.
Preparé un pequeño programa de pruebas: cargar r0 con 0 y r1 con 1, luego probar menor que, igual, distinto y menor o igual, y finalizar devolviendo 0 si todo salía bien. Pero el resultado era -1 debido a la línea que probaba la igualdad. El nuevo opcode IFEQ debía saltar solo si los registros eran iguales; aquí saltaba cuando evidentemente no lo eran.
Por dónde empezar. El programa de prueba era correcto. Revisé mis cambios en el ensamblador y no vi nada raro. Revisé la VM y tampoco. Añadí mensajes de depuración para ver qué ocurría paso a paso y encontré algo inquietante: parecía que la VM ejecutaba IFLT cuando yo había ensamblado IFEQ. Tenía dos hipótesis claras: o el ensamblador estaba generando el opcode equivocado o la VM estaba ejecutando otro distinto.
Con más trazas, la cosa se volvió más extraña: el ensamblador emitía los opcodes correctos para las comparaciones, pero al llegar a la VM, todos parecían ser el mismo, el de menor que. Era como si alguien reescribiera mi salida en el camino.
Eso era exactamente lo que pasaba. Un poco de contexto: en estas instrucciones de comparación siempre hay tres argumentos, dos registros y un desplazamiento de salto. Ese desplazamiento puede ser un inmediato o una etiqueta. Yo usaba una etiqueta y, durante la segunda pasada del ensamblador, esa etiqueta se resolvía a un desplazamiento numérico. El bug estaba en esa segunda pasada: al traducir la etiqueta a desplazamiento, una parte del código reescribía también el opcode de la línea, forzándolo a IFLT. Esa lógica venía de un momento en el que IFLT era el único opcode de comparación, así que no causaba problemas hasta que se añadieron más. La solución fue eliminar la sobrescritura y respetar el opcode original al resolver etiquetas.
La lección es clara: no siempre la culpa está en el código nuevo. En troubleshooting también hay que pensar fuera de la caja y desafiar suposiciones heredadas que ya no son válidas. Con el problema resuelto, el prototipo vuelve a mostrar un rendimiento muy prometedor y ojalá tengamos MiniScript 2.0 pronto.
En Q2BSTUDIO ayudamos a equipos a construir software robusto desde la base, desde ensambladores y VMs hasta plataformas de datos y productos listos para producción. Somos una empresa de desarrollo con foco en aplicaciones a medida y software a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, además de soluciones de ia para empresas y agentes IA. Si buscas un partner para acelerar tu hoja de ruta técnica, descubre cómo abordamos proyectos de alto rendimiento con nuestro enfoque de ingeniería y calidad.
Conoce más sobre nuestro enfoque de aplicaciones a medida y cómo combinamos buenas prácticas de compiladores, pruebas y observabilidad para reducir bugs difíciles desde el diseño. Y si quieres llevar tus productos al siguiente nivel con modelos de machine learning, copilotos y automatizaciones, explora nuestras soluciones de inteligencia artificial aplicadas a casos reales de negocio.
.jpg)