Llamada de interrupción de BIOS

Las implementaciones de BIOS proporcionan interrupciones que pueden ser invocadas por sistemas operativos y programas de aplicación para usar las funciones del firmware en computadoras compatibles con IBM PC ^{[ a ]} . Tradicionalmente, las llamadas a BIOS son utilizadas principalmente por programas DOS y algún otro software como cargadores de arranque (incluyendo, históricamente, software de aplicación relativamente simple que arranca directamente y se ejecuta sin un sistema operativo , especialmente software de juegos). BIOS se ejecuta en el modo de dirección real (Modo Real) de la CPU x86, por lo que los programas que llaman a BIOS también deben ejecutarse en modo real o deben cambiar del modo protegido al modo real antes de llamar a BIOS y luego volver a cambiar. Por esta razón, los sistemas operativos modernos que usan la CPU en modo protegido o modo largo generalmente no usan las llamadas de interrupción de BIOS para admitir funciones del sistema, aunque sí las usan para sondear e inicializar el hardware durante el arranque . ^{[ 1 ]} El modo real tiene una limitación de memoria de 1 MB; los cargadores de arranque modernos (por ejemplo, GRUB2 , Windows Boot Manager ) utilizan el modo irreal o el modo protegido (y ejecutan las llamadas de interrupción de la BIOS en el modo Virtual 8086 , pero solo para el arranque del sistema operativo) para acceder hasta 4 GB de memoria. ^{[ 2 ]}

En todos los ordenadores, las instrucciones de software controlan el hardware físico (pantalla, disco, teclado, etc.) desde el momento en que se encienden. En un PC, la BIOS, precargada en la ROM de la placa base, toma el control inmediatamente después de que se reinicie la CPU, incluso durante el encendido, cuando se pulsa un botón de reinicio de hardware o cuando un fallo crítico de software (un fallo triple ) provoca que los circuitos de la placa base activen automáticamente un reinicio de hardware. La BIOS prueba el hardware e inicializa su estado; encuentra, carga y ejecuta el programa de arranque (normalmente, un cargador de arranque del sistema operativo y el antiguo BASIC de la ROM ); y proporciona control básico del hardware al software que se ejecuta en la máquina, que normalmente es un sistema operativo (con programas de aplicación), pero también puede ser una única aplicación de software de arranque directo.

Por su parte, IBM proporcionó toda la información necesaria para usar su BIOS por completo o para utilizar directamente el hardware y evitarlo totalmente al programar los primeros modelos de IBM PC (anteriores al PS/2). Desde el principio, los programadores podían elegir entre usar o no la BIOS, según el periférico de hardware. IBM fomentó encarecidamente la creación de programas "correctos" que accedieran al hardware únicamente mediante llamadas INT de la BIOS (y llamadas de servicio de DOS), para garantizar la compatibilidad del software con los modelos de PC actuales y futuros con periféricos de hardware diferentes. Sin embargo, IBM comprendió que para algunos desarrolladores de software y clientes de hardware, la capacidad de que el software de usuario controlara directamente el hardware era un requisito. Esto se debía, en parte, a que un subconjunto significativo de todas las características y funciones del hardware no estaba disponible a través de los servicios de la BIOS. Por ejemplo, los adaptadores MDA y CGA permiten el desplazamiento por hardware, y el adaptador serie del PC permite la transferencia de datos mediante interrupciones, pero la BIOS de IBM no admite ninguna de estas útiles funciones técnicas.

Actualmente, la BIOS de un PC moderno sigue siendo compatible con la mayoría, si no con todas, las llamadas a funciones de interrupción definidas por IBM para el IBM AT (introducido en 1984), además de muchas otras más recientes y extensiones a algunas de las originales (por ejemplo, rangos de parámetros ampliados) propuestas por diversas organizaciones y grupos de colaboración del sector. Esto, sumado a un grado similar de compatibilidad de hardware, significa que la mayoría de los programas escritos para un IBM AT pueden ejecutarse correctamente en un PC moderno, siempre que la mayor velocidad de ejecución sea aceptable (lo cual suele serlo, excepto en juegos que utilizan la temporización de la CPU). A pesar de las considerables limitaciones de los servicios a los que se accede mediante las interrupciones de la BIOS, estas han demostrado ser extremadamente útiles y resistentes a los cambios tecnológicos.

