Emulador

De MadriSX wiki
Revisión del 09:36 12 oct 2006 de Museo8bits (discusión | contribs.)
(difs.) ← Revisión anterior | Revisión actual (difs.) | Revisión siguiente → (difs.)
Ir a la navegaciónIr a la búsqueda

En informática, un emulador es un software que permite ejecutar programas de ordenador en una plataforma (arquitectura hardware o sistema operativo) diferente de la cual fueron escritos originalmente. A diferencia de un simulador, que sólo trata de reproducir el comportamiento del programa, un emulador trata de modelar de forma precisa el dispositivo que se está emulando.

Un uso popular de los emuladores es el de imitar la experiencia de los videojuegos de máquinas recreativas o videoconsolas en sistemas operativos como Linux, Mac OS X o Microsoft Windows, o el poder ser jugados en otras videoconsolas. La emulación de videojuegos de sistemas antiguos (abandonware) en las modernas computadoras personales y videoconsolas de hoy día resulta generalmente más cómodo y práctico que en los dispositivos originales. Sin embargo, puede ser requerido a los creadores de emuladores una licencia de software para escribir programas originales que dupliquen la funcionabilidad de la ROM y BIOS del hardware original, lo que comúnmente se conoce como high-level emulation o emulación de alto nivel.

En sentido teórico, la tesis de Church-Turing implica que cualquier ambiente funcional puede ser emulado dentro de cualquier otro. En la práctica, esto puede resultar realmente difícil, particularmente cuando el comportamiento exacto del sistema emulado no está documentado y debe ser deducido mediante ingeniería inversa. Tampoco se habla en la tesis sobre las diferencias en sincronización; si el emulador no actúa tan rápidamente como el hardware original, el software de emulación va a ir más lento que si fuese el hardware original.

Estructura

La mayoría de los emuladores solo emulan una arquitectura de hardware - si un sistema operativo específico se requiere para un software deseado, éste debe ser proporcionado también (y puede emularse asimismo). Tanto el SO como el software deben ser interpretados por el emulador, como si estuviese corriendo en el hardware original. Aparte de la interpretación del lenguaje de la máquina emulada, otros hardwares (como los dispositivos de entrada y salida) deben ser provistos también de forma virtual: si escribir a una región específica de la memoria debe influir en el contenido en pantalla, por ejemplo, esto también debe ser emulado.

En vez de una emulación completa del hardware, una compatibilidad superficial puede ser suficiente. Esto traduce las llamadas del sistema emulado a llamadas del sistema anfitrión.

Los desarrolladores de software para máquinas con sistemas computarizados y consolas de videojuego comúnmente diseñan el software en emuladores especialmente exactos llamados simuladores antes de correrlos en el hardware real. Esto permite que el software pueda ser producido y probado antes de que la versión final del hardware para el cual se está desarrollando sea producida en grandes cantidades, de esta forma puede ser probado sin tener que copiar el programa en el hardware, de modo que puedan ser eliminados errores en un nivel bajo sin tener los efectos colaterales de un depurador.

Típicamente, un emulador se divide en módulos que corresponden de forma precisa a los subsistemas de la computadora emulada. Lo más común, es que un emulador este compuesto por los siguientes módulos:

    • un emulador de CPU o un simulador de CPU (ambos términos son en la mayoría de los casos intercambiables)
    • un módulo para el subsistema de memoria
    • varios emuladores para los dispositivos de entrada y salida.

Lo más común es que los BUSes no sean emulados, por razones de simplicidad y rendimiento, y para que los periféricos virtuales se comuniquen directamente con el CPU y los subsistemas de memoria.

Subsistema de memoria

Es posible que la emulación de los subsistemas de memoria se reduzca a un simple arreglo de elementos cada uno clasificado como una palabra emulada; sin embargo, este modelo falla rápidamente tan pronto como cualquier parte en memoria lógica de la computadora no coincida con la memoria física.

Éste es claramente el caso en que el hardware emulado permita un manejo avanzado de la memoria (en caso que, la Unidad de administración de memoria lógica pueda ser encajada en la memoria del emulador, haciendo un módulo de sí mismo, o en ciertos casos integrándola en el simulador del CPU). si

Incluso si la computadora emulada no contiene una MMU, es posible que existan otros factores que permitan la equivalencia entre memoria lógica y física; algunas (si no todas) arquitecturas ofrecen un mapeado de memoria de entrada y salida; incluso aquellos que no son del todo invariables contienen un bloque de memoria lógica mapeada a la Memoria de sólo lectura, lo cual significa que el módulo de arreglo de memoria debe ser descartado si la memoria ROM va a ser emulada.

Como resultado, la mayoría de los emuladores implementa al menos dos procedimientos para escribir y leer de la memoria lógica, y este procedimiento debe mapear cada acceso a su localización correcta del objeto correcto.

En un sistema de dirección en base-límite donde la memoria de la dirección 0 a la dirección ROMSIZE es memoria de sólo lectura, mientras que el resto es RAM, algo a lo largo de la línea de los siguientes procedimientos sería lo típico: 

void WriteMemory(word Address, word Value) {
    word RealAddress;
    RealAddress=Address+BaseRegister;
    if(RealAddress<LimitRegister) {
        if(RealAddress>ROMSIZE) Memory[RealAddress]=Value;
    } else {
        RaiseInterrupt(INT_SEGFAULT);
    }
}

word ReadMemory(word Address) {
    word RealAddress;
    RealAddress=Address+BaseRegister;
    if(RealAddress<LimitRegister) {
        return Memory[RealAddress];
    } else {
        RaiseInterrupt(INT_SEGFAULT);
        return NULL;
    }
}

