El propósito de este texto es proporcionar una referencia para el lenguaje ensamblador de nivel universitario y los cursos de programación de sistemas. Este texto aborda el conjunto de instrucciones x86-64 para la popular clase de procesadores x86-64 que utilizan el sistema operativo Ubuntu de 64 bits. Si bien el código proporcionado y varios ejemplos deberían funcionar bajo cualquier sistema operativo de 64 bits basado en Linux, solo se han probado bajo Ubuntu 14/16/18 LTS (64 bits).
Comentarios
Gracias por el envío.
Me acuerdo de mi proyecto fin de curso en ensamblador en el 96. Hice el Tetris, con sonido por el altavoz del pc, jostick, modo gráfico x, editor de niveles, y cada vez que pasabas de nivel aparecía una tía en tetas. Además usaba el reloj de sistema para que fuese a la misma velocidad en todos los pc. Que no le metí horas.
#6 Tetas? Vaya tela, qué pensarían de tí tus compañeras de clase en el 96!! Y tus profesoras? En fin...
#18 En el 96, profesoras pocas, y compañeras menos.
#26 Ya ya, por eso he remarcado lo del '96.
#26 ninguna profesora, y solo una compañera, que estaba curada de espanto, siempre rodeada de tíos.
#6 Y aprendiste lo que es el retrazado vertical en el CPV.
#6 Usaste el PIT(programable interval timer), y modo x? supongo que te referirás a cualquier modo grafico de la VGA modo 13 320x200 tal vez, por que usar el modo X de la vga con 320x240 con sus 4 buffers y demas que faenon te metiste.
#40 exacto, dibujaba en la pantalla siguiente y luego la visualizaba, así no había efecto arrastre al mover las fichas.
#8 mi cuñado en la cena de Navidad.
#12 Igual te lo has tomado mal, pero la pregunta era seria. La razón por la que lo pregunto es: me dedico a optimización de codigo numérico desde hace +/- 12 años, y sí que es verdad que el compilador hace, en términos generales, un buen trabajo de optimización. Por otro lado, tambien es verdad que si conoces la arquitectura de tu procesador, de tu sistema, y inviertes algo de tiempo, puedes hacer un mejor trabajo (llegar al 90% de rendimiento máximo para la carga de trabajo en cuestión debería ser posible con una inversión de tiempo razonable). Conclusión: conoce tu arquitectura y, para los kernels de calculo, mejor escribe a bajo nivel (intrínsecas y demás) y sacarás bastante mas rendimiento a tu maquina.
#14 por supuesto, y como he dicho dependiendo del procesador puede haber casos en los que es interesante hacer cosas en ensamblador.
No estoy en contra de su aprendizaje, siempre es importante conocer cómo funciona un procesador y lo que está haciendo tu compilador si haces cosas a bajo nivel, simplemente creo que en la mayoría de entornos (especialmente si trabajas en arm o x86) no es necesario ni recomendable su uso.
#14 Llevo 20 años sin tocar ASM, pero en mis días cuando hice programación gráfica, había muchos trucos, recuerdo uno en concreto que decía que para asignar valor 0 a un registro era mas rápido hacer un xor ax, ax que un mov ax, 0. Y digo recuerdo por que supongo que la mayoría de trucos que servían en aquella época hoy no tendrán mucho sentido. Conociendo las entrañas de la CPU puedes hacer muchas micro-optimizaciones.
Diferencia abismal había entre hacer tu propia implementación del algoritmo de Bresenham y ver luego como los maestros de la demoscene hacían lo mismo mil veces mas rápido.
#41 los compiladores, hoy en dia, hacen ese xor El problema de las optimizaciones es que tienes que tener claro el tiempo que vas a invertir en ellas, y si merece la pena. Es mas importante hacer un buen analisis, que una buena optimización (creo yo).
#42 Supongo que hoy en día los compiladores harán virguerias, te hablo de hace 20 años o mas, cuando la única información eran revistas "marginales", el drjobs journal(via disketes) y las bbs. Como todo hay que ver si merece la pena, en el mundo gráfico consigues arañar unos milisegundos a una función aveces se traduce en un incremento sustancial en los frames por segundo y acaba valiendo la pena.
#7 O igual te dedicas al desarrollo de compiladores y tienes que saber cómo funciona tu procesador de destino al dedillo.
Pero se me ocurren más cosas: por ejemplo, programando a alto nivel, si no sabes cómo funciona tu procesador y, sobre todo, la caché del mismo, puedes hacer cagadas tan gordas (insisto: incluso en lenguajes de alto nivel) como invalidar la caché en cada lectura a memoria sin que te des cuenta (y sin que sepas por qué).
Luego #41 también te da alguna noción más (gracias).
/cc #8
#13 Jajaja te puedo entender, pero eso no quita de que a fin de cuentas estas dejando en un proceso automático la responsabilidad de traducir correctamente las instrucciones de tu programa. No digo de usar ensamblador, mas bien que hay que tener en cuenta cada vez que se compila un programa lo que se hace, que a mucha gente en la facultad prácticamente le dijeron que eso es magia negra y luego pueden venir sorpresas. Por lo demás, totalmente de acuerdo, salvo quizá en el porcentaje que mencionas
#15 ya sabes, el 80% de las estadísticas son inventadas
Como he dicho en otro comentario, no estoy en contra de aprender ensamblador, y es interesante saber lo que está haciendo tu compilador, pero hoy en día su uso debería reducirse a muy contadas situaciones (por supuesto IMHO).
#8 Yo me dedico a esto. Y tiene razón.
Mejor preocúpate de escribir código limpio, que cosas como el desenrollado de bucles ya las puede hacer el compilador y si las haces a mano son feas, inmantenibles y para colmo hay que hacerlas adaptadas a cada máquina.
Si tú escribes un for (i=0; i
#23 Luego están los que programan compiladores
#27 Yep. Goto #29
#27 aunque no lo creas, los compiladores suelen estar compilados con los compiladores
De hecho el primer compilador de C, se compiló con B.
#34 Sí, pero las optimizaciones para cada procesador no las programa el compilador
#34 pero el lenguaje de salida es?
Que queda después de pasar el linker?
He programado un compilador de Pascal "de juguete" escrito en Python que daba como salida z80 ASM. Al final hay assembler.
#23 Lo que dices es cierto, pero la palabra mágica es "heuristica": el compilador va a decidir qué hacer, en muchos casos, a partir de algunas métricas de coste y del conocimiento que tenian los tipos que hicieron el compilador en ese momento (de la misma manera que igual no te desarrolla el bucle porque el cuerpo usa demasiados datos y no cabe en cache). Lo suyo es escribir codigo limpio, sin optimizar, y ver qué hace el compilador (sacar unas metricas de roofline, de IPC, etc.) y, en función de eso, meter mano donde sea necesario.
El compilador hacer un buen trabajo en términos generales, pero si quieres qué el código vaya a toda pastilla con el procesador que tienes a mano, del que tienes un cluster, y en el que tu empresa se ha gastado una pasta (típico caso de empresas "grandes", tipo aeronauticas, oil & gas, finanzas) en las que hay un conjunto de aplicaciones en las que un número reducido de kernels se comen el 80% del tiempo... El código va a quedar "sucio", la mayor parte de las veces porque el compilador es bueno en términos generales, pero no necesariamente en términos específicos.
#28 Totalmente de acuerdo.
#28 Bueno, yo tengo una regla: haz el código como si tu sucesor fuera un psicópata que sabe donde vives.
Y un código sucio probablemente también sea sucio en bugs difíciles de encontrar.
#35 Claro, por eso se empieza con un codigo limpio... y se ensucia al optimizarlo despues de hacerle un analisis.
Ensamblador rulez. Los viejos rockeros nunca mueren.
#2 en el año 2018 salvo que uses procesadores raros, el compilador va a hacer un mejor trabajo de optimización que cualquier programador...
#7 Hablas así porque te dedicas a esto, o porque te lo ha contado alguien?
#7 Discrepo. Lo hará más rápido, pero no mejor y mucho menos que cualquier programador. Luego vienen los lloros porque los que si saben leer ensamblador tienen un exploit para alguna vulnerabilidad introducida por algún compilador.
#11 efectivamente, no que cualquier programador. Pero los que pueden hacer un trabajo mejor que el compilador son tan, tan pocos, que en el 99,9% de los casos el resultado va a ser una aberración. Yo personalmente me incluyo en ese 99%, y estoy cansado de arreglar chapuzas que algún genio decidió hacer en ensamblador que ni son rápidas ni son mantenibiles.
#13 Si un programador es capaz de escribir código más rápido que un compilador, para todas las plataformas, lo razonable en el 99% de los casos es que se dedique a escribir compiladores.
El 1% restante es ese código crítico que en aplicaciones intensivas en el uso de la CPU, y tras un buen profiling, ha demostrado ser lento y consumir una buena parte de los ciclos de la CPU. Esto sólo pasa en cosas como el kérnel de un SO, compresores de vídeo, librerías matemáticas, etc, pero no en código normal y corriente.
#11 Un compilador no sólo es capaz de optimizar el código, también es capaz de realizar un montón de comprobaciones, por ejemplo fsanitize para direcciones de memoria y leaks. Gcc tiene un montón de flags para hacerlo más o menos estricto.
Código seguro en ensamblador, ¿estamos locos?
Un muy buen envío.
Muchas gracias!!!
#9 Menéame debería tener una portada hecha de subs configurables, como Reddit. Por defecto sysdevs no aparecería en las suscripciones básicas, y así nos ahorraríamos el problema de que una noticia de un sub raro llegue a portada y la crujan.
Por que los votos negativos? No comprendo.
#3 Son programadores de Visual Basic.
Esto es para hombres y con el culo mu pelao de tanta silla. Yo me voy.
Una guía muy completa. En su día aprendí algo de ensamblador solo para crackear algún programa en la época de Astalavista.
Me parece una descusión bastante acertada, yo pienso igual #flixter, aunque creo que muchos prefieren compilador por rapidez
¿Esto qué es?. ¿Menéame o prográmame?. Irrelevante
Lo dice un informático
#4 Mira en qué sub está, que haya llegado a portada en la general es casi accidental
#5 Si si, que me parece correcto, pero a mi me interesan que lleguen a portada noticias, temas, etc que en mi opinión resultan interesantes o distintas y que pueda entender todo el mundo. Esto es algo muy concreto que poca gente va a entender. El tema es que soy consciente que aquí hay mucho nformático y yo respeto que la gente lo menee. Pero a su vez también tengo mi derecho a votar negativo
#4 En portada la verdad me parece que no pega mucho. Salvo que sea algo muy bueno (habría que verlo).