Las llamadas de interrupción de la BIOS realizan funciones de control de hardware o de E/S solicitadas por un programa, devuelven información del sistema al programa o ambas cosas. Un elemento clave del propósito de las llamadas de la BIOS es la abstracción de " caja negra ": las llamadas de la BIOS realizan funciones definidas de forma general, y los detalles específicos de cómo se ejecutan esas funciones en el hardware particular del sistema están encapsulados en la BIOS y ocultos para el programa. Así, por ejemplo, un programa que desea leer de un disco duro no necesita saber si el disco duro es una unidad ATA , SCSI o SATA (o, en épocas anteriores, una unidad ESDI , o una unidad MFM o RLL con un controlador Seagate ST-506 , quizás uno de los varios tipos de controladores de Western Digital , o con un controlador propietario diferente de otra marca). El programa solo necesita identificar el número de la unidad definida por la BIOS al que desea acceder y la dirección del sector que necesita leer o escribir, y la BIOS se encargará de traducir esta solicitud general en la secuencia específica de operaciones elementales necesarias para completar la tarea a través del hardware del controlador de disco particular conectado a esa unidad. El programa queda liberado de la necesidad de controlar a bajo nivel cada tipo de disco duro (o adaptador de pantalla, interfaz de puerto o periférico de reloj en tiempo real) al que pueda necesitar acceder. Esto facilita la programación de sistemas operativos y aplicaciones, y reduce el tamaño de los programas, disminuyendo la duplicación de código, ya que la funcionalidad incluida en la BIOS no necesita estar presente en todos los programas que la requieren; en su lugar, se incluyen llamadas relativamente cortas a la BIOS. (En los sistemas operativos donde no se utiliza la BIOS, las llamadas de servicio proporcionadas por el propio sistema operativo generalmente cumplen la misma función).

La BIOS también libera a los diseñadores de hardware (en la medida en que los programas se escriben para usar la BIOS exclusivamente) de la obligación de mantener una compatibilidad exacta con sistemas antiguos al diseñar sistemas nuevos, para así mantener la compatibilidad con el software existente. Por ejemplo, el hardware del teclado del IBM PCjr funciona de forma muy diferente al de los modelos anteriores de IBM PC, pero para los programas que usan el teclado solo a través de la BIOS, esta diferencia es prácticamente imperceptible. (Como buen ejemplo de la otra cara de la moneda, una parte importante de los programas de PC en uso cuando se lanzó el PCjr no usaban el teclado exclusivamente a través de la BIOS, por lo que IBM también incluyó funciones de hardware en el PCjr para emular el funcionamiento del teclado del IBM PC y el IBM PC XT originales . La emulación del hardware no es exacta, por lo que no todos los programas que intentan usar el hardware del teclado directamente funcionarán correctamente en el PCjr, pero todos los programas que usan solo los servicios de teclado de la BIOS sí lo harán).

Además de brindar acceso a las funciones de hardware, la BIOS proporciona funciones adicionales implementadas en su software. Por ejemplo, la BIOS mantiene posiciones de cursor independientes para hasta ocho páginas de visualización de texto y ofrece una salida similar a la de una terminal (TTY) con ajuste de línea automático e interpretación de caracteres de control básicos como retorno de carro y salto de línea. En cambio, el hardware de visualización de texto compatible con CGA solo tiene un cursor global y no puede avanzarlo automáticamente, usar la posición del cursor para acceder a la memoria de visualización (para determinar qué celda de caracteres se modificará o examinará) ni interpretar caracteres de control. Otro ejemplo es la interfaz de teclado de la BIOS, que interpreta numerosas pulsaciones y combinaciones de teclas para controlar los distintos estados de las teclas Mayús izquierda y derecha , Ctrl y Alt , llamar al servicio de captura de pantalla al pulsar Mayús + Impr Pant , reiniciar el sistema al pulsar Ctrl + Alt + Supr , controlar los estados de bloqueo (Bloq Mayús, Bloq Num y Bloq Despl) y, en máquinas de clase AT, controlar los indicadores luminosos de bloqueo correspondientes en el teclado, además de realizar otras funciones de interpretación y gestión similares para el teclado. En cambio, las capacidades habituales del hardware de teclado estándar de PC y PC-AT se limitan a informar al sistema de cada evento primitivo de pulsación o liberación de una tecla individual (es decir, la transición del estado "liberado" al estado "pulsado" o viceversa), realizar un reinicio y una autocomprobación ordenados de la unidad de teclado y, en el caso de los teclados de clase AT, ejecutar un comando del sistema anfitrión para establecer los estados absolutos de los indicadores de estado de bloqueo (LED).

