Ensamblador - Portabilidad

Hola a todos. Me estoy iniciando en la programación en lenguaje ensamblador, por eso disculpar si la duda que tengo y os planteo os parece absurda, pero es que soy todavía un principiante.

He leído en multitud de publicaciones que una cosa incómoda que tiene la programación en ensamblador es que no es portable, es decir, solo funcionará con los mismos procesadores para los que se haya realizado la aplicación. En mi caso estoy aprendiendo con la familia de Intel x86.

Por otro lado he leído también que ese inconveniente no lo tienen los lenguajes de más alto nivel como C, C++, C#, Java, etc. Lo que parece ser que quieren decir es que son portables entre distintos procesadores, arquitecturas, sistemas operativos, etc. sin problema alguno.

Mi pregunta, y es lo que no entiendo, es la siguiente:

Si los lenguajes de más alto nivel al final también son traducidos al lenguaje máquina (como el caso del ensamblador que también es traducido a ceros y unos), ¿porque ellos si son portables entre distintos procesadores?. Cuando se compilan los programas hechos en esos leguajes de más alto nivel, ¿como sabe el compilador con que microprocesador se van a ejecutar para que puedan tener total compatibilidad?. ¿Cual es la explicación de esta aparente portabilidad universal de los lenguajes de alto nivel?.

Muchas gracias de antemano a todos los que podáis responder.

Un saludo a todos.

Hola.

Mientras utilices los comandos/mnemonicos "estandar", tus programas funcionaran en cualquier procesador.

En este caso, ejemplo, si dices que estas aprendiendo x86, no utilices los comandos de 3DNow (porque tus programas entonces solo funcionarian en AMD), ni utilices MMX (porque solo funcionarian en Intel).

Tienes que utilizar el conjunto de instrucciones "estandar".

