Programación en lenguaje ensamblador x86

La herramienta más importante para la programación en lenguaje ensamblador es el ensamblador, el software que convierte el código en lenguaje ensamblador a lenguaje máquina. Hay disponibles dos tipos de ensambladores muy diferentes para FreeBSD.

El primero es el as(1) de GNU (devel/binutils), que usa la sintaxis tradicional del lenguaje ensamblador de UNIX. Como alternativa, se puede usar clang(1), que es un reemplazo compatible del ensamblador de GNU y viene con el sistema.

El otro es nasm(1) (devel/nasm). Este ensamblador usa la sintaxis de Intel, y su principal ventaja es que puede ensamblar código para muchos sistemas operativos.

Este artículo usa la sintaxis de nasm porque la mayoría de los programadores de lenguaje ensamblador que llegan a FreeBSD desde otros sistemas operativos la encontrarán más fácil de entender. Y, además, porque, francamente, es a lo que estoy acostumbrado.

La salida del ensamblador, como la de cualquier compilador, necesita enlazarse para formar un archivo ejecutable.

El enlazador estándar ld(1) viene con FreeBSD. Funciona con el código ensamblado con cualquiera de los dos ensambladores.

Por defecto, el kernel de FreeBSD usa la convención de llamada de C. Además, aunque se accede al kernel usando int 80h, se asume que el programa llamará a una función que emite int 80h, en lugar de emitir int 80h directamente.

Esta convención es muy cómoda, y bastante superior a la convención de Microsoft® usada por MS-DOS®. ¿Por qué? Porque la convención de UNIX permite que cualquier programa escrito en cualquier lenguaje acceda al kernel.

Un programa en lenguaje ensamblador también puede hacerlo. Por ejemplo, podríamos abrir un archivo:

Esta es una forma de programar muy limpia y portable. Si necesita portar el código a un sistema UNIX que use una interrupción diferente, o una forma diferente de pasar los parámetros, todo lo que necesita cambiar es el procedimiento kernel.

Pero a los programadores de lenguaje ensamblador les gusta recortar ciclos. El ejemplo anterior requiere una combinación call/ret. Podemos eliminarla haciendo push de un dword adicional:

El 5 que hemos colocado en EAX identifica la función del kernel, en este caso open.

FreeBSD es un sistema extremadamente flexible. Ofrece otras formas de llamar al kernel. Sin embargo, para que funcione, el sistema debe tener instalada la emulación de Linux®.

Linux es un sistema similar a UNIX. Sin embargo, su kernel usa la misma convención de llamadas al sistema de pasar parámetros en registros que usa MS-DOS. Al igual que con la convención de UNIX, el número de función se coloca en EAX. Los parámetros, sin embargo, no se pasan en la pila sino en EBX, ECX, EDX, ESI, EDI, EBP:

Esta convención tiene una gran desventaja frente a la forma de UNIX®, al menos en lo que respecta a la programación en lenguaje ensamblador: Cada vez que hace una llamada al kernel debe hacer push de los registros, y luego pop de ellos más tarde. Esto hace que su código sea más voluminoso y más lento. No obstante, FreeBSD le ofrece una opción.

Si elige la convención de Linux, debe informar de ello al sistema. Después de ensamblar y enlazar su programa, necesita marcar el ejecutable:

Si está programando específicamente para FreeBSD, siempre debería usar la convención de UNIX: Es más rápida, puede almacenar variables globales en registros, no tiene que marcar el ejecutable, y no impone la instalación del paquete de emulación de Linux en el sistema de destino.

Si quiere crear código portable que también pueda ejecutarse en Linux, probablemente aun así querrá dar a los usuarios de FreeBSD un código tan eficiente como sea posible. Le mostraré cómo puede lograrlo después de haber explicado los fundamentos.

Para indicarle al kernel qué servicio del sistema está llamando, coloque su número en EAX. Por supuesto, necesita saber cuál es el número.

El lugar tradicional para buscar información sobre las diversas llamadas al sistema en sistemas UNIX son las páginas de manual. FreeBSD describe sus llamadas al sistema en la sección 2, a veces en la sección 3.

Por ejemplo, open(2) dice:

El programador de lenguaje ensamblador nuevo en UNIX y FreeBSD se hará de inmediato la desconcertante pregunta: ¿dónde está errno y cómo llego a él?

Desafortunadamente, depende…​ Para la mayoría de las llamadas al sistema está en EAX, pero no para todas. Una buena regla general, cuando se trabaja con una llamada al sistema por primera vez, es buscar el valor de retorno en EAX. Si no está ahí, necesita investigar más.

En realidad, en ninguna parte…​