Los sistemas operativos y otros programas se comunican con el software BIOS para controlar el hardware instalado mediante interrupciones de software. Una interrupción de software es una variante específica del concepto general de interrupción. Una interrupción es un mecanismo mediante el cual se puede ordenar a la CPU que detenga la ejecución del programa principal y ejecute inmediatamente un programa especial, denominado Rutina de Servicio de Interrupción (ISR). Una vez finalizada la ISR, la CPU continúa con el programa principal. En las CPU x86, cuando se produce una interrupción, la ISR que se debe llamar se encuentra buscándola en una tabla de direcciones de punto de inicio de ISR (denominadas "vectores de interrupción") en la memoria: la tabla de vectores de interrupción (IVT). Una interrupción se invoca mediante su número de tipo, del 0 al 255, y este número de tipo se utiliza como índice en la Tabla de Vectores de Interrupción, y en ese índice de la tabla se encuentra la dirección de la ISR que se ejecutará en respuesta a la interrupción. Una interrupción de software es simplemente una interrupción que se activa mediante un comando de software. Por lo tanto, las interrupciones de software funcionan como subrutinas, con la principal diferencia de que el programa que realiza la llamada a la interrupción no necesita conocer la dirección de la rutina de servicio de interrupción (ISR), sino solo su número de interrupción. Esto ofrece ventajas en cuanto a modularidad, compatibilidad y flexibilidad en la configuración del sistema.

Las llamadas de interrupción de la BIOS pueden considerarse un mecanismo para pasar mensajes entre la BIOS y el software cliente de la BIOS, como un sistema operativo. Los mensajes solicitan datos o acciones a la BIOS y devuelven los datos solicitados, información de estado y/o el producto de la acción solicitada al emisor. Los mensajes se dividen en categorías, cada una con su propio número de interrupción, y la mayoría de las categorías contienen subcategorías, llamadas "funciones" e identificadas por "números de función". Un cliente de la BIOS pasa la mayor parte de la información a la BIOS en los registros de la CPU y recibe la mayor parte de la información de vuelta de la misma manera, pero los datos demasiado grandes para caber en los registros, como las tablas de parámetros de control o los datos de sectores de disco para transferencias de disco, se pasan asignando un búfer (es decir, algo de espacio) en la memoria y pasando la dirección del búfer en los registros. (A veces, se pueden pasar varias direcciones de elementos de datos en la memoria en una estructura de datos en la memoria, y la dirección de esa estructura se pasa a la BIOS en los registros). El número de interrupción se especifica como el parámetro de la instrucción de interrupción de software (en lenguaje ensamblador de Intel, una instrucción "INT"), y el número de función se especifica en el registro AH; Es decir, quien realiza la llamada establece el registro AH al número de la función deseada. En general, los servicios de la BIOS correspondientes a cada número de interrupción operan de forma independiente, pero las funciones dentro de un mismo servicio de interrupción son gestionadas por el mismo programa de la BIOS y no son independientes. (Este último punto es relevante para la reentrada ).

