Las implementaciones de BIOS proporcionan interrupciones que los sistemas operativos y los programas de aplicación pueden invocar para utilizar las funciones del firmware en computadoras compatibles con IBM PC [a] . Tradicionalmente, las llamadas al BIOS son utilizadas principalmente por programas DOS y algún otro software como cargadores de arranque (incluido, principalmente históricamente, software de aplicación relativamente simple que arranca directamente y se ejecuta sin un sistema operativo, especialmente software de juegos). El BIOS se ejecuta en el modo de dirección real (modo real) de la CPU x86, por lo que los programas que llaman al BIOS también deben ejecutarse en modo real o deben cambiar del modo protegido al modo real antes de llamar al 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 del BIOS para admitir funciones del sistema, aunque sí usan las llamadas de interrupción del BIOS 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 ) usan el modo irreal o el modo protegido (y ejecutan las llamadas de interrupción del BIOS en el modo Virtual 8086 , pero solo para el arranque del sistema operativo) para acceder hasta 4 GB de memoria. [2]
En todas las computadoras, las instrucciones del software controlan el hardware físico (pantalla, disco, teclado, etc.) desde el momento en que se enciende. En una PC, el BIOS, precargado en la ROM de la placa base, toma el control inmediatamente después de que se reinicia la CPU, incluso durante el encendido, cuando se presiona un botón de reinicio de hardware o cuando se produce una falla crítica de software (una falla triple ). hace que el circuito de la placa base active automáticamente un reinicio del hardware. El BIOS prueba el hardware e inicializa su estado; busca, carga y ejecuta el programa de arranque (normalmente, un cargador de arranque del sistema operativo y una ROM BASIC histórica ); y proporciona control de hardware básico para el software que se ejecuta en la máquina, que suele ser un sistema operativo (con programas de aplicación), pero puede ser una única aplicación de software que arranca directamente.
Por parte de IBM, proporcionaron toda la información necesaria para utilizar su BIOS completamente o para utilizar directamente el hardware y evitar el BIOS por completo, al programar los primeros modelos de PC de IBM (anteriores al PS/2). Desde el principio, los programadores tenían la opción de usar BIOS o no, según el hardware y el periférico. IBM sí recomendó firmemente la autoría de programas "de buen comportamiento" que accedieran al hardware sólo a través de llamadas BIOS INT (y llamadas de servicio DOS), para respaldar la compatibilidad del software con modelos de PC actuales y futuros que tengan hardware periférico diferente, pero IBM entendió que para algunos Para los desarrolladores de software y los clientes de hardware, era un requisito que el software del usuario pudiera controlar directamente el hardware. En parte, esto se debió a que los servicios del BIOS no expusieron un subconjunto importante de todas las características y funciones del hardware. Por dos ejemplos (entre muchos), los adaptadores MDA y CGA son capaces de desplazarse por hardware, y el adaptador serie de PC es capaz de transferir datos mediante interrupciones, pero el BIOS de IBM no admite ninguna de estas útiles características técnicas.
Hoy en día, el BIOS de una PC nueva todavía admite la mayoría, si no todas, las llamadas a funciones de interrupción del BIOS definidas por IBM para IBM AT (introducidas en 1984), junto con muchas más nuevas, además de extensiones a algunos de los originales ( por ejemplo, rangos de parámetros ampliados) promulgados por varias otras organizaciones y grupos industriales colaborativos. Esto, combinado con un grado similar de compatibilidad de hardware, significa que la mayoría de los programas escritos para un IBM AT todavía pueden ejecutarse correctamente en una PC nueva hoy en día, suponiendo que la velocidad de ejecución más rápida sea aceptable (lo que normalmente ocurre para todos los juegos excepto los que usan Temporización basada en CPU). A pesar de las considerables limitaciones de los servicios a los que se accede a través de las interrupciones del BIOS, han demostrado ser extremadamente útiles y duraderos ante el cambio tecnológico.
Las llamadas de interrupción del BIOS realizan control de hardware o funciones de E/S solicitadas por un programa, devuelven información del sistema al programa o hacen ambas cosas. Un elemento clave del propósito de las llamadas al BIOS es la abstracción: las llamadas al BIOS realizan funciones generalmente definidas y los detalles específicos de cómo se ejecutan esas funciones en el hardware particular del sistema están encapsulados en el BIOS y ocultos del programa. Así, por ejemplo, un programa que quiere leer desde un disco duro no necesita saber si el disco duro es una unidad ATA , SCSI o SATA (o antes, una unidad ESDI , o una unidad MFM o RLL con quizás un controlador Seagate ST-506 , quizás uno de los varios tipos de controladores Western Digital o con un controlador propietario diferente de otra marca). El programa sólo necesita identificar el número definido por BIOS de la unidad a la que desea acceder y la dirección del sector que necesita leer o escribir, y el BIOS se encargará de traducir esta solicitud general en la secuencia específica de operaciones elementales requeridas. para completar la tarea a través del hardware del controlador de disco particular que está conectado a esa unidad. El programa se libera de la necesidad de saber controlar a bajo nivel cada tipo de disco duro (o adaptador de pantalla, o 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 hace que los programas sean más pequeños, lo que reduce la duplicación del código del programa, ya que no es necesario incluir la funcionalidad incluida en el BIOS en todos los programas que la necesitan; En su lugar, los programas incluyen llamadas relativamente cortas al BIOS. (En los sistemas operativos donde no se utiliza el BIOS, las llamadas de servicio proporcionadas por el propio sistema operativo generalmente cumplen la misma función y propósito).
El BIOS también libera a los diseñadores de hardware informático (en la medida en que los programas se escriben para utilizar el BIOS exclusivamente) de verse obligados a mantener la compatibilidad exacta del hardware con sistemas antiguos al diseñar sistemas nuevos, a fin de mantener la compatibilidad con el software existente. Por ejemplo, el hardware del teclado en IBM PCjr funciona de manera muy diferente al hardware del teclado en modelos anteriores de IBM PC, pero para los programas que usan el teclado solo a través del BIOS, esta diferencia es casi invisible. (Como un buen ejemplo del otro lado de este problema, una parte significativa de los programas de PC en uso en el momento en que se introdujo el PCjr no usaban el teclado a través del BIOS exclusivamente, por lo que IBM también incluyó funciones de hardware en el PCjr para emular el forma en que funciona el hardware del teclado original de IBM PC e IBM PC XT . 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 del BIOS sí lo harán. .)
Además de brindar acceso a las funciones de hardware, el BIOS proporciona funciones adicionales que se implementan en el software del BIOS. Por ejemplo, el BIOS mantiene posiciones separadas del cursor para hasta ocho páginas de visualización de texto y proporciona salida tipo TTY con ajuste automático de línea e interpretación de caracteres de control básicos como retorno de carro y avance de línea, mientras que el hardware de visualización de texto compatible con CGA tiene solo un cursor de visualización global y no puede hacer avanzar automáticamente el cursor, usar la posición del cursor para direccionar la memoria de visualización (para determinar qué celda de carácter se cambiará o examinará) o interpretar caracteres de control. Para otro ejemplo, la interfaz del teclado del BIOS interpreta muchas pulsaciones de teclas y combinaciones de teclas para realizar un seguimiento de los distintos estados de cambio ( Shift izquierdo y derecho , Ctrl y Alt ), para llamar al servicio de impresión de pantalla cuando se presiona Shift + PrtScrn , para reiniciar. el sistema cuando se presiona Ctrl + Alt + Supr , para realizar un seguimiento de los estados de bloqueo (Bloqueo de mayúsculas, Bloqueo numérico y Bloqueo de desplazamiento) y, en máquinas de clase AT, controlar las luces indicadoras de estado de bloqueo correspondientes en el teclado, y para realizar otras funciones similares de interpretación y gestión del teclado. En contraste, las capacidades ordinarias del hardware de teclado PC y PC-AT estándar se limitan a informar al sistema cada evento primitivo de una tecla individual presionada o liberada (es decir, hacer una transición del estado "liberado" al estado "presionado"). estado de bloqueo o viceversa), realizar un reinicio ordenado y una autoprueba de la unidad de teclado y, para teclados de clase AT, ejecutar un comando desde el sistema host para establecer los estados absolutos de los indicadores de estado de bloqueo (LED).
Los sistemas operativos y otro software se comunican con el software BIOS para controlar el hardware instalado mediante interrupciones de software. Una interrupción de software es una variedad específica del concepto general de interrupción. Una interrupción es un mecanismo mediante el cual se puede ordenar a la CPU que deje de ejecutar el programa de línea principal y ejecute inmediatamente un programa especial, llamado Rutina de servicio de interrupción (ISR). Una vez que finaliza el ISR, la CPU continúa con el programa principal. En las CPU x86, cuando se produce una interrupción, el ISR a llamar se encuentra buscándolo en una tabla de direcciones de punto de inicio de ISR (llamadas "vectores de interrupción") en la memoria: la tabla de vectores de interrupción (IVT). Una interrupción se invoca por su número de tipo, de 0 a 255, y el número de tipo se utiliza como índice en la tabla de vectores de interrupción, y en ese índice en la tabla se encuentra la dirección del ISR que se ejecutará en respuesta a la interrupción. Una interrupción de software es simplemente una interrupción provocada por un comando de software; por lo tanto, las interrupciones de software funcionan como subrutinas, con la principal diferencia de que el programa que realiza una llamada de interrupción de software no necesita conocer la dirección del ISR, sólo su número de interrupción. Esto tiene ventajas de modularidad, compatibilidad y flexibilidad en la configuración del sistema.
Las llamadas de interrupción del BIOS pueden considerarse como un mecanismo para pasar mensajes entre el BIOS y el software cliente del BIOS, como un sistema operativo. Los mensajes solicitan datos o acciones del BIOS y devuelven los datos solicitados, la información de estado y/o el producto de la acción solicitada a la persona que llama. 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 BIOS pasa la mayor parte de la información al BIOS en los registros de la CPU y recibe la mayor parte de la información de la misma manera, pero los datos demasiado grandes para caber en los registros, como tablas de parámetros de control o datos del sector del 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 registros. (A veces se pueden pasar múltiples 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 al BIOS en registros). El número de interrupción se especifica como el parámetro de la instrucción de interrupción del software (en lenguaje ensamblador Intel , una instrucción "INT") y el número de función se especifica en el registro AH; es decir, la persona que llama establece el registro AH en el número de la función deseada. En general, los servicios del BIOS correspondientes a cada número de interrupción funcionan de forma independiente entre sí, pero las funciones dentro de un servicio de interrupción son manejadas por el mismo programa del BIOS y no son independientes. (Este último punto es relevante para la reentrada ).
El software BIOS generalmente regresa a la persona que llama con un código de error si no tiene éxito, o con un código de estado y/o datos solicitados si tiene éxito. Los datos en sí 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). El BIOS ha sido ampliado y mejorado a lo largo de los años muchas veces por muchas entidades corporativas diferentes y, desafortunadamente, el resultado de esta evolución es que no todas las funciones del BIOS que se pueden llamar utilizan convenciones consistentes para formatear y comunicar datos o para informar resultados. Algunas funciones del BIOS brindan información detallada sobre el estado, mientras que otras pueden ni siquiera informar sobre el éxito o el fracaso, sino que simplemente regresan en silencio, dejando que la persona que llama asuma el éxito (o pruebe el resultado de alguna otra manera). A veces también puede ser difícil determinar si una determinada llamada de función del BIOS es compatible con el BIOS de una determinada computadora, o cuáles son los límites de los parámetros de una llamada en esa computadora. (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 anterior del BIOS de IBM, es posible que el BIOS no haga nada y regrese sin código de error; entonces es responsabilidad [inconveniente pero inevitable] del persona que llama para evitar este caso al no realizar tales llamadas, o para probar positivamente un efecto esperado de la llamada en lugar de asumir que la llamada fue efectiva. Debido a que BIOS ha evolucionado ampliamente en muchos pasos a lo largo de su historia, una función que es válida en. una versión de BIOS de un determinado proveedor puede no ser válida en una versión de BIOS anterior o divergente del mismo proveedor o en una versión de BIOS (de cualquier antigüedad relativa) de un proveedor diferente).
Debido a que las llamadas de interrupción del BIOS utilizan el paso de parámetros basado en registros de la CPU, las llamadas están orientadas a realizarse 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 contenedoras que traducen parámetros del formulario (generalmente basado en pila) utilizado por el lenguaje de alto nivel al formulario basado en registros requerido por BIOS, y luego regresan a la convención de llamada HLL después. el BIOS regresa. En algunas variantes de C, las llamadas al BIOS se pueden realizar utilizando lenguaje ensamblador en línea dentro de un módulo C. (La compatibilidad con el lenguaje ensamblador en línea no es parte del estándar ANSI C, pero es una extensión del lenguaje; por lo tanto, los módulos C que usan lenguaje ensamblador en línea son menos portátiles que los módulos C estándar ANSI puro).
Se puede invocar una interrupción utilizando la instrucción en lenguaje ensamblador INT x86 . Por ejemplo, para imprimir un carácter en la pantalla usando la interrupción del BIOS 0x10, se podrían ejecutar las siguientes instrucciones en lenguaje ensamblador x86:
movah , 0x0e ; número de función = 0Eh: Mostrar carácter mov al , '!' ; AL = código de carácter a mostrar int 0x10 ; llamada INT 10h, servicio de video BIOS A continuación se puede encontrar una lista de clases de interrupciones de BIOS comunes. Algunos BIOS (particularmente los más antiguos) no implementan todas estas clases de interrupción.
El BIOS también utiliza algunas interrupciones para transmitir interrupciones de eventos de hardware a programas que eligen recibirlas o enrutar mensajes para su propio uso.
INT 18hTradicionalmente se saltaba a una implementación de Cassette BASIC (proporcionada por Microsoft) almacenada en ROM opcionales . Esta llamada normalmente se invocaría si el BIOS no pudiera identificar ningún volumen de disco de arranque durante el inicio.
Cuando se lanzó la PC IBM original (máquina IBM tipo 5150) en 1981, el BASIC en ROM era una característica clave. Las computadoras personales populares contemporáneas, como la Commodore 64 y la línea Apple II, también tenían Microsoft Cassette BASIC en ROM (aunque Commodore cambió el nombre de su versión con licencia Commodore BASIC), por lo que en una parte sustancial de su mercado previsto, la PC IBM necesitaba BASIC para competir. Al igual que en esos otros sistemas, la ROM BASIC de la PC IBM sirvió como un sistema operativo primitivo sin disco, que permitía al usuario cargar, guardar y ejecutar programas, así como escribirlos y perfeccionarlos. (La IBM PC original también fue el único modelo de PC de IBM que, al igual que sus dos competidores antes mencionados, incluía hardware de interfaz de casete. Un modelo base de IBM PC tenía sólo 16 KiB de RAM y no tenía unidades de disco de ningún tipo, por lo que la interfaz de casete y BASIC en ROM era esencial para que el modelo base fuera utilizable. Una PC IBM con menos de 32 KiB de RAM no puede arrancar desde el disco. De los cinco chips ROM de 8 KiB en una PC IBM original, con un total de 40 KiB, cuatro contienen BASIC y. solo uno contiene el BIOS; cuando solo se instalan 16 KiB de RAM, la ROM BASIC representa 4/7 de la memoria total del sistema).
A medida que pasó el tiempo y BASIC ya no se envió a todas las PC, esta interrupción simplemente mostraría un mensaje de error indicando que no se encontró ningún volumen de arranque (como "No hay ROM BASIC" o mensajes más explicativos en versiones posteriores del BIOS); en otras versiones de BIOS, le pediría al usuario que insertara un volumen de arranque y presionara una tecla, y luego, después de que el usuario presionara una tecla, regresaría al cargador de arranque (INT 19h) para intentar arrancar nuevamente.
El Rainbow 100 B de Digital INT 18hsolía llamar a su BIOS, que era incompatible con la BIOS de IBM. Turbo Pascal , Turbo C y Turbo C++ reutilizaron INT 18 para asignación de memoria y paginación. Otros programas también reutilizaron este vector para sus propios fines.
En sistemas DOS, IO.SYS o IBMBIO.COM conectan INT 13 para la detección de cambios de disquete, el seguimiento de llamadas de formato, la corrección de errores de límites de DMA y la solución de problemas en la BIOS ROM "01/10/84" de IBM con el código de modelo 0xFC antes del primera llamada.
Muchos sistemas operativos modernos (como Linux y Windows ) no utilizan ninguna llamada de interrupción del BIOS después del inicio, sino que optan por interactuar directamente con el hardware. Para hacer esto, dependen de controladores que forman parte del propio kernel del sistema operativo , se envían junto con el sistema operativo o son proporcionados por proveedores de hardware.
Hay varias razones para esta práctica. Lo más significativo es que los sistemas operativos modernos se ejecutan con el procesador en modo protegido (o largo ), mientras que el código BIOS sólo se ejecutará en modo real . Esto significa que si un sistema operativo que se ejecuta en modo protegido quisiera realizar una llamada al BIOS, primero tendría que cambiar al modo real, luego ejecutar la llamada y esperar a que regrese, y finalmente volver al modo protegido. Esto sería terriblemente lento e ineficiente. El código que se ejecuta en modo real (incluido el 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, el BIOS generalmente no es la forma más rápida de realizar una tarea en particular. De hecho, las limitaciones de velocidad del BIOS hicieron que fuera común incluso en la era DOS que los programas lo eludieran para evitar sus limitaciones de rendimiento, especialmente para la visualización de gráficos de video y la comunicación serial rápida.
Más allá de los factores anteriores, los problemas con la funcionalidad del BIOS incluyen limitaciones en la gama de funciones definidas, inconsistencia en los subconjuntos de funciones admitidas en diferentes computadoras y variaciones en la calidad de los BIOS (es decir, algunos BIOS son completos y confiables, otros son abreviados y calesa). Al tomar el asunto en sus propias manos y evitar depender del BIOS, los desarrolladores de sistemas operativos pueden eliminar algunos de los riesgos y complicaciones que enfrentan al escribir y respaldar el software del sistema. Por otro lado, al hacerlo, esos desarrolladores se vuelven responsables de proporcionar software de controlador "básico" para cada sistema o dispositivo periférico diferente con el que pretenden que funcione su sistema operativo (o de inducir a los productores de hardware a proporcionar esos controladores).
Por lo tanto, debería ser evidente que los sistemas operativos compactos desarrollados con presupuestos pequeños tenderían a utilizar BIOS en gran medida, mientras que los sistemas operativos grandes creados por grandes grupos de ingenieros de software con grandes presupuestos optarían más a menudo por escribir sus propios controladores en lugar de utilizar BIOS. , incluso sin considerar los problemas de compatibilidad de BIOS y modo protegido.