Diferencia entre revisiones de «Experiencias con MIPsim»

Revisión actual del 03:25 22 ene 2009

Primer contacto

1. Ejecuto el programa.
   1. Aparece una ventana dividida en dos partes. En la de la izquierda aparecen las instrucciones que hay introducidas, que ahora mismo son todas NOP. En la de la derecha aparece un esquema del camino de datos dividido en segmentos, todo en gris.
2. Pulso la tecla del triángulo verde (Start simulation).
   1. Los cables que conectan los diferentes componentes se van "llenando" de las instrucciones (NOP). Se puede ver cómo las instrucciones van atravesando los distintos segmentos a la vez que van entrando otras.
   2. En la barra de arriba, que indica los segmentos, se puede ver qué instrucción hay en cada segmento y en el mismo color que los cables.
3. Pulso el botón de Pause Simulation para poder ver bien.
   1. El flujo se congela. Incluso las instrucciones se quedan a mitad de los cables.
   2. La barra de estado (abajo) me advierte: Drücken Sie F1, um Hilfe zu erhalten.
4. Le hago caso y pulso F1.
   1. Aparece la ayuda.
5. La cierro.
6. Pulso el botón Simulation slow mode.
   1. El programa funciona igual que antes pero más despacio.
7. Pulso el botón Simulation fast mode.
   1. El programa funciona algo más rápido que en el modo normal.
8. Pulso el botón Simulation single step.
   1. El programa se para, esta vez justo cuando cada cable es de un sólo color.
   2. Cada vez que vuelvo a pulsar el botón la simulación avanza hasta el siguiente paso.
9. Pulso el botón Assembler window.
   1. Aparece la ventana del ensamblador (la experimentaremos en el siguiente contacto).
10. Cierro la ventana del ensamblador y pulso Register window.
    1. Aparece la ventana de registros.
    2. Compruebo que puedo cambiarlos y grabarlos a disco..
11. Pulso Data memory window.
    1. Aparece la ventana con las posiciones de memoria y su contenido.
    2. Se puede editar el contenido y grabarlo a disco.
12. Cierro el programa

Usando MIPSim bajo GNU/Linux

Ya que es nuestro entorno de trabajo habitual, vamos a ver si es posible usar el simulador de MIPS en el sistema operativo GNU/Linux con la ayuda del programa llamado wine. Éste es algo parecido a un emulador que permite ejecutar en GNU/Linux aplicaciones nativas de Windows. Desgraciadamente la API de Windows no es abierta, por lo que la emulación no es perfecta. Algunos programas funcionan perfectamente, otros tienen problemas y otros directamente no se pueden ejecutar.

Tras el tiempo de carga, aparece la ventana de MIPSim. Lo primero que podemos apreciar es que los botones que hay bajo la barra de menús no se dibujan correctamente: los dibujos de los botones no caben en ellos y se mezclan (añadir captura).

Probamos las funciones de simulación (empezar simulación, pausar, simular rápido, simular lento, etc). Funcionan correctamente aunque más despacio que en Windows.

Probamos la ventana de de ensamblador. Funciona todo correctamente: la ventana aparece, se puede cambiar, se puede grabar, cargar y resetear.

La ventana de registros funciona correctamente y se actualiza tanto por el usuario como por resultado de la operación del programa.

De la misma forma, la ventana de memoria también funciona.

Introducimos un pequeño programa en ensamblador y lo simulamos. La simulación es perfecta y los resultados son los esperados.

Pulsamos sobre el botón y nos aparece un diálogo que nos dice: Die Hilfe konnte nicht aufgerufen werden., que suponemos que quiere indicarnos que la ayuda no se encuentra. Lo mismo ocurre cuando intentamos acceder a la ayuda desde el menú.

Probamos a visualizar el contenido de los buses y elementos del camino de datos durante la simulación. Actúa correctamente.

Conclusión: es totalmente factible utilizar el simulador de MIPS en GNU/Linux usando wine. La única pega real es la velocidad.

Riesgos por dependencia de datos

En MIPS no se pueden escribir los programas despreocupadamente, ya que no existe una forma de tratar los riesgos de la segmentación.

En esta prueba vamos a comprobar qué ocurre en MIPS ante los riesgos por dependencia de datos. Estos se producen porque si una instrucción escribe en un registro, este cambio no se hace efectivo hasta el último segmento. Esto quiere decir que, ya que las instrucciones leen el banco de registros en su segundo segmento, cuando la escritura en el registro se produce hay cuatro instrucciones que pueden haber leído el registro con campos obsoletos.

Para comprobar esto, veremos dos programas.

Fibonaci a Mano

En el primero, se parte con todos los registros con valor 1. Se suma el registro 1 con el 2 y se almacena en el 3. Después se suma el 2 con el 3 y se almacena en el 4 y así sucesivamente hasta almacenar en el registro 10. El resultado es que los registros del 1 al 10 contienen los 10 primeros elementos de la sucesión de Fibonaci calculados de forma no estructurada. El código es el siguiente:

 
add $3, $2, $1
add $4, $3, $2
add $5, $4, $3
add $6, $5, $4
add $7, $6, $5
add $8, $7, $6
add $9, $8, $7
add $10, $9, $8

El resultado esperado es el siguiente:

Que se corresponde con la sucesión de Fibbonaci.

Sin embargo, el resultado obtenido es el siguiente:

Ya que cada dato sirve para obtener los dos siguientes, al hacer una suma no da nunca tiempo a que los sumandos estén actualizados, luego siempre se toman como 1 y las sumas siempre son 2.

Solución

En este programa la única solución es agregar instrucciones NOP en medio de las instrucciones. El nivel de segmentación posible es muy escaso.

 
add $3, $2, $1
nop
nop
add $4, $3, $2
nop
nop
add $5, $4, $3
nop
nop
add $6, $5, $4
nop
nop
add $7, $6, $5
nop
nop
add $8, $7, $6
nop
nop
add $9, $8, $7
nop
nop
add $10, $9, $8

Sumas Distanciadas

Este programa pretende hallar experimentalmente el número de instrucciones que deben distanciar otras dos para evitar el riesgo.

Inicialmente todos los registros deben estar a 1.

 
add $2, $2, $1
add $2, $2, $1

add $3, $3, $1
nop
add $3, $3, $1

add $4, $4, $1
nop
nop
add $4, $4, $1

add $5, $5, $1
nop
nop
nop
add $5, $5, $1

add $6, $6, $1
nop
nop
nop
nop
add $6, $6, $1

add $7, $7, $1
nop
nop
nop
nop
nop
add $7, $7, $1

$1 siempre contiene el número 1. Los registros $2 al $7 se incrementan dos veces cada uno, por lo que se espera que al final tengan el valor 3. Veamos que sucede en realidad:

De lo que se desprenden que es necesario dejar un espacio de al menos dos operaciones desde que una instrucción escribe en un registro hasta que otra lo usa.

Riesgos de Control

Estos se producen cuando hay un salto porque se introducen instrucciones en el cauce antes de que pueda evaluarse la condición y, por tanto, saber cual va a ser el camino del programa.

Probaremos con el siguiente programa:

 
beq $1, $2, 10
add $3, $2, $1
add $4, $2, $1
add $5, $2, $1
add $6, $2, $1
add $7, $2, $1
add $8, $2, $1
add $9, $2, $1
add $10, $2, $1

El programa debería saltar a la sexta instrucción y hacer las sumas que haya de allá para adelante. El resultado es el siguiente:

Por tanto esta vez MIPS se comporta correctamente y salva los riesgos de control.

Durante la simulación observamos que tras la primera instrucción, se introduce en el cauce la segunda, sin hacer el salto. Después la tercera y entonces estas tres instrucciones se anulan (aparecen en gris en el programa) y se introduce la instrucción correcta, continuando el programa de forma correcta.

Errores de MIPSim

Ensamblador

1. Cuando estás editando una instrucción y cambias de ventana, pierdes los cambios.

Formatos de archivo

Es una buena característica el que se puedan guardar las instrucciones, registros y memoria en ficheros para después cargarlos. Sin embargo los diseñadores tuvieron el desacierto de codificar estos ficheros de forma binaria. Se echa de menos, una vez has hecho un programa, poder manipularlo con un edior más potente, para insertar unas instrucciones entre otras, copiar y pegar texto, buscar dentro del programa, etc.