errno es parte del lenguaje C, no del kernel de UNIX. Al acceder a los servicios del kernel directamente, el código de error se devuelve en EAX, el mismo registro en el que generalmente acaba el valor de retorno propiamente dicho.

Esto tiene todo el sentido. Si no hay error, no hay código de error. Si hay un error, no hay valor de retorno. Un mismo registro puede contener cualquiera de los dos.

Al usar la convención de llamada estándar de FreeBSD, el carry flag se limpia en caso de éxito, y se establece en caso de fallo.

Al usar el modo de emulación de Linux, el valor con signo en EAX es no negativo en caso de éxito, y contiene el valor de retorno. En caso de error, el valor es negativo, es decir, -errno.

En muchos casos los números de función son los mismos. Sin embargo, incluso cuando no lo son, el problema es fácil de abordar: En lugar de usar números en su código, use constantes que haya declarado de forma diferente según la arquitectura de destino:

Tanto la convención de llamada como el valor de retorno (el problema de errno) pueden resolverse con macros:

Las soluciones anteriores pueden manejar la mayoría de los casos de escritura de código portable entre FreeBSD y Linux. No obstante, con algunos servicios del kernel las diferencias son más profundas.

En ese caso, necesita escribir dos manejadores diferentes para esas llamadas al sistema concretas, y usar ensamblado condicional. Afortunadamente, la mayor parte de su código hace algo distinto de llamar al kernel, así que normalmente solo necesitará unas pocas de estas secciones condicionales en su código.

Puede evitar por completo los problemas de portabilidad en su código principal escribiendo una biblioteca de llamadas al sistema. Cree una biblioteca separada para FreeBSD, otra diferente para Linux, y aún otras bibliotecas para más sistemas operativos.

En su biblioteca, escriba una función separada (o procedimiento, si prefiere la terminología tradicional del lenguaje ensamblador) para cada llamada al sistema. Use la convención de C de pasar parámetros. Pero siga usando EAX para pasar el número de llamada. En ese caso, su biblioteca de FreeBSD puede ser muy simple, ya que muchas funciones aparentemente diferentes pueden ser simplemente etiquetas del mismo código:

Su biblioteca de Linux requerirá más funciones diferentes. Pero incluso aquí puede agrupar las llamadas al sistema que usan el mismo número de parámetros:

El enfoque de la biblioteca puede parecer inconveniente al principio porque le obliga a producir un archivo separado del que depende su código. Pero tiene muchas ventajas: por un lado, solo necesita escribirla una vez y puede usarla para todos sus programas. Incluso puede permitir que otros programadores de lenguaje ensamblador la usen, o quizá usar una escrita por otra persona. Pero quizá la mayor ventaja de la biblioteca es que su código puede portarse a otros sistemas, incluso por otros programadores, simplemente escribiendo una nueva biblioteca sin ningún cambio en su código.

Si no le gusta la idea de tener una biblioteca, puede al menos colocar todas sus llamadas al sistema en un archivo de lenguaje ensamblador separado y enlazarlo con su programa principal. Aquí, de nuevo, todo lo que los portadores tienen que hacer es crear un nuevo archivo objeto para enlazar con su programa principal.

Si publica su software como (o con) código fuente, puede usar macros y colocarlas en un archivo separado, que incluye en su código.

Los portadores de su software simplemente escribirán un nuevo archivo de inclusión. No se necesita ninguna biblioteca ni archivo objeto externo, y aun así su código es portable sin ninguna necesidad de editarlo.

Podemos empezar nuestro system.inc declarando los descriptores de archivo estándar:

A continuación, creamos un nombre simbólico para cada llamada al sistema:

Añadimos un procedimiento corto, no global, con un nombre largo, para no reutilizar accidentalmente el nombre en nuestro código:

Creamos una macro que toma un argumento, el número de syscall:

Finalmente, creamos macros para cada syscall. Estas macros no toman argumentos.

Adelante, introdúzcalo en su editor y guárdelo como system.inc. Le añadiremos más a medida que tratemos más syscalls.

Escriba el código en un editor, y guárdelo en un archivo llamado hello.asm. Necesita devel/nasm para ensamblarlo.

Ahora puede ensamblar, enlazar, y ejecutar el código:

Aunque nuestro programa de ejemplo no lo requiere, los filtros más sofisticados a menudo necesitan mirar hacia adelante. En otras palabras, pueden necesitar ver cuál es el siguiente carácter (o incluso varios caracteres). Si el siguiente carácter tiene un cierto valor, es parte del token que se está procesando actualmente. De lo contrario, no lo es.

Por ejemplo, puede estar analizando el flujo de entrada en busca de una cadena de texto (p. ej., al implementar un compilador de un lenguaje): Si a un carácter le sigue otro carácter, o quizá un dígito, es parte del token que está procesando. Si le sigue un espacio en blanco, o algún otro valor, entonces no es parte del token actual.

Esto presenta un problema interesante: ¿cómo devolver el siguiente carácter al flujo de entrada, de modo que pueda leerse de nuevo más tarde?

Una posible solución es almacenarlo en una variable de carácter, y luego establecer un indicador. Podemos modificar getchar para que compruebe el indicador, y si está establecido, obtenga el byte de esa variable en lugar del búfer de entrada, y restablezca el indicador. Pero, por supuesto, eso nos ralentiza.

El lenguaje C tiene una función ungetc(), precisamente para ese propósito. ¿Hay una forma rápida de implementarla en nuestro código? Me gustaría que volviera hacia arriba y echara un vistazo al procedimiento getchar y viera si puede encontrar una solución buena y rápida antes de leer el siguiente párrafo. Luego vuelva aquí y vea mi propia solución.

La clave para devolver un carácter al flujo está en cómo obtenemos los caracteres en primer lugar:

Primero comprobamos si el búfer está vacío evaluando el valor de EBX. Si es cero, llamamos al procedimiento read.

Si tenemos un carácter disponible, usamos lodsb, y luego decrementamos el valor de EBX. La instrucción lodsb es efectivamente idéntica a:

El byte que hemos obtenido permanece en el búfer hasta la próxima vez que se llame a read. No sabemos cuándo ocurre eso, pero sí sabemos que no ocurrirá hasta la siguiente llamada a getchar. Por lo tanto, para "devolver" el último byte leído al flujo, todo lo que tenemos que hacer es decrementar el valor de ESI e incrementar el valor de EBX:

¡Pero tenga cuidado! Hacer esto es perfectamente seguro si nuestra anticipación es de como mucho un carácter cada vez. Si estamos examinando más de un carácter próximo y llamamos a ungetc varias veces seguidas, funcionará la mayoría de las veces, pero no siempre (y será difícil de depurar). ¿Por qué?

Porque mientras getchar no tenga que llamar a read, todos los bytes leídos por anticipado siguen en el búfer, y nuestro ungetc funciona sin ningún fallo. Pero en el momento en que getchar llama a read, el contenido del búfer cambia.

Siempre podemos confiar en que ungetc funcione correctamente sobre el último carácter que hemos leído con getchar, pero no sobre nada que hayamos leído antes de eso.

Si su programa lee más de un byte por anticipado, tiene al menos dos opciones:

Si es posible, modifique el programa para que solo lea un byte por anticipado. Esta es la solución más sencilla.

Si esa opción no está disponible, determine en primer lugar el número máximo de caracteres que su programa necesita devolver al flujo de entrada de una sola vez. Aumente ese número ligeramente, solo para estar seguro, preferiblemente a un múltiplo de 16, para que se alinee bien. Luego modifique la sección .bss de su código, y cree un pequeño búfer "de reserva" justo antes de su búfer de entrada, algo así:

También necesita modificar su ungetc para pasar en AL el valor del byte que se va a devolver:

Con esta modificación, puede llamar a ungetc hasta 17 veces seguidas de forma segura (la primera llamada seguirá estando dentro del búfer, las 16 restantes pueden estar dentro del búfer o dentro del de "reserva").

He dicho antes que cuando un programa comienza a ejecutarse, la pila contiene argc seguido del array argv terminado en NULL, seguido de algo más. El "algo más" es el entorno, o, para ser más precisos, un array terminado en NULL de punteros a las variables de entorno. A esto se le suele denominar env.

La estructura de env es la misma que la de argv, una lista de direcciones de memoria seguida de un NULL (0). En este caso, no hay ningún "envc": averiguamos dónde termina el array buscando el NULL final.

Las variables suelen venir en el formato name=value, pero a veces puede faltar la parte =value. Necesitamos tener en cuenta esa posibilidad.

Podría simplemente mostrarle algo de código que imprima el entorno de la misma forma que lo hace el comando env de UNIX. Pero he pensado que sería más interesante escribir una sencilla utilidad CGI en lenguaje ensamblador.

El problema se resuelve fácilmente usando una técnica llamada máquina de estados finitos, desarrollada originalmente por los diseñadores de circuitos electrónicos digitales. Una máquina de estados finitos es un circuito digital cuya salida depende no solo de su entrada sino de su entrada previa, es decir, de su estado. El microprocesador es un ejemplo de máquina de estados finitos: nuestro código en lenguaje ensamblador se ensambla a lenguaje máquina en el que cierto código en lenguaje ensamblador produce un solo byte de lenguaje máquina, mientras que otro produce varios bytes. A medida que el microprocesador obtiene los bytes de la memoria uno a uno, algunos de ellos simplemente cambian su estado en lugar de producir alguna salida. Cuando se han obtenido todos los bytes del código de operación, el microprocesador produce alguna salida, o cambia el valor de un registro, etc.