Simulador de CPU

El Simulador de CPU es a menudo la parte más compleja de un emulador. Muchos emuladores son escritos utilizando simuladores de CPU "pre-empaquetados", para así poder realizar una emulación fiel y eficiente de una máquina específica.

El simulador de CPU más simple sería un Intérprete informático, que sigue el flujo de ejecución del código de programación emulado y, por cada instrucción de código de la máquina emulada, ejecuta en el procesador en que se carga, instrucciones semánticamente equivalentes a las originales.

Esto es posible asignando una variable a cada registro y flag de la CPU simulada. La lógica de la CPU simulada puede ser más o menos traducida directamente a algoritmos de software, creando una re-implementación del software que básicamente refleja la implementación original del hardware.

El ejemplo siguiente ilustra el modo en que la simulación de CPU por un intérprete. En este caso, las interrupciones se revisan después de la ejecución de cada instrucción, aunque este comportamiento no es usual en los emuladores en la realidad, por razones de rendimiento. 


void Execute(void) {
    if(Interrupt!=INT_NONE) {
        SuperUser=TRUE;
        WriteMemory(++StackPointer, ProgramCounter);
        ProgramCounter=InterruptPointer;
    }
    switch(ReadMemory(ProgramCounter++)) {
        // Handling of every valid instruction
        default:
        Interrupt=INT_ILLEGAL;
    }
}

Los intérpretes son muy populares en el caso de los simuladores de CPU, ya que son más sencillos de implementar que otras soluciones alternativas de mejor rendimiento, y su velocidad es más que adecuada para emular computadares de hace más de una [década|década] en máquinas modernas.

Aún así, la penalización de velocidad inherente en la interpretación puede ser un problema al emular computadores cuya velocidad de procesador está en el mismo [orden de magnitud] que la máquina huésped. Hasta no hace tantos años, la emulación en tales situaciones era considerada impracticable.

Lo que permite el rompimiento de esta restricción son las técnicas avanzadas de recompilación dinámica. Una translación simple a priori del código del programa emulado al código que corre en la arquitectura original es usualmente imposible por varias razones:

  • el código puede ser auto modificable
  • no existe una forma que distinga de forma confiable los segmentos de información (que no deben ser traducidos) de los segmentos de texto (segmentos de código)
  • no existe forma de comunicarse con el sistema operativo emulado para que el emulador reconozca los nuevos códigos cargados (por ejemplo del disco)

Varias formas de recompilación dinámica, incluyendo la popular técnica de compilación en tiempo de ejecución (compilación JIT), trata de bordear estos temas esperando hasta que el proceso de control de flujo se mueva hasta donde esta la parte donde esta localizado el código sin traducir, y es solo entonces {"en tiempo de ejecución") cuando los bloques traducidos del código al código anfitrión pueden ser ejecutados.

El código traducido se mantiene en el código cache, y el código original no se pierde ni es afectado; de esta forma, incluso los segmentos de data pueden ser trasladados por el recompilador, resultando solo en un gasto de tiempo de traslado.

Dispositivos de Entrada y Salida

La mayoría de los emuladores, como dicho anteriormente, no emulan el sistema principal bus; cada dispositivo de entrada y salida es tratado a menudo como un caso especial, y no existe una interfaz constante para los periféricos virtuales.

Esto puede resultar en una ventaja en el funcionamiento, proveyendo que cada módulo de entrada y salida pueda ser adaptado a las características del dispositivo emulado; diseños basados en un estándar, entradas y salidas unificadas por medio de API pueden sin embargo proveer modelos más simples, y además tienen la ventaja adicional de permitir de forma "automática" la utilización de servicios plugins para proveer dispositivos virtuales de terceros en el emulador.

Las entradas y salidas unificadas por medio de API no necesariamente reflejan la estructura del bus del hardware real: el diseño del bus esta limitado por varios parámetros eléctricos y la necesidad del manejo de programación paralela que la mayoría de las veces puede ser ignorada en la implementación del software.

Aún los emuladores que tratan cada dispositivo como un caso especial poseen una infraestructura básica en común para ello:

  • manejando interruptores, por medio de procedimientos que fijen banderas legibles por el simulador del CPU siempre que un interruptor sea levantado, permitiendo al CPU virtual "convertir los interruptores (virtuales)".
  • escribiendo y leyendo de la memoria física, por medio de dos procedimientos similares mientras este lidia con la memoria lógica (contrario a este último, el anterior puede comúnmente ser echado a un lado, y en su lugar se emplean las referencias directas al arreglo de memoria)

Sistema de ROMs

Los emuladores arrancan ROMs, el contenido de los cartuchos, disquetes o cintas que se usaban con los sistemas antiguos. Físicamente en las PC las ROMs son archivos binarios que se pueden cargar en la memoria. Es decir, el emulador es un programa que hace las funciones de una consola, por ejemplo la Game Boy Advance o una PDA, y la ROM es un archivo que hace de cartucho, Cd, o Cinta, por ejemplo "Mario Bros.".

Virtualización

También hay una vertiente en la emulación que puede ser realizada por virtualización, consistente en crear una capa de abstracción, pero ejecutando instrucciones en una máquina del mismo tipo, y da como resultados obtener un ordenador dentro de otro. Ejemplos de esto son:

Algunas arquitecturas emuladas

Ejemplos de Emuladores

Artículo principal: Lista de Emuladores

Véase también

Enlaces externos

Obtenido de «http://wiki.madrisx.org:80/index.php?title=Emulador&oldid=2170»