Modos de direccionamiento histórico / Condiciones que complican el manejo de fallas de página

Navega tus respuestas
0

Estaba leyendo esta pregunta vinculada y me destacaron los siguientes párrafos:

  

Por ejemplo, x86 y 68000 tenían instrucciones que accedían a la memoria dos o más veces. Cada acceso a la memoria puede causar un error de página. Por lo tanto, la CPU debe revertir la instrucción incompleta y guardar el estado suficiente para volver a ejecutar la instrucción desde el inicio, o guardar el estado suficiente para continuar y continuar con la instrucción incompleta. En cualquier caso, eso podría ser millones o incluso miles de millones de instrucciones más adelante, con otras instrucciones intermedias que también presenten fallas de página.

     

... Entonces, las 'excepciones de instrucciones incompletas' guardan un estado diferente en la pila y, por lo tanto, deben manejarse de manera diferente para las interrupciones normales.

Hoy en día, las arquitecturas de CPU, excepto x86 en general, no permiten múltiples accesos de memoria por instrucción. Dicho esto, me pregunto históricamente qué modos de direccionamiento y el estado de la CPU (como un error de página en medio de una instrucción) requerirán que se guarde un estado especial para restaurar el estado del procesador. Además, ¿qué estado de la CPU tendría que guardarse conceptualmente?

Para el resto de esta pregunta, suponga que tengo una CPU que reinicia una instrucción en fallo de página (x86), y otra que se detiene en medio de una instrucción en fallo de página (68k).

También asuma que estas CPU son similares a CISC en orden; permiten que ambos src y dst sean operandos de memoria para datos en movimiento y las operaciones aritméticas pueden acceder a la memoria directamente. Esto crea un ISA donde las insns pueden tener múltiples accesos de memoria. Además, ignorar las complicaciones causadas por la canalización. Preguntaré sobre los casos de x86, como aludido a , como una pregunta separada.

Puedo pensar en solo dos modos de direccionamiento histórico mal comportados, antes del decremento previo y posterior al incremento. Además, una instrucción que abarca un límite de página puede causar problemas.

  • Pre-decremento / Post-incremento
    • En una CPU de "reinicio en fallo de página", el estado para un decremento con fallas tendría que poder revertir el registro dec / incrementado, independientemente del motivo por el cual la instrucción falló (abarcar límite de página o fallo de página en el acceso); el decremento se produciría antes de cualquier acceso a la memoria, pero se producirá un incremento entre el acceso a la memoria en MOV.

  • La instrucción abarca páginas

    • En la CPU "reinicio en fallo de página", es posible que ya se haya iniciado una instrucción mientras esperando los bytes de instrucciones restantes. Así que el límite de instrucción necesita para ser conocido para recuperar (así como el estado para revertir los efectos secundarios del direccionamiento del insn modo) después de que se ejecute el manejador de errores de página.

  • AFAICT, el único estado que debe guardarse en una CPU que "se detiene en medio de una inserción en una falla" es "cuán lejos avanzó la instrucción" antes de la falla, y continúa desde ese punto, independientemente de la razón de la culpa. No es necesario revertir los registros, y ni siquiera creo que se deba guardar la "razón de la falla".

¿Mi explicación / comprensión es precisa? ¿Debo considerar algún otro estado de CPU y modos de direccionamiento (más sus combinaciones)?

    
pregunta cr1901

1 respuesta

2

La serie de CPU de Motorola almacenaba diferentes cantidades de estado específico del procesador en la pila de supervisores cuando manejaba la mayoría de las fallas (incluidas las fallas de página). Este blob binario (destinado a ser opaco) fue, en esencia, un volcado del estado interno de la CPU en el momento en que se descubrió el fallo, lo que permite que la CPU retome el lugar donde lo dejó si decide reiniciar la operación. Sin embargo, no conozco ningún otro procesador que (re) almacene su estado interno de esta manera.

Descargo de responsabilidad: a continuación, especulaciones basadas en vagos recuerdos. Mientras que el almacenamiento del estado de microarquitectura en la pila de supervisores fue efectivo, recuerdo que también afectó la compatibilidad hacia adelante / hacia arriba de los sistemas operativos (esto estaba totalmente oculto del modo de usuario). La incapacidad aproximada de predecir cómo los cambios en la microarquitectura impactarían la lógica de manejo de fallas hizo que el soporte de los núcleos sea más difícil que, por ejemplo, para x86, donde la compatibilidad con versiones anteriores era una filosofía establecida no solo para el código del anillo 3, sino para todos los anillos. / p>

Otra preocupación es la latencia; El enfoque de Motorola para resolver este problema involucraba el almacenamiento automático de hasta (IIRC) 16 palabras largas hacia o desde la pila. No se puede opinar sobre esto, lo que hace que los procesadores de Motorola sean algunos de los más lentos para responder a diversos tipos de fallas. Dado que las diferentes condiciones operativas pueden afectar a qué marco de pila se empuja, la latencia no era predecible aún sin un conocimiento muy detallado del estado interno de la CPU en el momento en que se produjo el fallo. Una buena razón por la que los procesadores eligen reiniciar desde cero en lugar de almacenar el estado actual es que realmente mejora el rendimiento y hace que las cosas sean más predecibles.

    
respondido por el Samuel A. Falvo II

Lea otras preguntas en las etiquetas

Conexión de un dispositivo a una CPU a través de pistas de PCB USB [cerrado] BJT amplificador de una etapa con fuente de corriente