Debido a eso, todo el software es esencialmente una secuencia de instrucciones de estado para el microprocesador. No obstante, el concepto de máquina de estados finitos también es útil en el diseño de software.

Nuestro conversor de archivos de texto puede diseñarse como una máquina de estados finitos con tres estados posibles. Podríamos llamarlos estados 0-2, pero nos facilitará la vida si les damos nombres simbólicos:

Nuestro programa comenzará en el estado ordinary. Durante este estado, la acción del programa depende de su entrada de la siguiente manera:

Siempre que estamos en el estado cr, es porque la última entrada fue un retorno de carro, que quedó sin procesar. Lo que hace nuestro software en este estado depende de nuevo de la entrada actual:

Finalmente, estamos en el estado lf después de haber recibido un avance de línea que no estuvo precedido por un retorno de carro. Esto ocurrirá cuando nuestro archivo ya esté en formato UNIX, o siempre que varias líneas seguidas se expresen mediante un único retorno de carro seguido de varios avances de línea, o cuando una línea termine con una secuencia de avance de línea / retorno de carro. Así es como necesitamos manejar nuestra entrada en este estado:

La parte más difícil de trabajar con una máquina de estados finitos es analizar el problema y expresarlo como una máquina de estados finitos. Logrado eso, el software casi se escribe solo.

En un lenguaje de alto nivel, como C, hay varios enfoques principales. Uno es usar una sentencia switch que elige qué función debe ejecutarse. Por ejemplo,

Otro enfoque es usar un array de punteros a función, algo así:

Otro más es hacer que state sea un puntero a función, configurado para apuntar a la función apropiada:

Este es el enfoque que usaremos en nuestro programa porque es muy fácil de hacer en lenguaje ensamblador, y muy rápido, además. Simplemente mantendremos la dirección del procedimiento correcto en EBX, y luego solo emitiremos:

Esto es posiblemente más rápido que codificar la dirección directamente en el código porque el microprocesador no tiene que obtener la dirección de la memoria: ya está almacenada en uno de sus registros. He dicho posiblemente porque con el almacenamiento en caché que hacen los microprocesadores modernos, ambas formas pueden ser igual de rápidas.

Como nuestro programa trabaja sobre un único archivo, no podemos usar el enfoque que nos funcionó antes, es decir, leer de un archivo de entrada y escribir en un archivo de salida.

UNIX nos permite mapear un archivo, o una sección de un archivo, en memoria. Para hacer eso, primero necesitamos abrir el archivo con los indicadores de lectura/escritura apropiados. Luego usamos la llamada al sistema mmap para mapearlo en la memoria. Una cosa buena de mmap es que funciona automáticamente con la memoria virtual: Podemos mapear en la memoria más del archivo del que tenemos memoria física disponible, y aun así acceder a él mediante códigos de operación de memoria normales, como mov, lods, y stos. Cualesquiera cambios que hagamos a la imagen en memoria del archivo serán escritos al archivo por el sistema. Ni siquiera tenemos que mantener el archivo abierto: mientras permanezca mapeado, podemos leer de él y escribir en él.

Los microprocesadores Intel de 32 bits pueden acceder hasta a cuatro gigabytes de memoria, física o virtual. El sistema FreeBSD nos permite usar hasta la mitad de ella para el mapeo de archivos.

En aras de la simplicidad, en este tutorial solo convertiremos archivos que puedan mapearse en la memoria en su totalidad. Probablemente no haya demasiados archivos de texto que superen los dos gigabytes de tamaño. Si nuestro programa encuentra uno, simplemente mostrará un mensaje sugiriendo que usemos el tuc original en su lugar.

Si examina su copia de syscalls.master, encontrará dos syscalls separadas llamadas mmap. Esto se debe a la evolución de UNIX: existía el mmap tradicional de BSD, la syscall 71. Esa fue reemplazada por el mmap de POSIX®, la syscall 197. El sistema FreeBSD admite ambas porque los programas más antiguos se escribieron usando la versión BSD original. Pero el software nuevo usa la versión POSIX, que es la que usaremos.

El syscalls.master lista la versión POSIX así:

Esto difiere ligeramente de lo que dice mmap(2). Eso se debe a que mmap(2) describe la versión de C.

La diferencia está en el argumento long pad, que no está presente en la versión de C. Sin embargo, las syscalls de FreeBSD añaden un relleno de 32 bits después de hacer push de un argumento de 64 bits. En este caso, off_t es un valor de 64 bits.

