JavaRush /Blog Java /Random-ES /Código de máquina y código de bytes: ¿qué idioma habla su...

Código de máquina y código de bytes: ¿qué idioma habla su programa?

Publicado en el grupo Random-ES
Aquellos que recién comienzan a familiarizarse con Java a menudo se confunden con los conceptos de código de máquina y código de bytes . ¿Qué son? ¿Cuáles son las diferencias? En una breve nota intentaremos describir sus características de la manera más simple y clara posible para cerrar este problema de una vez por todas.
Código de máquina y código de bytes: ¿qué idioma habla su programa?  - 1

Codigo de maquina

El procesador es, en esencia, una calculadora muy compleja y avanzada. Tiene muchas ubicaciones de memoria (llamadas registros) en y entre las cuales se realizan diversas operaciones matemáticas y de bytes. El código de máquina es precisamente una descripción de la secuencia de operaciones y el conjunto de datos involucrados. De hecho, es el único idioma que entiende el procesador de su computadora.

Incompatibilidad congénita

Además, no todos los procesadores “hablan” el mismo idioma. Existen diferencias no sólo entre las arquitecturas CISC y RISC , sino también dentro de estos “campos”.

CISC (Computación de conjunto de instrucciones complejas) es un concepto de diseño de procesador que se caracteriza por el siguiente conjunto de propiedades:

  • muchos comandos, de diferente longitud;
  • muchos modos de direccionamiento;
  • codificación de instrucciones complejas.
RISC (Computación con conjunto de instrucciones reducido) : un procesador con un conjunto de instrucciones reducido. Los comandos son del mismo formato, cortos y con codificación sencilla.
Las nuevas generaciones de procesadores introducen conjuntos de instrucciones adicionales que los modelos de generaciones anteriores simplemente desconocen. Debido a esto, los programas compilados para una arquitectura (o una generación de procesadores) no pueden ejecutarse en otro hardware. Todo esto nos obliga a recompilar programas para asegurarnos de que funcionan en otros ordenadores. Sin embargo, hay que recompilar no sólo por los procesadores, sino también por las diferencias en la interacción de los programas y el sistema operativo. Es por ellos que es imposible ejecutar un programa "Windows" en Linux y un programa "Linux" en Windows.

código de bytes

Bytecode es en muchos aspectos similar al código de máquina, solo que utiliza un conjunto de instrucciones no de un procesador real, sino de uno virtual. Además, puede incluir secciones centradas en el uso de un compilador JIT , que optimiza la ejecución de comandos para el procesador real en el que se ejecuta el programa.
La compilación JIT (compilación justo a tiempo, compilación sobre la marcha) o compilación dinámica (traducción dinámica) es una tecnología para aumentar el rendimiento de los sistemas de software que utilizan código de bytes compilando el código de bytes en código de máquina o en otro formato directamente mientras el programa se está ejecutando. “Oficialmente” en Java hasta la versión 9 solo existía un compilador JIT. En Java 9, apareció otro compilador que compila antes de tiempo (AoT). Esta característica permite compilar clases de Java en código nativo antes de ejecutarlas en una máquina virtual. Esta característica está diseñada para mejorar los tiempos de inicio de aplicaciones grandes y pequeñas, con un impacto limitado en el rendimiento máximo.
Para los procesadores CISC , algunas instrucciones se pueden combinar en estructuras más complejas soportadas por el procesador, y para los RISC , por el contrario, se pueden dividir en secuencias de instrucciones más simples.

También un sistema operativo virtual

Sin embargo, el código de bytes no solo contiene instrucciones del procesador. También contiene lógica para interactuar con un sistema operativo virtual, lo que hace que el comportamiento de la aplicación sea independiente del sistema operativo utilizado en la computadora. Esto es claramente visible en la JVM , donde el trabajo con las llamadas al sistema y la GUI suelen ser independientes del sistema operativo en el que se ejecuta el programa. En general, la JVM emula el proceso de lanzamiento de un programa, a diferencia de soluciones como Virtual Box , que crean sólo un sistema/hardware virtual.

¿Es JVM el único así?

Definitivamente no. La misma CLI de DotNet también es una máquina virtual, que se usa con mayor frecuencia en computadoras que ejecutan Windows con procesadores compatibles con x86 . Sin embargo, existe una implementación para otros sistemas: las aplicaciones deben ejecutarse en Windows RT con procesadores compatibles con ARM (RISC) , o puede ejecutarlas en Linux/OSX en el entorno Mono , que es un tercero (y por lo tanto no totalmente compatible) implementación de DotNet para estas plataformas. Entonces, esta plataforma, al igual que la JVM , se ejecuta en diferentes procesadores y diferentes sistemas operativos. Hay muchas más soluciones similares (antiguas y nuevas): LLVM , Flash SWF y otras. Algunos lenguajes de programación tienen sus propias máquinas virtuales. Por ejemplo, CPython compila fuentes PY en archivos PYC : código de bytes compilado que está preparado para ejecutarse en PVM . O hay un ejemplo mucho más antiguo: Lisp se puede compilar en archivos FASL (carga rápida). De hecho, contienen un árbol AST creado por el generador a partir del código fuente. Estos archivos pueden ser leídos y ejecutados por el intérprete Lisp en varias plataformas, o usarse para generar código de máquina para la arquitectura de hardware utilizada actualmente.
Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION