El ensamblador es el lenguaje más bajo, más cercano a la máquina, que normalmente uno utiliza. Sólo hay un escalón más: el código máquina. Sólo hay dos motivos por el cual alguien programaría en código máquina:
- Como recurso educativo
- Porque no existe compilador o no existe otra manera de hacer lo que uno quiere hacer.
Estoy convencido que la mayoría de programadores huirán del ensamblador como una lengua maldita. No me extraña, al ser un lenguaje de bajo nivel todo tiene que ser controlado por el programador y no existe ningún tipo de facilidad.
En junio de 1996 yo estaba finalizando mi segundo título de FPII: Tecnico especialista en electrónica de equipos informáticos. La asignatura de programación estaba orientada a la realización de un proyecto, en quinto podíamos elegir entre C/C++ o ensamblador. Yo elegí este último.
Me gustaba el ensamblador, esa mezcla de control total y tener que hacerlo todo uno mismo era algo a lo que no podía resistirme.
Mi proyecto consistió en crear una librería para ser utilizada en QuickBasic, la versión “profesional” de Basic que tenía Microsoft por aquel entonces. Con el MS-DOS venía una versión interpretada que se llamó QBasic. Dado que ambos interpretes/compiladores compartían sintaxis se les denominó QB. Las diferencias entre QuickBasic y QBasic no sólo consistían en que el primero permitía compilar nuestros proyectos para crear ejecutables, sino que además QuickBasic permitía el uso de librerías. Oficialmente QBasic no podía cargar librerías, pero como todo eso se podía hacer por medio de trucos, básicamente leyendo la librería y cargándola a mano en la memoria para que QBasic pudiera atacar las funciones almacenadas en ella.
Escribiría mi librería en ensamblador, pero ¿qué contendría?. El caso es que me había comprado el libro PC al límite en el que con la escusa de enseñar a crear videojuegos los autores (Boris Bertelsons -The CoExistence- y Mathias Rasch -Vision Factory-) te enseñaban a programar un montón de cosas fuera de lo habitual. Entre esas cosas estaba exprimir los límites de las tarjetas gráficas y los modos de vídeo normales para crear otros modos de vídeo más adecuados para crear juegos.
Así que dedicaría meses a desarrollar una librería para que QB pudiera utilizar el Modo X. En dicho modo se tenía una resolución de 320×240 pixels y 256 colores, realmente asombroso en los años 80 y principios de los 90.
Dado que el libro me explicaba de manera detallada cómo crear y utilizar dicho modo gráfico la dificultad no estaba en escribir el código. Además contaba con todo el código escrito en Pascal por los autores. Sin tener ni idea de Pascal me sirvió perfectamente a modo de pseudocódigo para entender qué es lo que había que hacer.
Así pues, la dificultad real y lo que me costó mucho tiempo era descubrir cómo tenía que escribir la librería para que esta pudiera acceder a los parámetros pasados por el usuario en las funciones y cómo devolver tipos de datos más allá de un entero.
Tuve la inconmensurable ayuda de un par de libros en los que describía cómo interactuaba el intérprete de Basic con las funciones en ensamblador. Sin embargo dichos libros sólo daban unas piceladas y no describían tipos de datos complejos ni diferencias ente compilador/intérprete que me dieron algún que otro dolor de cabeza.
En GitHub está lo que he podido recuperar, ha sido un poco difícil descubrir que copia de las muchas que tenía era la buena.
El código es el que entregué como proyecto, sin embargo he reemplazado la documentación original entregada con el proyecto por archivos en Markdown. Así mismo he añadido un par de documentos que cree con el resumen de la documentación utilizada para entender la interfaz ensamblador/QB.
Otro al que le encantó el ensamblador. De hecho, aprendí primero ensamblador que C, y gracias al primero fue por lo que entendí sin problemas los punteros del segundo.
En aquella época yo era más de Turbo Basic que de Quick Basic, y cuando empecé a hacer ese tipo de cositas, eran con ensamblador y Turbo C. En mi caso opté por el modo 13h, mucho más fácil de programar que el X.
Me quedó pendiente VESA, que en modo protegido era una pasada, pero sólo llegué a hacer pinitos.
Te felicito por el proyecto en Github, te has currado la documentación, y se el tedio que eso representa, en especial después de tantos años.
Como digo en su día me llevo meses llegar a entender bien cómo QB estructuraba en memoria los diversos tipos de variables y las diferencias entre QBasic y QuickBasic. Así que a la hora de rescatar el proyecto para publicarlo no quería hacerlo de cualquier manera y me decidí por convertir toda la documentación a Markdown, ya que de esta manera cualquiera podría ver la documentación sin necesitar ningún programa externo y sin salir del navegador.
Además, ya puestos, me puse a transcribir el capítulo de la “GW-BASIC: Guía del programador” que fue fundamental para saber y entender cómo enlazar QB con ensamblador. Creo que fueron un par de horas de mecanografía y edición, y creo que están bien invertidas.
Evidentemente el proyecto en sí estaba muerto desde el principio pues ya se sabía que VESA era el futuro inmediato cuando yo estaba con estas cosas. Pero el proyecto no trataba de ser útil, se trataba de:
1. Demostrar el dominio de un lenguaje de programación
2. Demostrar el dominio de la algoritmia
Lo que más me gustó del proyecto fue que no tenía toda la información, y la poca que tenía no era 100% adecuada. Tuve que echarle imaginación y recurrir al método científico (Hipótesis, Pruebas, Conclusiones) para desentrañar bien cómo funcionaba QB en memoria cuando se llamaba a una función de una librería. Que en suma se podría traducir en “prueba y error” y que fue lo que más tiempo me consumió.
Por cierto que cotilleando un poco el código, te voy a poner una pega, y es que usa instrucciones de 286. Es algo que no me gustaba, porque si no recuerdo mal, QB no era capaz de generar código 286, me parece que fue Microsoft Basic Compiler PDS el que sí lo soportaba.
Es decir, por un lado tenías el código BASIC que era 8086 y el tuyo con cosas de 286. Era como cuando se criticaba a Windows 95 por tener código de 16 bits que no aprovechaba el hardware.
Pues mira, entonces tiene más sentido haber programado esa librería en ensamblador, puesto que de esta forma no sólo extendemos QB sino que además dotamos a las nuevas funciones de más eficiencia al trabajar con un código objeto más optimizado.
Por cierto, podíamos haber creado esas nuevas funciones directamente desde QB: https://github.com/alphp/ModoX/blob/master/MODOX/MODOX.BAS
Esa parte (MODOX.BAS) la había pasado por alto. Menuda virguería. Hay que ver lo potente que era QB. Son de los dialectos que siempre me gustaron. Tanto QB, como QBASIC, Microsoft PDF, y luego Visual BASIC. Eran lenguajes que te permitían hacer guarradas de principiante, pero al mismo tiempo, hacer cosas potentes y bien estructuradas.