Cuando terminamos de trabajar con un archivo mapeado en memoria, lo desmapeamos con la syscall munmap:

Como necesitamos indicarle a mmap cuántos bytes del archivo mapear en la memoria, y como queremos mapear el archivo entero, necesitamos determinar el tamaño del archivo.

Podemos usar la syscall fstat para obtener toda la información sobre un archivo abierto que el sistema pueda darnos. Eso incluye el tamaño del archivo.

De nuevo, syscalls.master lista dos versiones de fstat, una tradicional (syscall 62), y una POSIX (syscall 189). Naturalmente, usaremos la versión POSIX:

Esta es una llamada muy sencilla: le pasamos la dirección de una estructura stat y el descriptor de un archivo abierto. Rellenará el contenido de la estructura stat.

Sin embargo, tengo que decir que intenté declarar la estructura stat en la sección .bss, y a fstat no le gustó: estableció el carry flag indicando un error. Después de cambiar el código para asignar la estructura en la pila, todo funcionaba bien.

Como nuestro programa puede combinar secuencias de retorno de carro / avance de línea en simples avances de línea, nuestra salida puede ser más pequeña que nuestra entrada. Sin embargo, como estamos colocando nuestra salida en el mismo archivo del que leemos la entrada, puede que tengamos que cambiar el tamaño del archivo.

La llamada al sistema ftruncate nos permite hacer precisamente eso. A pesar de su nombre algo engañoso, la llamada al sistema ftruncate puede usarse tanto para truncar el archivo (hacerlo más pequeño) como para agrandarlo.

Y sí, encontraremos dos versiones de ftruncate en syscalls.master, una más antigua (130), y una más nueva (201). Usaremos la más nueva:

Tenga en cuenta que esta contiene de nuevo un int pad.

Ahora sabemos todo lo que necesitamos para escribir ftuc. Empezamos añadiendo algunas líneas nuevas en system.inc. Primero, definimos algunas constantes y estructuras, en algún lugar al principio del archivo o cerca de él:

Definimos las nuevas syscalls:

Añadimos las macros para su uso:

Y aquí está nuestro código:

Ilustraré este principio con un ejemplo concreto de la vida real al que me enfrenté recientemente:

Necesitaba extraer el undécimo campo de cada registro de una base de datos que descargué de un sitio web. La base de datos era un archivo CSV, es decir, una lista de valores separados por comas. Ese es un formato bastante estándar para compartir datos entre personas que pueden estar usando software de bases de datos diferente.

La primera línea del archivo contiene la lista de los diversos campos separados por comas. El resto del archivo contiene los datos listados línea por línea, con los valores separados por comas.

Probé con awk, usando la coma como separador. Pero como varias líneas contenían una coma entrecomillada, awk extraía el campo equivocado de esas líneas.

Por lo tanto, necesitaba escribir mi propio software para extraer el undécimo campo del archivo CSV. Sin embargo, siguiendo el espíritu de UNIX, solo necesitaba escribir un filtro sencillo que hiciera lo siguiente:

Estrictamente hablando, podría usar sed para eliminar la primera línea del archivo, pero hacerlo en mi propio programa era muy fácil, así que decidí hacerlo y reducir el tamaño de la tubería.

En cualquier caso, escribir un programa como este me llevó unos 20 minutos. Escribir un programa que extrajera el undécimo campo del archivo CSV llevaría mucho más tiempo, y no podría reutilizarlo para extraer algún otro campo de alguna otra base de datos.

Esta vez decidí dejar que hiciera un poco más de trabajo del que haría un programa de tutorial típico:

Aquí está su mensaje de uso:

Todos los parámetros son opcionales, y pueden aparecer en cualquier orden.

El parámetro -t declara por qué reemplazar las comas. El tab es el valor por defecto aquí. Por ejemplo, -t; reemplazará todas las comas no entrecomilladas por puntos y comas.

No necesitaba la opción -c, pero puede resultar útil en el futuro. Me permite declarar que quiero que un carácter distinto de una coma sea reemplazado por otra cosa. Por ejemplo, -c@ reemplazará todos los signos de arroba (útil si quiere dividir una lista de direcciones de correo electrónico en sus nombres de usuario y dominios).

La opción -p preserva la primera línea, es decir, no la elimina. Por defecto, eliminamos la primera línea porque en un archivo CSV contiene los nombres de los campos en lugar de datos.

Las opciones -i y -o me permiten especificar los archivos de entrada y de salida. Los valores por defecto son stdin y stdout, así que este es un filtro UNIX normal.