El software BIOS generalmente devuelve un código de error si la operación no se realiza correctamente, o un código de estado y/o los datos solicitados si se realiza correctamente. Los datos pueden ser tan pequeños como un bit o tan grandes como 65.536 bytes de sectores de disco completos (el máximo que cabe en un segmento de memoria en modo real). BIOS se ha ampliado y mejorado a lo largo de los años por diversas empresas, y lamentablemente, como resultado de esta evolución, no todas las funciones BIOS utilizan convenciones consistentes para formatear y comunicar datos o informar resultados. Algunas funciones BIOS informan información detallada sobre el estado, mientras que otras ni siquiera informan si la operación fue exitosa o fallida, sino que simplemente devuelven un mensaje, dejando que la empresa que realiza la llamada asuma el éxito (o que compruebe el resultado de otra manera). A veces también puede ser difícil determinar si una llamada a una función BIOS específica es compatible con la BIOS de un ordenador determinado, o cuáles son los límites de los parámetros de la llamada en ese ordenador. (Para algunos números de función no válidos, o números de función válidos con valores no válidos de parámetros clave —particularmente con una versión antigua de la BIOS de IBM— la BIOS puede no hacer nada y no devolver ningún código de error; entonces es responsabilidad [inconveniente pero inevitable] del programa que realiza la llamada evitar este caso no realizando dichas llamadas, o comprobar positivamente el efecto esperado de la llamada en lugar de asumir que la llamada fue efectiva. Dado que la BIOS ha evolucionado extensamente en múltiples etapas a lo largo de su historia, una función que es válida en una versión de BIOS de un proveedor determinado puede no ser válida en una versión anterior o divergente de la misma BIOS o en una versión de BIOS —de cualquier antigüedad relativa— de un proveedor diferente).

Debido a que las llamadas de interrupción de la BIOS utilizan el paso de parámetros basado en registros de la CPU, están diseñadas para ejecutarse desde lenguaje ensamblador y no pueden realizarse directamente desde la mayoría de los lenguajes de alto nivel (HLL). Sin embargo, un lenguaje de alto nivel puede proporcionar una biblioteca de rutinas de envoltura que traducen los parámetros del formato (generalmente basado en pila) utilizado por el lenguaje de alto nivel al formato basado en registros requerido por la BIOS, y luego de vuelta a la convención de llamada del HLL una vez que la BIOS finaliza. En algunas variantes de C, las llamadas a la BIOS pueden realizarse utilizando lenguaje ensamblador en línea dentro de un módulo C. (La compatibilidad con el lenguaje ensamblador en línea no forma parte del estándar ANSI C, sino que es una extensión del lenguaje; por lo tanto, los módulos C que utilizan lenguaje ensamblador en línea son menos portátiles que los módulos C que cumplen con el estándar ANSI).

mov ah , 0x0e ; número de función = 0Eh: Mostrar carácter mov al , '!' ; AL = código del carácter a mostrar int 0x10 ; llamar a INT 10h, servicio de vídeo BIOS

A continuación se muestra una lista de las clases de interrupción más comunes de la BIOS. Algunas BIOS (sobre todo las más antiguas) no implementan todas estas clases de interrupción.

La BIOS también utiliza algunas interrupciones para transmitir interrupciones de eventos de hardware a los programas que deciden recibirlas o para enrutar mensajes para su propio uso.

INT 18hTradicionalmente, se recurría a una implementación de Cassette BASIC (proporcionada por Microsoft) almacenada en las ROM de opciones . Esta llamada se invocaba normalmente si la BIOS no podía identificar ningún volumen de disco de arranque al iniciar el sistema.

Cuando se lanzó el primer IBM PC (modelo 5150) en 1981, el BASIC en ROM era una característica clave. Los ordenadores personales populares de la época, como el Commodore 64 y la línea Apple II, también incluían Microsoft Cassette BASIC en ROM (aunque Commodore renombró su versión con licencia como Commodore BASIC), por lo que, en una parte sustancial de su mercado objetivo, el IBM PC necesitaba BASIC para competir. Al igual que en esos otros sistemas, el BASIC en ROM del IBM PC funcionaba como un sistema operativo primitivo sin disco, que permitía al usuario cargar, guardar y ejecutar programas, así como escribirlos y perfeccionarlos. (El IBM PC original fue también el único modelo de PC de IBM que, al igual que sus dos competidores mencionados anteriormente, incluía hardware de interfaz de casete. Un modelo básico de IBM PC tenía solo 16 KiB de RAM y carecía de unidades de disco de cualquier tipo, por lo que la interfaz de casete y BASIC en ROM eran esenciales para que el modelo básico fuera utilizable. Un IBM PC con menos de 32 KiB de RAM es incapaz de arrancar desde un disco. De los cinco chips ROM de 8 KiB en un IBM PC original, que suman un total de 40 KiB, cuatro contienen BASIC y solo uno contiene la BIOS; cuando solo se instalan 16 KiB de RAM, el BASIC en ROM representa 4/7 partes de la memoria total del sistema).

