Un simulador de conjunto de instrucciones ( ISS ) es un modelo de simulación , generalmente codificado en un lenguaje de programación de alto nivel , que imita el comportamiento de un mainframe o microprocesador "leyendo" instrucciones y manteniendo variables internas que representan los registros del procesador .
La simulación de instrucciones es una metodología que se emplea por una de varias razones posibles:
Los simuladores de conjuntos de instrucciones se pueden implementar utilizando tres técnicas principales:
A menudo, una ISS se proporciona con (o es en sí misma) un depurador para que un ingeniero de software / programador depure el programa antes de obtener el hardware de destino. GDB es un depurador que tiene una ISS compilada. A veces se integra con circuitos periféricos simulados, como temporizadores , interrupciones , puertos serie , puertos de E/S generales , etc., para imitar el comportamiento de un microcontrolador .
La técnica básica de simulación de instrucciones es la misma independientemente del propósito: primero se ejecuta el programa de monitoreo pasando el nombre del programa de destino como un parámetro de entrada adicional.
El programa de destino se carga entonces en la memoria, pero el control nunca se pasa al código. En cambio, se calcula el punto de entrada dentro del programa cargado y se establece una palabra de estado de pseudoprograma (PSW) en esta ubicación. La palabra de estado de programa (PSW) se compone de un registro de estado y un contador de programa , el último de los cuales significa la siguiente instrucción que se ejecutará. [1] Por lo tanto, es específicamente el contador de programa el que se asigna a esta ubicación. Un conjunto de pseudoregistros se establece en lo que habrían contenido si se le hubiera dado el control directamente al programa.
Puede ser necesario modificar algunos de estos parámetros para que apunten a otros pseudo "bloques de control" según el hardware y el sistema operativo. También puede ser necesario restablecer la lista de parámetros original para "eliminar" el parámetro de nombre de programa agregado anteriormente.
Posteriormente la ejecución se realizará de la siguiente manera:
Para fines de prueba y depuración, el programa de monitoreo puede proporcionar funciones para ver y modificar registros, memoria y ubicación de reinicio u obtener un minivolcado de memoria o imprimir nombres de programas simbólicos con valores de datos actuales. Podría permitir nuevas ubicaciones de "pausa" condicionales, eliminar pausas no deseadas y cosas por el estilo.
La simulación de instrucciones ofrece la posibilidad de detectar errores ANTES de la ejecución, lo que significa que las condiciones siguen siendo exactamente las mismas que antes y no se han visto destruidas por el error. Un buen ejemplo del mundo IBM S/360 es la siguiente secuencia de instrucciones que puede causar dificultades de depuración sin un monitor de simulación de instrucciones.
LM R14,R12,12(R13) donde r13 apunta incorrectamente a la cadena de X"00" BR R14 hace que PSW contenga X "0000002" con la comprobación del programa "Excepción de operación"* todos los registros en caso de error contienen valores nulos.
El número de instrucciones para realizar el "bucle" básico anterior (obtener/ejecutar/calcular nueva dirección) depende del hardware, pero podría lograrse en la gama de máquinas IBM S/360 /370/390/ES9000 en alrededor de 12 o 13 instrucciones para muchos tipos de instrucciones. La comprobación de ubicaciones de memoria válidas o de "pausas" condicionales aumenta considerablemente la sobrecarga, pero las técnicas de optimización pueden reducirla a niveles aceptables. Para fines de prueba, esto normalmente es bastante aceptable, ya que se proporcionan potentes capacidades de depuración, que incluyen paso de instrucción , seguimiento y salto deliberado a la rutina de error de prueba (cuando no hay ningún error real). Además, se puede utilizar un seguimiento de instrucción completo para probar la cobertura del código real (ejecutado) .
En ocasiones, supervisar la ejecución de un programa de destino puede ayudar a destacar errores aleatorios que aparecen (o a veces desaparecen) durante la supervisión, pero no en la ejecución real. Esto puede suceder cuando el programa de destino se carga en una ubicación diferente a la normal debido a la presencia física del programa de supervisión en el mismo espacio de direcciones.
Si el programa de destino toma el valor de una ubicación "aleatoria" en la memoria (una que no es "suya" habitualmente), puede ser, por ejemplo, nulo (X"00") en casi todas las situaciones normales y el programa funciona bien. Si el programa de monitoreo cambia el punto de carga, puede tomar, por ejemplo, X"FF" y la lógica provocaría resultados diferentes durante una operación de comparación. Alternativamente, si el programa de monitoreo ahora está ocupando el espacio de donde se está "tomando" el valor, pueden ocurrir resultados similares.
Errores de reentrada: el uso accidental de variables estáticas en lugar de memoria de subprocesos "dinámica" puede causar problemas de reentrada en muchas situaciones. El uso de un programa de monitoreo puede detectarlos incluso sin una clave de protección de almacenamiento.
Operaciones ilegales: algunos sistemas operativos (o hardware) requieren que el programa de aplicación esté en el "modo" correcto para ciertas llamadas al sistema operativo. La simulación de instrucciones puede detectar estas condiciones antes de la ejecución.
Análisis de puntos calientes y uso de instrucciones mediante el recuento de las instrucciones ejecutadas durante la simulación (que coincidirá con el número ejecutado en el procesador real o la ejecución no supervisada), el simulador puede proporcionar una medida del rendimiento relativo entre diferentes versiones del algoritmo y también puede utilizarse para detectar "puntos calientes" donde el programador puede apuntar a la optimización . En este papel puede considerarse una forma de análisis de rendimiento , ya que no es fácil obtener estas estadísticas en una ejecución normal y esto es especialmente cierto para los programas de lenguaje de alto nivel que efectivamente "disfrazan" el alcance de las instrucciones de código de máquina por su naturaleza.
Algunos de estos simuladores de software aún se utilizan como herramientas para la enseñanza del lenguaje ensamblador y la arquitectura del conjunto de instrucciones, y algunos están diseñados específicamente utilizando múltiples capas de simulación y simulación de ISA a ISA, con la capacidad incluso de diseñar ISA y simularlas. [2]
En el primer volumen de El arte de la programación informática , Donald Knuth escribió: "En opinión del autor, los programadores han dedicado demasiado tiempo a escribir estos simuladores [de lenguaje máquina] y se ha desperdiciado demasiado tiempo informático en utilizarlos". [3] Sin embargo, en la siguiente sección, el autor da ejemplos de cómo estos simuladores son útiles como rutinas de seguimiento o monitorización para fines de depuración.
Salida de seguimiento típica de la simulación realizada mediante un programa de monitoreo utilizado para pruebas y depuración:
Instrucción de desplazamiento del programa Registro/almacenamiento desensamblado (después de la ejecución) PRUEBA001 000000 X'05C0' BALR R12,0 R12=002CE00A 000002 X'47F0C00E' BC 15,X'00C'(R12) 00000E X'98ECD00C' STM R14,R12,X'00C'(R13) X'002E0008' ==> X'00004CE,002CE008,..etc....' 000012 X'45E0C122' Balanza R14, X'122'(R12) R14=002C0016SUB1 000124 X'50E0C28A' ST R14,X'28A'(R12) X'002CE294' ==> X'002C0016'etc...
Simuladores
Otro