Me aseguré de que se aceptaran tanto -i filename como -ifilename. También me aseguré de que solo pudiera especificarse un archivo de entrada y uno de salida.

Para obtener el undécimo campo de cada registro, ahora puedo hacer:

El código almacena las opciones (salvo los descriptores de archivo) en EDX: la coma en DH, el nuevo separador en DL, y el indicador de la opción -p en el bit más alto de EDX, de modo que una comprobación de su signo nos dará una decisión rápida sobre qué hacer.

Aquí está el código:

Gran parte de él está tomado del hex.asm anterior. Pero hay una diferencia importante: ya no llamo a write cada vez que produzco un avance de línea. Aun así, el código puede usarse de forma interactiva.

He encontrado una solución mejor para el problema interactivo desde que empecé a escribir este artículo. Quería asegurarme de que cada línea se imprima por separado solo cuando sea necesario. Al fin y al cabo, no hay necesidad de volcar cada línea cuando se usa de forma no interactiva.

La nueva solución que uso ahora es llamar a write cada vez que encuentro el búfer de entrada vacío. De esa forma, al ejecutarse en modo interactivo, el programa lee una línea del teclado del usuario, la procesa, y ve que su búfer de entrada está vacío. Vuelca su salida y lee la siguiente línea.

La FPU consta de 8 registros de coma flotante de 80 bits. Estos están organizados a modo de pila: puede hacer push de un valor en la TOS (cima de la pila) y puede hacer pop de él.

Dicho esto, los códigos de operación del lenguaje ensamblador no son push y pop porque esos ya están ocupados.

Puede hacer push de un valor en la TOS usando fld, fild, y fbld. Varios otros códigos de operación le permiten hacer push de muchas constantes comunes -como pi- en la TOS.

De forma similar, puede hacer pop de un valor usando fst, fstp, fist, fistp, y fbstp. En realidad, solo los códigos de operación que terminan en p harán literalmente pop del valor, el resto lo almacenarán en otro lugar sin quitarlo de la TOS.

Podemos transferir los datos entre la TOS y la memoria del ordenador bien como un real de 32, 64, u 80 bits, un entero de 16, 32, o 64 bits, o un decimal empaquetado de 80 bits.

El decimal empaquetado de 80 bits es un caso especial del decimal codificado en binario que es muy conveniente al convertir entre la representación ASCII de los datos y los datos internos de la FPU. Nos permite usar 18 dígitos significativos.

Independientemente de cómo representemos los datos en la memoria, la FPU siempre los almacena en el formato real de 80 bits en sus registros.

Su precisión interna es de al menos 19 dígitos decimales, así que incluso si elegimos mostrar los resultados como ASCII con la precisión completa de 18 dígitos, seguimos mostrando resultados correctos.

Podemos realizar operaciones matemáticas sobre la TOS: podemos calcular su seno, podemos escalarla (es decir, podemos multiplicarla o dividirla por una potencia de 2), podemos calcular su logaritmo en base 2, y muchas otras cosas.

También podemos multiplicarla o dividirla por, sumarla a, o restarla de, cualquiera de los registros de la FPU (incluido él mismo).

El código de operación oficial de Intel para la TOS es st, y para los registros st(0)-st(7). st y st(0), entonces, se refieren al mismo registro.

Por las razones que sean, el autor original de nasm decidió usar códigos de operación diferentes, a saber st0-st7. En otras palabras, no hay paréntesis, y la TOS siempre es st0, nunca solo st.

Para escribir software con sentido, no solo debemos entender nuestras herramientas de programación, sino también el campo para el que estamos creando software.

Nuestro próximo filtro nos ayudará siempre que queramos construir una cámara estenopeica, así que necesitamos algunos conocimientos previos sobre fotografía estenopeica antes de poder continuar.

Ya estamos listos para decidir qué queremos exactamente que haga nuestro software del estenopo.

En lenguaje ensamblador podemos optimizar el código de la FPU de formas imposibles en los lenguajes de alto nivel, incluido C.

Siempre que una función C necesita calcular un valor de coma flotante, carga todas las variables y constantes necesarias en los registros de la FPU. Luego hace el cálculo que sea necesario para obtener el resultado correcto. Los buenos compiladores de C pueden optimizar esa parte del código realmente bien.

"Devuelve" el valor dejando el resultado en la TOS. Sin embargo, antes de retornar, limpia. Cualesquiera variables y constantes que usó en su cálculo han desaparecido ahora de la FPU.

No puede hacer lo que acabamos de hacer arriba: calculamos el cuadrado del número f y lo mantuvimos en la pila para su uso posterior por otra función.

Sabíamos que necesitaríamos ese valor más adelante. También sabíamos que teníamos suficiente espacio en la pila (que solo tiene espacio para 8 números) para almacenarlo ahí.

