Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

El Ciego y el Mudo

–Programación sin Input ni Print–

chistecruel

Muchas veces al programar, pero sobre todo cuando se programa en Ensamblador, a veces se da entre el programador y la computadora una conversación entre un ciego y un mudo. La ilustración que acompaña a esta nota describe perfectamente esta situación, aunque la que yo estaba buscando era la de un ciego que entra a un baño público a orinar y no se percata de que un sordomudo está sentado en el WC frente al que está parado.

Mas específico, en los casos en lo que uno se inicia en la programación gráfica y no tiene acceso a funciones avanzadas de procesamiento de texto ni conversiones numéricas el monitor no sirve como dispositivo de salida para datos internos de la aplicación. Esto es lo mismo que si uno estuviera ciego. Al mismo tiempo, la computadora no puede leer entradas complicadas por el teclado y esto lo sabe cualquier estudiante que haya intentado procesar (por medio de un análisis léxico-sintáctico) cadenas alfanuméricas; en este caso, la computadora es como un sordomudo que no puede entender lo que le decimos. Por lo que para sostener un diálogo en esta situación es necesario usar un método de comunicación no convencional.

Mientras mas avanzo en esto de la programación en Ensamblador mas cuenta me doy del daño que produce haberse iniciado con lenguajes de ‘alto nivel’. Pues al menos en mi caso mi primer lenguaje al que le dediqué el tiempo suficiente para aprender fue el Qbasic que incluía el DOS en mi antigua Pentium 100 mhz. Las 2 instrucciones mas importantes para intercambio de datos entre el usuario y la computadora eran PRINT e INPUT. Con estas dos únicas instrucciones uno era capaz de darle datos al programa y ver que estaba pasando dentro de él. Y por supuesto que conforme aprendí otros lenguajes mas avanzados estos contaban con instrucciones equivalentes: readln y writeln en pascal, printf() y scanf() en C, cin y cout en C++ y así hasta que llegué al Ensamblador. Pues aunque habían funciones del BIOS o del sistema operativo no eran para nada tan sencillas de manejar como en su tiempo lo fueron INPUT y PRINT.

No hay peor ciego que el que no quiere oir.

Y de esto es de lo que trata esta nota, sobre como los métodos mas populares de entrada y salida en los lenguajes de nivel usuario no sirven en Ensamblador o el costo de implementarlos hace que no valga la pena su uso. Para poner un ejemplo cercano, el primer gran reto al que nos vamos a enfrentar en las siguientes notas de programación gráfica es el de no tener un método práctico y sencillo de implementar funciones de entrada y salida entre la computadora y el usuario. Pues las tradicionales funciones como las de MessageBox o las que involucran las GUI de Windows no funcionan a la hora de escribir directo a la tarjeta de video o si acaso llegan a funcionar su comportamiento no es nada predecible. Y aunque DirectX es compatible con los DeviceContext los resultados no son muy buenos. Como ejemplo la fotografía del monitor de la computadora aparecida en la nota “Revancha de 32 Bits” muestra el contenido de una sección de memoria relativamente pequeña, apenas unos 20 dwords. ¡Pero ocupa casi un tercio de la pantalla!. Por ejemplo, si quisiéramos mostrar una multiplicación de matrices de 4 por 4 con flotantes de 32 bits una pantalla completa no sería suficiente.

En resumen, los métodos usuales de despliegue de datos en pantalla no nos sirven de momento, la parte de entrada de datos no es dificil si escribimos estos directo en el source code o en algun área de datos inicializados; pero la salida es otra cosa. Una solución sencilla que se me acaba de ocurrir es la de sacar los datos que nos interesan por medio de un archivo binario y luego leerlos con cualquier editor hexadecimal externo a la aplicación desarrollada. Con esto nos ahorraríamos el esfuerzo de hacer todas estas cosas:

  • Funciones de salida de texto a pantalla
  • Conversiones entre datos binarios y ascii para su despliegue
  • Rutinas de formato de texto para darle una apariencia medianamente legible
  • Capacidades de ‘scrolling’ de texto para desplegar grandes cantidades de datos en zonas pequeñas de pantalla
  • Controles de actualización de salida para mostrar información de manera mas dinámica.

Y eso sin mencionar la ventaja que supondría tener un archivo de respaldo con la salida del programa en lugar de que estos datos se pierdan en cada inicialización. Creo que es oportuno mencionar que darle capacidades de texto a un sistema orientado a gráficos es algo que se hace en una etapa muy avanzada de desarrollo. Primero habría que conocer rutinas para manejo de sprites en un sistema tipo ‘raster’ o conocer de las matemáticas vectoriales en un sistemas mas avanzado. Así que por ahora quedémonos con los humildes trozos de datos binarios facilmente interpretados por un editor hexadecimal externo.

RAW DATA o datos sin curtir

vistahex

Esta es la solución mas rápida y sencilla de aplicar para el problema de la salida de datos en nuestros primeros programas de manejo de gráficos. Un par de mejoras podrían ser poner valores predefinidos entre los datos para que sean mas fáciles de ubicar en la ventana del editor hexadecimal o inclusive hasta hacer un programa completo para interpretar esta clase de archivos de salida y presentarlos en un modo mucho mas legible. Esto aunque supondría un esfuerzo en si mismo evitaría sobrecargar el programa original con funciones de depuración no indispensables y permitiría una mejor reutilización de estos códigos en otros programas.

No recuerdo bien el nombre de esta técnica pero muchos llaman a esta clase de bloques binarios sin procesar “Raw Data”, que podría traducirse como Datos Crudos. El término Raw se usa para describir los materiales en su estado natural antes de ser procesados, por ejemplo pieles o madera. Ahora vamos a lo interesante, los detalles de la implementación.

Y esta es la mejor parte porque ¡Ya todo está hecho!. Si miran atrás encontrarán una nota en este mismo blog titulada “Darwin Digital” donde viene un programa en ensamblador que lee un archivo de texto y lo copia con otro nombre. Tranquilamente pueden arrancar la parte de ese programa que se encarga de escribir el archivo. Solo es cosa de definir un espacio en la sección de datos donde escribiremos la información que queremos ver y llamamos a la API de Windows para escribir el archivo.

Hasta ahora la única limitante que le veo, o debería de decir le veía a este sistema era el no poder visualizar datos en tiempo real. Pero pensándolo bien, en un sistema multitarea como lo es Windows bastaría con pasar de una aplicación a otra con ALT-TAB o el Task Manager y recargar el archivo en el editor hexadecimal. No sería tan rápido como escribir directo a pantalla pero al menos no estaríamos limitados al poco espacio para exhibir información que nos da la pantalla. Ahora que lo pienso, la ‘ceguera’ del programador en esta clase de situaciones es temporal, como la de alguien que se asoma a un cuarto oscuro con tesoros pero solo puede ver lo que sacó hasta que lo lleva a la entrada del mismo.

Es una pena que esto se me acabe de ocurrir hace apenas unas horas. De haber pasado esto hace una semana pude haber adelantado mucho en el tema de la Programación Gráfica en este blog. Estas últimas semanas no pude programar tanto como quería por motivos ajenos a mi control.

enero 29, 2010 - Posted by | Uncategorized | ,

1 comentario »

  1. escuela para sordos y mudos

    Comentario por Edgar Tapia | marzo 8, 2013 | Responder


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: