Las CPU no sondean para detectar interrupciones, al menos no en sentido lógico. Con respecto al software, las interrupciones son eventos asincrónicos.
Lo que sucede es que el hardware dentro de la CPU reconoce la solicitud de interrupción, que es una entrada eléctrica en una línea de interrupción, y en respuesta, deja de lado la ejecución normal de eventos para responder a la interrupción. En la mayoría de las CPU modernas, lo que sucede a continuación viene determinado por un apretón de manos de hardware específico para el tipo de CPU, pero la mayoría de ellos reciben algún tipo de algún tipo del dispositivo de interrupción. Ese número puede ser de 8 bits o 32 o lo que sea, según el diseño de la CPU. La CPU utiliza este número de interrupción para indexar en la tabla de vectores de interrupción, para encontrar una dirección para comenzar la ejecución de la rutina de servicio de interrupción. Una vez que se determina esa dirección, (y el contexto de ejecución actual se guarda de forma segura en la pila), la CPU comienza a ejecutar el ISR.
Cuando dos dispositivos comparten una línea de solicitud de interrupción, pueden hacer que se ejecuten diferentes ISR devolviendo un número de interrupción diferente durante el proceso de establecimiento de la comunicación. Si tiene suficientes números vectoriales disponibles, cada dispositivo de interrupción puede usar su propio vector de interrupción.
Pero dos dispositivos pueden incluso compartir una línea de solicitud de interrupción y un vector de interrupción, siempre que el ISR compartido sea lo suficientemente inteligente como para volver a todas las fuentes posibles de la interrupción dada y verificar los registros de estado para ver qué dispositivo solicitó el servicio .
un poco más detalle
Suponga que tiene un sistema compuesto por una CPU, y controlador de interrupciones, y un dispositivo de interrupción. En los viejos tiempos, estos habrían sido dispositivos físicos separados, pero ahora los tres podrían incluso residir en el mismo chip, pero todas las señales todavía están allí dentro de la caja de cerámica. Voy a utilizar una CPU powerPC (PPC) con un controlador de interrupción integrado, conectado a un dispositivo en un bus PCI, como un ejemplo que debería funcionar muy bien.
Digamos que el dispositivo es un puerto en serie que está transmitiendo algunos datos. Un controlador de puerto serie típico cargará un montón de datos en el FIFO del dispositivo, y la CPU puede hacer un trabajo regular mientras el dispositivo hace su trabajo.Normalmente, estos dispositivos se pueden configurar para generar una solicitud de interrupción cuando el dispositivo se está quedando sin datos para transmitir, de modo que el controlador del dispositivo pueda regresar y alimentar más.
La lógica de hardware en el dispositivo esperará un reconocimiento de interrupción de bus PCI, en cuyo punto, pueden suceder un par de cosas. Algunos dispositivos usan 'autovectoring', lo que significa que confían en el controlador de interrupción para asegurarse de que se seleccione la rutina de servicio correcta. Otros tendrán un registro, que el controlador del dispositivo preprogramará, que contiene un vector de interrupción que el dispositivo colocará en el bus de datos en respuesta al reconocimiento de interrupción, para que el controlador de interrupción capte.
Un bus PCI tiene solo cuatro líneas de solicitud de interrupción, por lo que nuestro dispositivo serie tendrá que confirmar una de ellas. (No importa cuál sea el momento, generalmente depende de la ranura). El siguiente en la línea es el controlador de interrupción (por ejemplo, PIC/APIC), que decidirá si se confirma la interrupción basándose en los bits de la máscara que se han configurado. sus propios registros. Suponiendo que reconoce la interrupción, o bien obtiene el vector del dispositivo de interrupción (a través de las líneas de bus de datos), o puede, si así está programado, usar un valor 'enlatado' provisto por el propio controlador de dispositivo del APIC. Hasta ahora, la CPU ha sido felizmente consciente de todos estos acontecimientos, pero eso está a punto de cambiar.
Ahora es el momento para que el controlador de interrupción capte la atención del núcleo de la CPU. La CPU tendrá su propio bit de máscara de interrupción que puede hacer que simplemente ignore la solicitud del PIC. Suponiendo que la CPU está lista para tomar interrupciones, es hora de que comience la acción real. La instrucción actual generalmente debe retirarse antes de que el ISR pueda comenzar, por lo que con procesadores enrutados esto es un poco complicado, pero basta decir que en algún punto de la secuencia de instrucciones, el contexto del procesador se guarda en la pila y el hardware -terminó ISR toma el control.
Algunos núcleos de CPU tienen múltiples líneas de solicitud y pueden iniciar el proceso de reducir qué ISR se ejecuta a través de la lógica de hardware que salta el puntero de instrucción de la CPU a uno de un puñado de controladores de nivel superior. El viejo 68K, y posiblemente otros lo hicieron de esa manera. El powerPC (y creo que el x86) tiene una sola entrada de solicitud de interrupción. El x86 en sí mismo se comporta como un PIC, y puede obtener un vector de los PIC externos, pero el powerPC simplemente salta a una dirección fija, 0x00000500.
En el PPC, el código en 0x0500 probablemente salte inmediatamente a algún lugar de la memoria donde haya suficiente espacio para algún código de toma de decisiones serio, pero sigue siendo la rutina de servicio de interrupción. Esa rutina irá primero al PIC y obtendrá el vector, y también le pedirá al PIC que deje de afirmar la solicitud de interrupción en el núcleo de la CPU. Una vez que se conoce el vector, el ISR de nivel superior puede desenmascarar a un controlador más específico que dará servicio a todos los dispositivos conocidos que usan ese vector. El manejador específico de vector luego recorre la lista de dispositivos asignados a ese vector, verificando los bits de estado de interrupción en esos dispositivos, para ver cuáles necesitan servicio.
Cuando se encuentra un dispositivo, como el puerto serie hipotético, que necesita servicio, el ISR de ese dispositivo realiza las acciones apropiadas, por ejemplo, cargando los datos FIFO siguientes de un búfer del sistema operativo en la FIFO de transmisión del puerto. Algunos dispositivos abandonan automáticamente su solicitud de interrupción en respuesta a que se acceda, por ejemplo, escribir un byte en la FIFO de transmisión puede hacer que el dispositivo del puerto en serie restaure la línea de solicitud. Otros dispositivos requerirán un bit de registro de control especial que se activará, establecerá, borrará, lo que tenga, con el fin de eliminar la solicitud. Hay tropecientos de diferentes dispositivos de E/S y no parece que dos de ellos lo hagan de la misma manera, por lo que es difícil generalizar, pero esa es la forma habitual de hacerlo.
Ahora, obviamente, hay más para decir, ¿qué pasa con las prioridades de interrupción? ¿Qué sucede en un procesador multi-core? ¿Qué pasa con los controladores de interrupción anidados? Pero he quemado suficiente espacio en el servidor. Espero que alguno de estos te ayude.
Gracias Jeff. Aunque mi pregunta todavía está allí. Entiendo que hay un número de interrupción utilizado para encontrar ISR. Entonces mi pregunta adicional fue cómo la CPU se suministra con este número. ¿Pasa a través del bus de datos o de qué otro modo? ¿También dónde encajan los APIC en la imagen para los dispositivos que comparten IRQ? Tu publicación fue muy útil para recordarme el uso de los registros de estado del dispositivo. Muchas gracias. –
Buena explicación Jeff. Gracias de nuevo por los esfuerzos. Tenía pensamientos similares, como que podría haber una estructura tipo árbol para manejar interrupciones. Pero ahora sé que los demás también piensan de la misma manera e hiciste un buen comentario sobre esto. Gracias de nuevo. –
Una pequeña pregunta. _Interrumpir vector_ es solo un número que es una entrada a _interrupt vector table_ para obtener la dirección de ISR. Entonces, ¿cómo es un ** Vector **? ** El número de interrupción ** está bien. – Shashwat