Con el paso del tiempo, y dado que BASIC dejó de venir incluido en todos los PC, esta interrupción simplemente mostraba un mensaje de error que indicaba que no se había encontrado ningún volumen de arranque (como "No ROM BASIC" o mensajes más explicativos en versiones posteriores de la BIOS); en otras versiones de la BIOS, solicitaba al usuario que insertara un volumen de arranque y pulsara una tecla, y después de que el usuario pulsara una tecla, volvía al cargador de arranque (INT 19h) para intentar arrancar de nuevo.

El procesador Rainbow 100 B de Digital INT 18hutilizaba su BIOS, que era incompatible con la BIOS de IBM. Turbo Pascal , Turbo C y Turbo C++ reutilizaron la instrucción INT 18 para la asignación de memoria y la paginación. Otros programas también reutilizaron este vector para sus propios fines.

Muchos sistemas operativos modernos (como Linux y Windows ) no utilizan ninguna llamada de interrupción de la BIOS después del arranque, sino que optan por interactuar directamente con el hardware. Para ello, dependen de controladores que forman parte del núcleo del sistema operativo , se distribuyen junto con este o son proporcionados por los fabricantes de hardware.

Existen varias razones para esta práctica. La más importante es que los sistemas operativos modernos se ejecutan con el procesador en modo protegido (o de larga duración ), mientras que el código de la BIOS solo se ejecuta en modo real . Esto significa que si un sistema operativo que se ejecuta en modo protegido quisiera realizar una llamada a la BIOS, primero tendría que cambiar al modo real, luego ejecutar la llamada y esperar su respuesta, y finalmente volver al modo protegido. Esto sería extremadamente lento e ineficiente. El código que se ejecuta en modo real (incluida la BIOS) está limitado a acceder a poco más de 1 MiB de memoria, debido al uso de direccionamiento de memoria segmentada de 16 bits . Además, la BIOS generalmente no es la forma más rápida de realizar ninguna tarea en particular. De hecho, las limitaciones de velocidad de la BIOS hicieron que fuera común, incluso en la era de DOS, que los programas la eludieran para evitar sus limitaciones de rendimiento, especialmente para la visualización de gráficos de video y la comunicación serial rápida.

Además de los factores mencionados, los problemas con la funcionalidad de la BIOS incluyen limitaciones en el rango de funciones definidas, inconsistencias en los subconjuntos de dichas funciones compatibles con diferentes equipos y variaciones en la calidad de las BIOS (es decir, algunas BIOS son completas y fiables, mientras que otras son incompletas y presentan errores). Al tomar el control y evitar depender de la BIOS, los desarrolladores de sistemas operativos pueden eliminar algunos de los riesgos y complicaciones que enfrentan al escribir y dar soporte al software del sistema. Por otro lado, al hacerlo, dichos desarrolladores se hacen responsables de proporcionar software de controlador "bare-metal" para cada sistema o dispositivo periférico con el que pretenden que funcione su sistema operativo (o de persuadir a los fabricantes de hardware para que proporcionen dichos controladores).

Por lo tanto, debería ser evidente que los sistemas operativos compactos desarrollados con presupuestos reducidos tenderían a utilizar mucho la BIOS, mientras que los sistemas operativos grandes, creados por enormes grupos de ingenieros de software con grandes presupuestos, optarían con mayor frecuencia por escribir sus propios controladores en lugar de utilizar la BIOS , incluso sin tener en cuenta los problemas de compatibilidad de la BIOS y el modo protegido.

• Llamada de interrupción de DOS
• Tabla de descriptores de interrupción
• Lista de interrupciones de Ralf Brown
• INT 10H
• INT 13H
• INT 16H

• La lista de interrupciones x86 (también conocida como RBIL, lista de interrupciones de Ralf Brown)
• Manual del usuario de la BIOS integrada
• Manual del usuario de PhoenixBIOS 4.0
• Referencia técnica de la interfaz BIOS del IBM Personal System/2 y del ordenador personal , IBM, 1988, OCLC 20737442 
• BIOS del sistema para PC, compatibles y ordenadores EISA de IBM , Phoenix Technologies , 1991, ISBN 0201577607
• Guía del programador para AMIBIOS , American Megatrends , 1993, ISBN 0070015619
• El libro de referencia para programadores de PC, de Thom Hogan, Microsoft Press, 1991 ISBN 155615321X