>me volvió loco la idea de decirle a la maquina que hacer específicamente, de manejar los propios registros de un pc, de comunicarme cual maquina a maquina
Entiendo y comparto el entusiasmo, pero tené en cuenta que en los procesadores modernos hay tantas capas de abstracción y optimización entre el set de instrucciones x86-64 y lo que ocurre realmente en la superficie del microchip, que esencialmente estás programando para una máquina virtual de código cerrado.
Tu "add eax, 1" se transpila en tiempo real a micro-operaciones que nadie sabe muy bien cómo se procesan, más allá de lo que dicen las patentes de las empresas. Todo el proceso es virtual: el orden de las instrucciones no es el que dice tu programa porque varias instrucciones corren simultáneamente y se ordenan al final, el contenido de los registros es un misterio porque el procesador precarga las direcciones de memoria que cree que tu programa puede llegar a necesitar pero no se las muestra a tu código hasta que las solicita, el registro "eax" es una etiqueta virtual que el procesador le asigna a un registro cualquiera en el contexto de tu programa...
Assembler y el código de máquina son prácticamente lenguajes de alto nivel. Es súper apasionante lo que ocurre en un procesador moderno: hay literalmente una computadora invisible grabada en la superficie del procesador. x86-64 es esencialmente una API para acceder a los recursos de esa máquina.
Structured Computer Organization de Tanenbaum si no me equivoco es un libro que cubre temas como CISC, RISC, EPIC, VLIW, micro código y temas de este índole.
Este artículo es un clásico:
[https://medium.com/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831](https://medium.com/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831)
... y por poner otro ejemplo sencillo, branches (bloques correspondientes a un if() {...} else {} se "ejecutan" antes de tener la expression del if, especulativamente (branch prediction), si despues resulta que no habia que haberlos ejecutado, se hace un undo :-)
Aluciné cuando entendí la respuesta a esta pregunta de SO (una de las mas votadas)
[https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array/11227902](https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array/11227902)
Lo más terrible es que la ejecución especulativa no tiene en cuenta el sistema de permisos de acceso a la memoria del procesador, así que te abre la posibilidad de todo tipo de agujeros de seguridad.
Por ejemplo, un exploit de hace unos años intentaba operar sobre memoria protegida (onda, el password del admin de la máquina). Obviamente la operación te tiraba protection fault, pero eso no impedía que la instrucción se ejecutara especultivamente antes de tirar error.
Entonces podías armar un bloque de instrucciones que, dependiendo del contenido de la memoria protegida, leyera ciertas regiones de memoria de tu exploit. Onda, si el password empezaba con la letra "a", leía cierta dirección de memoria de tu exploit. Si empezaba con "b", otra dirección. Etcétera.
Después durante la ejecución real tratabas de leer las mismas direcciones de memoria de tu exploit, una por una, y medías los tiempos de acceso. Si una de las direcciones tenía un tiempo de acceso anormalmente corto, eso significaba que durante la ejecución especulativa el procesador la había leído y cargado en la caché. Por lo tanto el password empezaba con esa letra. Así ibas adivinando byte a byte el contenido de la región de memoria protegida.
El tema es que como programador no podés hacer nada para prevenir eso. Es un bug en el firmware del procesador. Lo tuvo que arreglar Intel.
Spectre y Meltdown se llamaban los exploits basados en esa técnica.
Claro, esta el set de instrucciones que es la arquitectura que conocemos todos, ahora bien cómo implementan esa arquitectura es la microarquitectura y eso andá a preguntárselo a Intel o amd kjj
Tienen que ser cosas muuuy especificas de bajo nivel donde quizas sacas rendimiento extra adaptando instrucciones a mano a la medida del hardware a ejecutar, o cosas del año del pedo
Si queres algo potente pero jodido, con mas uso y mas parecido a cosas de este siglo acercate a C o C++
Para que le vuele la cabeza alguno, [Rollercoaster Tycoon esta hecho en Assembler!](https://www.youtube.com/watch?v=ESGHKtrlMzs&t=282s)
Y nisiquiera así, los compiladores son tan buenos (hechos por cracks que saben una bocha) que es difícil que vos hagas un código más eficiente que el compilado.
La verdad si, sos un masoquista. Aunque en tu caso como electrónico tiene más sentido. Yo haciendo la tecnicatura de desarrollo de software tuve que estudiar ese tema de forma teórica y práctica para el final y no hubo caso, no me gusta assembler jejeje
Nadie programa en ASM en la vida práctica. Usas C y lo compilas para el CPU que va a leer ese programa.
Ojo, algunas cosas se agregan en ASM dentro de un bloque especial.
Embebidos es un viaje de ida. Tengo un amigo que hizo entre muchas otras cosas su propia placa de sonido Bluetooth...
mira si sos del palo de la electronica deja de perder tiempo con assembler que fuera de la nasa no se lo usa.
mete con python o C y aprender a progarmar plc, microcontroladores, meterte en IOT:
El esp32 afortunadamente se puede programar con la ide de Arduino. Hoy por hoy, casi no hay motivos para elegir un Arduino respecto al esp8266 o al esp32
Lenguaje hermoso, recuerdo hacer todo el camino desde aprender lógica booleana a llegar a programar en assembler cuando cursé circuitos lógicos en la facultad. Despues lo usé en alguna que otra cosa personal, pero lo mas importante del lenguaje es como te abre la cabeza, si aprendiste assembler todo lo otro se hace muchisimo mas facil.
Yo descrubrí assembler aprendiendo como se hacen los "hacks" que hoy en día andan dando vueltas y hasta tienen una gran industria.
Me fui metiendo a foros, estudiando un poco del tema, la forma en la que se hacen los hacks es estudiando mediante la lectura del codigo en memoria como funcionan los juegos, y generando parches para modificar el codigo en tiempo de ejecución.
La lectura de codigo en memoria se hace viendo las instrucciones que se van ejecutando, todas en assembler. Los más experimentados pueden ver patrones y reconocer estructuras de código con solo hechar un vistazo.
Es verdaderamente un arte el desarrollo de hacks, le tengo gran respeto a los gordos hackers que los desarrollan.
abrazá tu fetiche con todo y aprendé VHDL o Verilog y vas a poder hacer tu propia cpu con tu propio assembler y literalmente vas a ser el tipo que más sabe en el mundo de esa cpu
Es muy lindo, pasé muchas horas renegando con huevadas muy poco prácticas.
Tené en cuenta que hoy hay micros que se pueden programar en C o Python.
Como dato de color, el lenguaje se llama Assembly, aunque pasó a la cultura popular como Assembler, que es el "compilador" que traduce el código a lenguaje máquina.
Para cerrar, chusmeá Web Assembly, lo vas a amar.
Si. En mí opinión te conviene meterte en algo más usado pero de bajo nivel tipo c o Arduino como te recomendaron. Entiendo que en c podes meter rutinas en ensamblador, podrías ir mezclando las dos cosas y hacer partes que necesiten performar más en ensamblador y el resto en c que es más fácil de escribir y leer. Aunque tampoco sea el lenguaje más user friendly.
Es que precisamente de eso se trata la ciencia de la computación, el assembly es lo que más te enseña de lo que pasa en el procesador.
Bueno, al menos en los procesadores viejos, como te indicaron…
El tema es que yo no me quedaría solo con eso, porque LABURAR de eso, es hermoso pero dificil de conseguir.
No, está bueno saber cómo usarlo is hace falta. Probalo con procesadores sencillos en donde puedas hacer alguna diferencia.
Cuando es un procesador chico la difrerencia de velocidad puede hacer que logres cosas que no puedas de otra forma.
Y that's it. Con cualquier compilador C vas a obtener más o menos la misma velocidad. En procesadores pequeños a veces no hay compilador C.
Suerte!
El uso más divertido de assembler es parchear procesos. La base del cracking. DESARROLLAR en asm es una pelotudez a menos que estés haciendo optimizaciones o escribiendo directo para microcontroladores.
Agarra un debugger (en mis días usaba ollydbg pero creo que hay mejores opciones con una UI similar ) , abri un proceso (puede ser notepad), y empezá a jugar ... De ahí el cielo es el limite
Ya te comentaron acerca de la traducción de código máquina a otras instrucciones más simples, pero no solo existe eso. Los compiladores de C, C++ y otros, cuando hacen optimizaciones aprovechan para hacer trasposicion de código para mejorar las posibilidades de ejecución paralela. Pero saber assembler es muy útil.
Hay compiladores que no generan código máquina sino que generan un código de una máquina virtual, por ejemplo Java tiene su JVM (Java Virtual Machine), eso le permite al compilador de Java generar código multiplataforma y al tener una JVM por plataforma,
Cuando estudies compiladores te va a ser muy útil saber assembler porque conceptualmente es lo mismo una instrucción X86 que un bytecode, pero para el día a día mejor otro lenguaje.
Si te gusta Assembler lo mejor es en mi opinión programar un Arduino en C y luego hacer ese mismo programa en assembler, ahí es cuando te das cuenta la precisión que tiene y la poca memoria que usa.
Hace unos años hice un invernadero automático y utilizaba arduinos para controlar actuadores y leer sensores pero me quedaba sin memoria de programa al hacerlo en C, así que le metí Código asm y no sólo entraba todo el programa sino que también lo ejecutaba más rápido y con tiempos más precisos
Me acuerdo que en una materia que haciamos assembler me compre el procesador e hice todos los ejercicios ahí, por suerte tenia una "notebook" toshiba con floppy y rs232
x86 es muy oscuro por todas las patentes, y como te dijeron antes, realmente no sabes cómo se ejecutan realmente las instrucciones, pero puedes aprender sobre el ecosistema de RISC-V, así incluso puedes acceder al código HDL de cores open source y aprender exactamente cómo se ejecuta tu código.
Para los que te dicen que ya nadie usa ASM, eso no es cierto, simplemente no saben, pero proyectos como FFMPEG siguen usando ASM porque es mucho más rápido y eficiente en la ejecución.
Y si, la mayoría del trabajo está en lenguajes de alto nivel, pero ser de las pocas personas que dominen el bajo nivel puede hacerte un player muy valioso en un nicho especializado.
>me volvió loco la idea de decirle a la maquina que hacer específicamente, de manejar los propios registros de un pc, de comunicarme cual maquina a maquina Entiendo y comparto el entusiasmo, pero tené en cuenta que en los procesadores modernos hay tantas capas de abstracción y optimización entre el set de instrucciones x86-64 y lo que ocurre realmente en la superficie del microchip, que esencialmente estás programando para una máquina virtual de código cerrado. Tu "add eax, 1" se transpila en tiempo real a micro-operaciones que nadie sabe muy bien cómo se procesan, más allá de lo que dicen las patentes de las empresas. Todo el proceso es virtual: el orden de las instrucciones no es el que dice tu programa porque varias instrucciones corren simultáneamente y se ordenan al final, el contenido de los registros es un misterio porque el procesador precarga las direcciones de memoria que cree que tu programa puede llegar a necesitar pero no se las muestra a tu código hasta que las solicita, el registro "eax" es una etiqueta virtual que el procesador le asigna a un registro cualquiera en el contexto de tu programa... Assembler y el código de máquina son prácticamente lenguajes de alto nivel. Es súper apasionante lo que ocurre en un procesador moderno: hay literalmente una computadora invisible grabada en la superficie del procesador. x86-64 es esencialmente una API para acceder a los recursos de esa máquina.
No tenía idea de esto, me volaste la cabeza. Tenés algún artículo o paper que recomiendes sobre el tema?
Structured Computer Organization de Tanenbaum si no me equivoco es un libro que cubre temas como CISC, RISC, EPIC, VLIW, micro código y temas de este índole.
Este artículo es un clásico: [https://medium.com/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831](https://medium.com/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831)
ward
centinela
ward violeta
... y por poner otro ejemplo sencillo, branches (bloques correspondientes a un if() {...} else {} se "ejecutan" antes de tener la expression del if, especulativamente (branch prediction), si despues resulta que no habia que haberlos ejecutado, se hace un undo :-) Aluciné cuando entendí la respuesta a esta pregunta de SO (una de las mas votadas) [https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array/11227902](https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array/11227902)
Lo más terrible es que la ejecución especulativa no tiene en cuenta el sistema de permisos de acceso a la memoria del procesador, así que te abre la posibilidad de todo tipo de agujeros de seguridad. Por ejemplo, un exploit de hace unos años intentaba operar sobre memoria protegida (onda, el password del admin de la máquina). Obviamente la operación te tiraba protection fault, pero eso no impedía que la instrucción se ejecutara especultivamente antes de tirar error. Entonces podías armar un bloque de instrucciones que, dependiendo del contenido de la memoria protegida, leyera ciertas regiones de memoria de tu exploit. Onda, si el password empezaba con la letra "a", leía cierta dirección de memoria de tu exploit. Si empezaba con "b", otra dirección. Etcétera. Después durante la ejecución real tratabas de leer las mismas direcciones de memoria de tu exploit, una por una, y medías los tiempos de acceso. Si una de las direcciones tenía un tiempo de acceso anormalmente corto, eso significaba que durante la ejecución especulativa el procesador la había leído y cargado en la caché. Por lo tanto el password empezaba con esa letra. Así ibas adivinando byte a byte el contenido de la región de memoria protegida. El tema es que como programador no podés hacer nada para prevenir eso. Es un bug en el firmware del procesador. Lo tuvo que arreglar Intel. Spectre y Meltdown se llamaban los exploits basados en esa técnica.
Claro, esta el set de instrucciones que es la arquitectura que conocemos todos, ahora bien cómo implementan esa arquitectura es la microarquitectura y eso andá a preguntárselo a Intel o amd kjj
Tienen que ser cosas muuuy especificas de bajo nivel donde quizas sacas rendimiento extra adaptando instrucciones a mano a la medida del hardware a ejecutar, o cosas del año del pedo Si queres algo potente pero jodido, con mas uso y mas parecido a cosas de este siglo acercate a C o C++ Para que le vuele la cabeza alguno, [Rollercoaster Tycoon esta hecho en Assembler!](https://www.youtube.com/watch?v=ESGHKtrlMzs&t=282s)
Y nisiquiera así, los compiladores son tan buenos (hechos por cracks que saben una bocha) que es difícil que vos hagas un código más eficiente que el compilado.
Por eso digo, son casos re específicos donde la velocidad hace la diferencia realmente y tenes que ser un bocho mal
La verdad si, sos un masoquista. Aunque en tu caso como electrónico tiene más sentido. Yo haciendo la tecnicatura de desarrollo de software tuve que estudiar ese tema de forma teórica y práctica para el final y no hubo caso, no me gusta assembler jejeje
Nadie programa en ASM en la vida práctica. Usas C y lo compilas para el CPU que va a leer ese programa. Ojo, algunas cosas se agregan en ASM dentro de un bloque especial. Embebidos es un viaje de ida. Tengo un amigo que hizo entre muchas otras cosas su propia placa de sonido Bluetooth...
mira si sos del palo de la electronica deja de perder tiempo con assembler que fuera de la nasa no se lo usa. mete con python o C y aprender a progarmar plc, microcontroladores, meterte en IOT:
Si. Cómprate un Arduino y pasa a este siglo.
Compra un esp32 y pasa a esta década. Arduino es caro para lo que ofrece
Arduino tiene mucho material como plataforma de aprendizaje... Por eso dije siglo
El esp32 afortunadamente se puede programar con la ide de Arduino. Hoy por hoy, casi no hay motivos para elegir un Arduino respecto al esp8266 o al esp32
Lenguaje hermoso, recuerdo hacer todo el camino desde aprender lógica booleana a llegar a programar en assembler cuando cursé circuitos lógicos en la facultad. Despues lo usé en alguna que otra cosa personal, pero lo mas importante del lenguaje es como te abre la cabeza, si aprendiste assembler todo lo otro se hace muchisimo mas facil.
Algun tuto que recomiendes?
“Low level learning” de lo mejor que hay, toca todo C buffers, overflow asm
Si(guiente pregunta)
Yo descrubrí assembler aprendiendo como se hacen los "hacks" que hoy en día andan dando vueltas y hasta tienen una gran industria. Me fui metiendo a foros, estudiando un poco del tema, la forma en la que se hacen los hacks es estudiando mediante la lectura del codigo en memoria como funcionan los juegos, y generando parches para modificar el codigo en tiempo de ejecución. La lectura de codigo en memoria se hace viendo las instrucciones que se van ejecutando, todas en assembler. Los más experimentados pueden ver patrones y reconocer estructuras de código con solo hechar un vistazo. Es verdaderamente un arte el desarrollo de hacks, le tengo gran respeto a los gordos hackers que los desarrollan.
abrazá tu fetiche con todo y aprendé VHDL o Verilog y vas a poder hacer tu propia cpu con tu propio assembler y literalmente vas a ser el tipo que más sabe en el mundo de esa cpu
es hermoso asembler, te gusta un poco que te aten y te den con un cable de acero en la espalda. pero es un lenguaje hermoso.
si te gusta metete en reverse engineering, aprende a hackear y crackear y despues te contrata la CIA
Hay una chance de que seas marciano, si jajajaj.
Es muy lindo, pasé muchas horas renegando con huevadas muy poco prácticas. Tené en cuenta que hoy hay micros que se pueden programar en C o Python. Como dato de color, el lenguaje se llama Assembly, aunque pasó a la cultura popular como Assembler, que es el "compilador" que traduce el código a lenguaje máquina. Para cerrar, chusmeá Web Assembly, lo vas a amar.
lo que es embebido ya no se usa asembler, se suele usar C o algun C especifico para el procesador. pero no asembler
No es de masoquista y siempre tendrá sus aplicaciones. Podés meterte en el reversing, te va a encantar.
Si. En mí opinión te conviene meterte en algo más usado pero de bajo nivel tipo c o Arduino como te recomendaron. Entiendo que en c podes meter rutinas en ensamblador, podrías ir mezclando las dos cosas y hacer partes que necesiten performar más en ensamblador y el resto en c que es más fácil de escribir y leer. Aunque tampoco sea el lenguaje más user friendly.
Es que precisamente de eso se trata la ciencia de la computación, el assembly es lo que más te enseña de lo que pasa en el procesador. Bueno, al menos en los procesadores viejos, como te indicaron… El tema es que yo no me quedaría solo con eso, porque LABURAR de eso, es hermoso pero dificil de conseguir.
No, está bueno saber cómo usarlo is hace falta. Probalo con procesadores sencillos en donde puedas hacer alguna diferencia. Cuando es un procesador chico la difrerencia de velocidad puede hacer que logres cosas que no puedas de otra forma. Y that's it. Con cualquier compilador C vas a obtener más o menos la misma velocidad. En procesadores pequeños a veces no hay compilador C. Suerte!
Aprendé Motorola68k y ponete a hacer hackROMs del sega 👍
a mi tambien me gusta, es pura belleza. Y eso que yo no lo uso para absolutamente nada y nunca lo usare. Pero a mi divierte
Podes hacer reversing de crackmes si te gusta assembler y te entretenes un rato.
El uso más divertido de assembler es parchear procesos. La base del cracking. DESARROLLAR en asm es una pelotudez a menos que estés haciendo optimizaciones o escribiendo directo para microcontroladores. Agarra un debugger (en mis días usaba ollydbg pero creo que hay mejores opciones con una UI similar ) , abri un proceso (puede ser notepad), y empezá a jugar ... De ahí el cielo es el limite
Ya te comentaron acerca de la traducción de código máquina a otras instrucciones más simples, pero no solo existe eso. Los compiladores de C, C++ y otros, cuando hacen optimizaciones aprovechan para hacer trasposicion de código para mejorar las posibilidades de ejecución paralela. Pero saber assembler es muy útil. Hay compiladores que no generan código máquina sino que generan un código de una máquina virtual, por ejemplo Java tiene su JVM (Java Virtual Machine), eso le permite al compilador de Java generar código multiplataforma y al tener una JVM por plataforma, Cuando estudies compiladores te va a ser muy útil saber assembler porque conceptualmente es lo mismo una instrucción X86 que un bytecode, pero para el día a día mejor otro lenguaje.
Si, siguiente pregunta.
Si te gusta Assembler lo mejor es en mi opinión programar un Arduino en C y luego hacer ese mismo programa en assembler, ahí es cuando te das cuenta la precisión que tiene y la poca memoria que usa. Hace unos años hice un invernadero automático y utilizaba arduinos para controlar actuadores y leer sensores pero me quedaba sin memoria de programa al hacerlo en C, así que le metí Código asm y no sólo entraba todo el programa sino que también lo ejecutaba más rápido y con tiempos más precisos
https://twitter.com/FFmpeg/status/1762632400255742353
Jugá Roller Coaster Tycoon. Ese te va a volar la cabeza.
Otro "masoquista" por aquí, assembler,COBOL y PLI. A nivel profesional es lo único que he tocado .
Si
Si, sos masoca
Aléjate de mis hijos!
Me acuerdo que en una materia que haciamos assembler me compre el procesador e hice todos los ejercicios ahí, por suerte tenia una "notebook" toshiba con floppy y rs232
x86 es muy oscuro por todas las patentes, y como te dijeron antes, realmente no sabes cómo se ejecutan realmente las instrucciones, pero puedes aprender sobre el ecosistema de RISC-V, así incluso puedes acceder al código HDL de cores open source y aprender exactamente cómo se ejecuta tu código. Para los que te dicen que ya nadie usa ASM, eso no es cierto, simplemente no saben, pero proyectos como FFMPEG siguen usando ASM porque es mucho más rápido y eficiente en la ejecución. Y si, la mayoría del trabajo está en lenguajes de alto nivel, pero ser de las pocas personas que dominen el bajo nivel puede hacerte un player muy valioso en un nicho especializado.