Un compilador de C no tiene forma de saber que un valor que tiene en la pila volverá a requerirse en un futuro muy próximo.

Por supuesto, el programador de C puede saberlo. Pero el único recurso que tiene es almacenar el valor en una variable de memoria.

Eso significa, por un lado, que el valor se cambiará de la precisión de 80 bits usada internamente por la FPU a un double de C (64 bits) o incluso a un single (32 bits).

Eso también significa que el valor debe moverse de la TOS a la memoria, y luego de vuelta. Por desgracia, de todas las operaciones de la FPU, las que acceden a la memoria del ordenador son las más lentas.

Así que, siempre que programe la FPU en lenguaje ensamblador, busque las formas de mantener los resultados intermedios en la pila de la FPU.

¡Podemos llevar esa idea aún más lejos! En nuestro programa estamos usando una constante (la que llamamos PC).

No importa cuántos diámetros de estenopo estemos calculando: 1, 10, 20, 1000, siempre estamos usando la misma constante. Por lo tanto, podemos optimizar nuestro programa manteniendo la constante en la pila todo el tiempo.

Al principio de nuestro programa, estamos calculando el valor de la constante anterior. Necesitamos dividir nuestra entrada por 10 por cada dígito de la constante.

Es mucho más rápido multiplicar que dividir. Así que, al comienzo de nuestro programa, dividimos 1 entre 10 para obtener 0.1, que luego mantenemos en la pila: en lugar de dividir la entrada por 10 por cada dígito, la multiplicamos por 0.1.

Por cierto, no introducimos 0.1 directamente, aunque podríamos. Tenemos una razón para ello: aunque 0.1 puede expresarse con un solo decimal, no sabemos cuántas posiciones binarias ocupa. Por lo tanto, dejamos que la FPU calcule su valor binario con su propia alta precisión.

Estamos usando otras constantes: multiplicamos el diámetro del estenopo por 1000 para convertirlo de milímetros a micras. Comparamos números con 10000 cuando los redondeamos a cuatro dígitos significativos. Así que mantenemos ambos, 1000 y 10000, en la pila. Y, por supuesto, reutilizamos el 0.1 al redondear números a cuatro dígitos.

Por último, pero no menos importante, mantenemos -5 en la pila. Lo necesitamos para escalar el cuadrado del número f, en lugar de dividirlo por 32. No es por casualidad que carguemos esta constante en último lugar. Eso hace que sea la cima de la pila cuando solo las constantes están en ella. Así, cuando se está escalando el cuadrado del número f, el -5 está en st(1), precisamente donde fscale espera que esté.

Es común crear ciertas constantes desde cero en lugar de cargarlas desde la memoria. Eso es lo que estamos haciendo con -5:

Podemos generalizar todas estas optimizaciones en una sola regla: ¡mantenga los valores que se repiten en la pila!

El código sigue el mismo formato que todos los demás filtros que hemos visto antes, con una sutil excepción:

Aparte de eso, la rutina bcdload se ve atrapada en medio de un conflicto liliputiense entre los Big-Endians y los Little-Endians.

Está convirtiendo la representación textual de un número en ese número: el texto está almacenado en el orden big-endian, pero el decimal empaquetado es little-endian.

Para resolver el conflicto, usamos el código de operación std al principio. Lo cancelamos con cld más tarde: es bastante importante que no hagamos call a nada que pueda depender de la configuración por defecto del indicador de dirección mientras std esté activo.

Todo lo demás en este código debería quedar bastante claro, siempre que haya leído el artículo entero que lo precede.

Es un ejemplo clásico del dicho de que programar requiere mucho pensamiento y solo un poco de codificación. Una vez que hemos pensado detenidamente cada pequeño detalle, el código casi se escribe solo.

Como hemos decidido hacer que el programa ignore cualquier entrada excepto los números (e incluso esos dentro de un comentario), podemos de hecho realizar consultas textuales. No tenemos que hacerlo, pero podemos.

En mi humilde opinión, formular una consulta textual, en lugar de tener que seguir una sintaxis muy estricta, hace que el software sea mucho más amigable para el usuario.

Supongamos que queremos construir una cámara estenopeica para usar la película de 4x5 pulgadas. La distancia focal estándar para esa película es de unos 150mm. Queremos afinar nuestra distancia focal para que el diámetro del estenopo sea un número tan redondo como sea posible. Supongamos también que estamos bastante cómodos con las cámaras pero algo intimidados por los ordenadores. En lugar de tener simplemente que teclear un montón de números, queremos hacer un par de preguntas.

Nuestra sesión podría tener este aspecto:

Hemos descubierto que mientras que para la distancia focal de 150, nuestro diámetro de estenopo debería ser de 490 micras, o 0,49 mm, si optamos por la distancia focal casi idéntica de 156 mm, podemos arreglárnoslas con un diámetro de estenopo de exactamente medio milímetro.

Como hemos elegido el carácter # para denotar el comienzo de un comentario, podemos tratar nuestro software pinhole como un lenguaje de scripting.

Probablemente haya visto scripts de shell que comienzan con:

…​o…​

…​porque el espacio en blanco después del #! es opcional.

Siempre que se le pide a UNIX que ejecute un archivo ejecutable que comienza con #!, asume que el archivo es un script. Añade el comando al resto de la primera línea del script, e intenta ejecutar eso.

Supongamos ahora que hemos instalado pinhole en /usr/local/bin/, podemos ahora escribir un script para calcular diversos diámetros de estenopo adecuados para diversas distancias focales de uso común con la película de 120.

El script podría tener un aspecto parecido a este:

Como la 120 es una película de tamaño medio, podemos llamar a este archivo medium.

Podemos establecer sus permisos de ejecución, y ejecutarlo como si fuera un programa:

UNIX interpretará ese último comando como:

Ejecutará ese comando y mostrará:

Ahora, introduzcamos:

UNIX tratará eso como:

Eso le da dos opciones en conflicto: -b y -c (usar la constante de Bender y usar la constante de Connors). Lo hemos programado de forma que las opciones posteriores anulen las anteriores: nuestro programa calculará todo usando la constante de Connors:

Decidimos que, después de todo, queremos optar por la constante de Bender. Queremos guardar sus valores como un archivo separado por comas:

Por un lado, puede que simplemente no sea posible. UNIX se ejecuta en modo protegido. Solo el kernel y los controladores de dispositivos tienen permitido acceder al hardware directamente. Quizá un clon concreto de UNIX le permita leer los códigos de escaneo del teclado, pero lo más probable es que un sistema operativo UNIX real no lo haga. E incluso si una versión le permite hacerlo, puede que la siguiente no, de modo que su software cuidadosamente elaborado puede convertirse en un dinosaurio de la noche a la mañana.

Pero hay una razón mucho más importante para no intentar acceder al hardware directamente (a menos, por supuesto, que esté escribiendo un controlador de dispositivo), incluso en los sistemas similares a UNIX que le permiten hacerlo:

¡UNIX es una abstracción!

Hay una diferencia importante en la filosofía de diseño entre MS-DOS y UNIX. MS-DOS fue diseñado como un sistema monousuario. Se ejecuta en un ordenador con un teclado y una pantalla de vídeo conectados directamente a ese ordenador. Está casi garantizado que la entrada del usuario provenga de ese teclado. La salida de su programa prácticamente siempre acaba en esa pantalla.

Esto NUNCA está garantizado bajo UNIX. Es bastante común que un usuario de UNIX canalice y redirija la entrada y la salida de los programas:

Si usted ha escrito program2, su entrada no proviene del teclado sino de la salida de program1. De forma similar, su salida no va a la pantalla sino que se convierte en la entrada de program3 cuya salida, a su vez, va a file1.

¡Pero hay más! Incluso si se aseguró de que su entrada proviene del terminal, y su salida va al terminal, no hay garantía de que el terminal sea un PC: puede que no tenga su memoria de vídeo donde usted espera, ni que su teclado esté produciendo códigos de escaneo al estilo PC. Puede ser un Macintosh, o cualquier otro ordenador.

Ahora puede que esté negando con la cabeza: mi software está en lenguaje ensamblador de PC, ¿cómo puede ejecutarse en un Macintosh? Pero yo no dije que su software se estuviera ejecutando en un Macintosh, solo que su terminal puede ser un Macintosh.

Bajo UNIX, el terminal no tiene por qué estar conectado directamente al ordenador que ejecuta su software, puede incluso estar en otro continente, o, ya puestos, en otro planeta. Es perfectamente posible que un usuario de Macintosh en Australia se conecte a un sistema UNIX en Norteamérica (o en cualquier otro sitio) vía telnet. El software se ejecuta entonces en un ordenador, mientras que el terminal está en un ordenador diferente: ¡si intenta leer los códigos de escaneo, obtendrá la entrada equivocada!

Lo mismo vale para cualquier otro hardware: un archivo que está leyendo puede estar en un disco al que no tiene acceso directo. Una cámara de la que está leyendo imágenes puede estar en un transbordador espacial, conectada a usted vía satélites.

Por eso bajo UNIX nunca debe hacer ninguna suposición sobre de dónde vienen y a dónde van sus datos. Deje siempre que el sistema maneje el acceso físico al hardware.