Siguiente: GNU as como ensamblador Superior: GNU as como ensamblador Anterior: El lenguaje de ensamblado

¿Por qué GNU as?

Seamos realistas: quizá el NASM sea más cómodo de utilizar con su sintaxis Intel que el GNU as. Quizá su soporte de macros pudiere ser mejor, quizá su nombre es más bonito... Pero si desarrollamos sólo parte de nuestro código en ensamble, mezclándolo con algún lenguaje de alto nivel, entonces usar un ensamblador como ese es practicamente inviable. En Linux los ejecutables tienen formato ELF, así que si generamos código objeto con el NASM o similares, tendremos que construirnos un objeto en formato ELF con el objeto generado por el NASM. Parece que en versiones recientes de NASM ya se pueden generar directamente objetos ELF.

Esto no es una tarea trivial, y obliga a conocer la estructura de un ELF para poder hacerlo. Afortunadamente en Linux contamos con binutils, que nos permite hacer este tipo de operaciones. De todas formas no es sencillo.

Además, resulta que nuestro compilador GNU cc soporta ensamble empotrado, así que decidimos que para algunos códigos muy pequeños no resulta rentable desarrollar el código con NASM y preferimos empotrarlo: mala idea; el ensamble empotrado del GNU cc tiene sintaxis AT&T...

Llegados a este punto tenemos varias alternativas:

• Desarrollar completamente en ensamble con NASM y luego integrar el código en el resto del programa con binutils y mucha maña.
• Desarrollar completamente con ensamble empotrado, olvidar la sintaxis Intel y pasarse a la AT&T
• No desarrollar y dedicarnos a la pastelería, profesión que ofrece perspectivas más que interesantes a un programador.

Me temo que si no se nos dan bien las artes culinarias debemos escoger entre las dos primeras opciones. Sin querer hacer publicidad engañosa creo que la más inteligente es la segunda: si vamos a usar ensamble junto a lenguajes de alto nivel pronto descubriremos que resulta más práctico empotrarlo, porque rara vez nos surgirá la necesidad de hacerlo de otra forma. Es más, puesto que ya aprendemos sintaxis AT&T nos deja la puerta abierta para usar el GNU as.

El GNU as genera código en distintos formatos, según esté configurado. En ese aspecto es igual que el resto de herramientas de desarrollo de GNU. Esto lo hace particularmente útil, ya que el código objeto que genera puede ser usado directamente: ya estará en el mismo formato que el resto de los códigos objeto.

Pero esta ventaja se convierte en una contrariedad cuando queremos generar con el GNU as código binario sin formato. Veremos que esto resulta infinitamente más simple que hacer lo contrario (coger código generado por NASM y convertirlo a formato ELF, por ejemplo).

Otra ventaja que podemos destacar del GNU as es que genera código en 16 y 32 bits (hablamos de bits de direccionamiento de memoria), en varios modos y en multitud de arquitecturas. Es practicamente el único ensamblador capaz de esto, y es sin duda un punto a su favor, pese a que al final el lenguaje de ensamble es practicamente no portable.

En resumen: todas las opciones tienen sus ventajas e inconvenientes, y hay que valorar éstos a la hora de elegir una alternativa. Por lo general, si desarrollamos mucho código que deba ejecutarse en modo real o virtual86 es mejor usar una herramienta como el NASM, aunque ya veremos que también el GNU as puede ser usado para ello. Por el contrario, si lo que hacemos de forma habitual es escribir en un lenguaje de alto nivel con partes escritas en ensamble, lo nuestro es la sintaxis AT&T, el ensamble empotrado y el GNU as.