En el caso de los compiladores que mencionas (por lo menos, para C# y Java), no es el compilador, es la maquina virtual (el "runtime"), el que traduce los comandos al conjunto de instrucciones soportadas por el procesador.

Ejemplo, puedes hacer tu programa en C#, y el runtime (.Net o Mono/Xamarin), lo traducira para ejecutarse en un procesador x86, o hasta en un ARM (para un celular).

Muchas gracias Cesar por responder con tanta rapidez. Igualmente te agradezco que me corrijas al confundir el compilador con la máquina virtual en los casos que has indicado.

Por otro lado, si la explicación es tan sencilla como usar el conjunto de instrucciones "estandar", ¿porque la gran mayoría de los programadores en lenguajes de mas alto nivel desaconsejan usar el lenguaje ensamblador fundamentalmente por la no portabilidad?. ¿Porque no decir que si es universalmente portable con tal de usar el conjunto de instrucciones "estandar"?.

Esto frustra un poco, la verdad. Aunque a mi no han conseguido desanimarme y seguiré con mis libros con la tarea de seguir aprendiendo ensamblador.

Muchas gracias por todo Cesar. Ahora lo cojo con más fuerzas si cabe.

Hola.

No se donde leiste eso de que ensamblador "no es portable", pero a mi parecer solo es un mito (por lo menos entre x86, si es portable).

Yo programe en ensamblador x86 hace un par de decadas, y te puedo asegurar que los escasos programas que aun conservo, siguen funcionando (incluso en procesador x64).

En mi experiencia profesional, se desaconseja el ensamblador por la complejidad del mismo (porque conlleva mas tiempo desarrollar en el), que por portabilidad.

Por otro lado, si se refieren a portabilidad entre arquitecturas de procesadores (x86, ARM, etc.), ahi si no es portable, y conviene uno de alto nivel.

Hola Cesar, pues perdona que te moleste de nuevo, pero vuelvo a la pregunta inicial.

Si los lenguajes de más alto nivel al final también son traducidos al lenguaje máquina (como el caso del ensamblador que también es traducido a ceros y unos), ¿porque ellos si son portables entre distintos procesadores (x86, ARM, etc.)?. Cuando se compilan los programas hechos en esos lenguajes de más alto nivel, ¿como sabe el compilador con que microprocesador se van a ejecutar para que puedan tener total compatibilidad?. ¿Cual es la explicación de esta aparente portabilidad universal de los lenguajes de alto nivel?.

Perdona que sea tan insistente.

Un saludo.

Estás confundiendo dos cosas. Una cosa es que un ejecutable sea portable y otra que lo sea un código fuente.

Si tienes un código fuente y lo compilas para un x86 sólo va a funcionarte en algo que entienda las instrucciones que utilices del x86.

Cuando se habla de la portabilidad de los lenguajes de alto nivel se entiende la portabilidad del fuente. Tú compilas un fuente en c en un Windows y funciona, lo compìlas en un Linux y funciona, lo compilas para un móvil con un Arm y funciona. Para eso necesitas un compilador que te compile un fuente para la plataforma que vaya a ser el destino del ejecutable. Hará un ejecutable con el set de instrucciones del procesador que sea y llamará las funciones del sistema operativo correspondientes a cada una.

Lenguajes de alto nivel como el c incluyen además un preprocesador, con el que puedes determinar mucho más las características de la plataforma en la que va a ejecutarse el programa antes de compilar. Según las directivas del preprocesador se incluye en el ejecutable una parte del código fuente u otra, dependiendo de cuál sea la apropiada para la plataforma de destino.

Muchas gracias Nacho por tu respuesta. Ahora creo que lo he entiendo. Voy a pensar en voz alta. La clave está entonces en que exista un compilador del lenguaje en el que esté trabajando, para cada procesador, sistema operativo, arquitectura o plataforma en la que vaya a ser usado el programa. Es decir, por cada lenguaje de programación de alto nivel habrá un compilador distinto (o uno con opciones de configuración) para cada procesador, sistema operativo, etc.

Me surge entonces otra pregunta. ¿Esta serie de compiladores son exclusivos para lenguajes de alto nivel?, es decir, ¿los lenguajes de bajo nivel, como el ensamblador, no disponen de esas herramientas?. Llámalo compilador o llámalo traductor de código de un procesador a otro procesador.

Si existen esas herramientas entonces el lenguaje ensamblador es tan portable (por medio del ejecutable que generará cada compilador en concreto) como los lenguajes de alto nivel, y si no existen esas herramientas ¿es porque nadie las ha desarrollado o es porque es imposible desarrollarlas?.

Muchas gracias.

Los lenguajes de bajo nivel no disponen de nada de eso. En teoría podría hacerse, pero tampoco tendría ninguna utilidad.

Si tú pones mul ebx, lo normal es que no haya ningún procesador que tenga un registro llamado ebx, y si da la casualidad de que lo tiene igual no se pueden hacer operaciones de multiplicación con él, y hasta puede que ese procesador no tenga operaciones de multiplicación, luego tendría que hacer otra cosa. Si hace otra cosa igual tiene que usar un registro que tienes tú ocupado en algo, con lo que tendría que ponerlo en memoria. Si lo metes en la pila te moverá el puntero y ya no apuntará a donde tú tenías previsto, y al final te saldrá una preciosa pantalla azul de Windows o verde de FreeBSD.

Y el valor del ensamblador es precisamente que puedes tener un control absoluto de lo que hace el procesador.

Cualquier compilador tiene opciones de compilación para aumentar el rendimiento un ejecutable. Puesto con todas las opciones para ello no consigues la misma velocidad ni de lejos que haciendo el programa en ensamblador. El sistema operativo Windows está hecho en c, pero hay partes que están hechas en ensamblador precisamente por eso.

Muchas gracias Nacho por tu respuesta.

Ya me voy aclarando.

Un saludo.

Estimados: me presento. Soy un aficionado a estos temas. Fui programador Basic en los 80. Hoy soy abogado, pero siempre me interesaron los temas relacionados con la seguridad informática y los lenguajes de bajo nivel. La pregunta realizada por Mario, relacionada con la portabilidad de los lenguajes de bajo nivel me lo vengo preguntando hace 30 años. Nunca encontré en la literatura española o inglesa una respuesta adecuada a este tema. Felicito a Mario por la insistencia y precisión en la pregunta. Lamentablemente creo que no se le ha respondido en forma precisa. Creo que contestar a la propuesta es realmente demostrar que se conoce a fondo y realmente el tema. A veces en lugar de responder se entra en disquisiciones que considero no conducentes. Lo digo con todo respeto. Conceptualmente no importa tanto si se trata de un compilador o el runtime o una "maquina virtual". Estas palabras esconden lo que hay por debajo. Volviendo al tema. Todos sabemos que el código maquina es 0 o 1. También sabemos que el ensamblador corresponde uno a uno al lenguaje de máquina usando nemotécnicos que lo hacen accesible al conocimiento humano. En muchos libros se descomponen las instrucciones simples de un lenguaje de alto nivel en varias instrucciones de ensamblador. Sentado lo anterior no queda claro: 1) Cómo hace el runtime o máquina virtual o compilador de alto nivel para identificar el tipo de procesador y traducir al lenguaje de máquina?. Más decisivo aún: 2) Por qué Java puede detectar en su runtime o compilador el procesador y traducir a máquina y no se puede hacer los mismo para el ensamblador.? 3) Por qué no hay un compilador universal para ensamblador y si los hay para los otros lenguajes?. También restaría responder 4) En qué lenguaje se programaron los runtimes de Java o Pyton?. 5) Por qué no hacer lo mismo para ensamblador?. En definitiva si para cada instrucción maquina hay una instrucción ensamblador pareciera que toda instrucción maquina seria reversible en ensamblador. Es decir que una vez que el compilador Java o el que sea codifica, podríamos revertir y obtener un código fuente para ensamblador. Para terminar: pareciera que perfectamente cada instrucción de Java o Pyton podrían descomponerse primero a una serie de instrucciones en ensamblador antes de pasar al código de máquina final. El atajo de decir que las instrucciones más simples de ensamblador son portables y las otras no, no responde científicamente al tema. Me gustaría saber por que Nacho escribe que "lo normal es que no haya ningún procesador que tenga un registro llamado ebx",? Gracias y disculpen la lata. El tema me apasiona.