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 de 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.

Many modern operating systems (such as Linux and Windows) do not use any BIOS interrupt calls at all after startup, instead choosing to directly interface with the hardware. To do this, they rely upon drivers that are either a part of the OS kernel itself, ship along with the OS, or are provided by hardware vendors.

There are several reasons for this practice. Most significant is that modern operating systems run with the processor in protected (or long) mode, whereas the BIOS code will only execute in real mode. This means that if an OS running in protected mode wanted to make a BIOS call, it would have to first switch into real mode, then execute the call and wait for it to return, and finally switch back to protected mode. This would be terribly slow and inefficient. Code that runs in real mode (including the BIOS) is limited to accessing just over 1 MiB of memory, due to using 16-bit segmented memory addressing. Additionally, the BIOS is generally not the fastest way to carry out any particular task. In fact, the speed limitations of the BIOS made it common even in the DOS era for programs to circumvent it in order to avoid its performance limitations, especially for video graphics display and fast serial communication.

Beyond the above factors, problems with BIOS functionality include limitations in the range of functions defined, inconsistency in the subsets of those functions supported on different computers, and variations in the quality of BIOSes (i.e. some BIOSes are complete and reliable, others are abridged and buggy). By taking matters into their own hands and avoiding reliance on BIOS, operating system developers can eliminate some of the risks and complications they face in writing and supporting system software. On the other hand, by doing so those developers become responsible for providing "bare-metal" driver software for every different system or peripheral device they intend for their operating system to work with (or for inducing the hardware producers to provide those drivers).

Thus it should be apparent that compact operating systems developed on small budgets would tend to use BIOS heavily, while large operating systems built by huge groups of software engineers with large budgets would more often opt to write their own drivers instead of using BIOS—that is, even without considering the compatibility problems of BIOS and protected mode.

• DOS interrupt call
• Interrupt descriptor table
• Ralf Brown's Interrupt List
• 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