Por qué no existen convertidores de código en vez de emuladores?

A ver, parto de la base de que no tengo ni idea de programación. Es una duda que siempre me ha surgido. Un programa que en vez de emular una plataforma en otra, convierta el código del juego de una a otra. Eso sí, de una plataforma inferior a otra superior, no al revés.
Por ejemplo, que coja un juego de gameboy y lo convierta a un juego de Amiga, que se supone que es superior por lo que no habría problema. Me explico?

Porque supongo que para hacer un emulador los programadores deben conocer a fondo las dos máquinas, la emulada y la emuladora. Me equivoco?

Abro paraguas por si me llueven palos.
@rafa-lito No es tan sencillo porque normalmente no tienes el código fuente (solo el resultado de haberlo compilado para una arquitectura hardware concreta). También habría que convertir el sistema operativo de la máquina original. Es como hacer un port a otra plataforma, sería un proceso manual.

Si el juego contaba con alguna optimización de bajo nivel para la arquitectura en cuestión, tampoco sirve en otra.

Con la emulación estás emulando el hardware original, conviertes las llamadas originales a las llamadas al sistema de verdad donde lo estés ejecutando. Lo bueno es que así puedes ejecutar absolutamente todo: la firmware con el sistema operativo original y los juegos sin modificar. Además, lo haces respetando la velocidad del procesador y otras características, de modo que el juego se encuentra un entorno de ejecución igual que aquel para el que se desarrolló en un primer momento.
rafa-lito escribió:A ver, parto de la base de que no tengo ni idea de programación. Es una duda que siempre me ha surgido. Un programa que en vez de emular una plataforma en otra, convierta el código del juego de una a otra. Eso sí, de una plataforma inferior a otra superior, no al revés.
Por ejemplo, que coja un juego de gameboy y lo convierta a un juego de Amiga, que se supone que es superior por lo que no habría problema. Me explico?

Porque supongo que para hacer un emulador los programadores deben conocer a fondo las dos máquinas, la emulada y la emuladora. Me equivoco?

Abro paraguas por si me llueven palos.


Antes de comenzar a dar mi charla comento, Si se te ocurre algo y no es tu campo, probablemente ya haya sido estudiado y probablemente sea inviable o solamente usable en según qué casos (y probablemente sea de cuñado)

Dicho esto, los convertidores de código no existen porque para empezar no existe código agnóstico.

Incluso en PC tenemos el tema de que el código que se escribe para Windows no es compatible con Mac OS X (post-powerPC, pre-M1) y GNU/Linux debido a que usan recursos (librerías) muy asociado a dichas plataformas,
Quiero decir, No puedes ejecutar juegos de Windows en tu Linux a pesar de ser la misma arquitectura y la misma máquina, siempre hay que crear ejecutable especiales que funcionen en los recursos específicos de cada uno (por eso existen la preprocesacion antes de compilar cualquier programa multiplataforma, AKA, las declarativa #if #end #ifdef y similares. (Que no confundir con los if de programar normalmente) (Hablando de lenguajes de programación que no usen Máquinas virtuales como el JVM de Java o el MSIL/CIL de Microsoft .Net)

Si todo fuera así de simple, no habría horrores de ports en PC.

Dicho esto, existe dos términos que son muy parecido a lo que propones, que existen y se usa en mayor o menor medida (porque ni todo es tan bonito, ni todo es tan sencillo)
Los términos son HLE (High-level emulation) y los recompiladores (de shaders o binarios ). Y los máximos exponentes de esto. UltraHLE64 (un emulador con montones de glitches visuales, pero de los mejores emuladores de la época, a falta de emuladores que no fueran lentos ) y RPCS3 (Uno de los emuladores más exigentes actualmente)

Estoy ahora mismo sacando al perro, lo resumiré, en que
El HLE solo funciona cuando la arquitectura a la que se quiere emular, es lo suficientemente parecida a donde se emula. Cuanto menos parecido, más glitches se producen.
Normalmente se suele usarse hoy en día para tema de audio y cosas no críticas pero no hay ningún emulador HLE puro hoy en dia.

Aqui tienes un articulo de wiki de emulación:
https://emulation.gametechwiki.com/inde ... _emulation

Aquí tienes un artículo de la emulación tradicional (bajo nivel) y la HLE, y el rendimiento en ambos.
https://alexaltea.github.io/blog/posts/ ... le-vs-hle/

Y la wiki de UltraHLE:
https://en.wikipedia.org/wiki/UltraHLE# ... _technique

Lo que se hace en GNU/Linux para que funcione en Windows (Wine) se le llama reimplementacion de librerías que básicamente lo que hace intentar que los elementos no-, agnósticos de Windows sean lo más agnóstico posible, pero vamos, nadie te impide usar Wine(D3D) sobre Windows En un Frankenstein de componentes. o programar para Wine en vez para Windows, por son lo que son, recursos/librerías.
(Aunque actualmente es lo mejor que puedes hacer si quieres jugar juegos añejos de Windows de XP para abajo)

Y los recompiladores (aqui me refiero a los LLVM Recompilers) como su nombre y indica recompilan, pero se compilan Just in time, porque se van recompilando según va ejecutando, normalmente se compilan los entrypoint al inicio de la emulación y después se va compilando según va ejecutandose.
(Técnicamente tendrías una experiencia más suave en una segunda run de un juego) y normalmente estas recompilaciones no son compatibles, porque se optimizan para la familia de procesador (ergo, compila con todas las funciones/optimizaciónes que el procesador pueda) , es decir, probablemente no puedas ejecutar (o te dé fallos) una recompilacion hecha en un Ryzen en un Intel e incluso no podrías ejecutar una recompilacion hecha en un Intel de octava generación en uno de 4ta, por no comentar.
Que compilar (porque lo que estás haciendo es recompilar) no es un trabajo liviano o sencillo xD.
Es como si fueras una granja de compilacion en la empresa original pero con desventajas incluidas.
(Por otro lado, los emuladores que usan esta técnica suelen mejoras las técnicas de recompilado (ya sea por ser fiel o por mejoras de rendimiento) así que probablemente lo que recompilaste en su día, actualmente está desfasado y tengas que recompilarlo otra vez.

Lamento haberte dado esta pesadilla jajajaja

EDIT: lo que comentado de las recompilaciones específicas a cada familia de procesador, se podría solucionar si lo compilar para un tipo genérico x86_64 pero empeoraría el rendimiento para todos. Y no es lo deseable.

Tengo que decir tambien que PCSX2 y Dolphin ya usaban recompiladores pero son lo denominados ASMJIT Recompilers no tienen Cache, ni son reutilizables (Se usa como modo alternativo en RPCS3 en caso de fallar alguna cosa con el LLVM Recompiler). Lo que si tiene Dolphin y CEMU, son recompiladores de Shaders, llamados en Dolphin Ubershaders.
2 respuestas