Abstracción de hardware

Las abstracciones de hardware son conjuntos de rutinas en software que proporcionan a los programas acceso a recursos de hardware a través de interfaces de programación. La interfaz de programación permite que se pueda acceder a todos los dispositivos de una clase C particular de dispositivos de hardware a través de interfaces idénticas, aunque C pueda contener diferentes subclases de dispositivos que proporcionen cada una una interfaz de hardware diferente.

Las abstracciones de hardware suelen permitir a los programadores escribir aplicaciones de alto rendimiento independientes del dispositivo al proporcionar llamadas estándar del sistema operativo (SO) al hardware. El proceso de abstracción de piezas de hardware se realiza a menudo desde la perspectiva de una CPU . Cada tipo de CPU tiene una arquitectura de conjunto de instrucciones específica o ISA. La ISA representa las operaciones primitivas de la máquina que están disponibles para su uso por parte de programadores de ensamblaje y escritores de compiladores. Una de las principales funciones de un compilador es permitir que un programador escriba un algoritmo en un lenguaje de alto nivel sin tener que preocuparse por las instrucciones específicas de la CPU. Luego, es trabajo del compilador generar un ejecutable específico de la CPU. El mismo tipo de abstracción se realiza en los sistemas operativos, pero las API del SO ahora representan las operaciones primitivas de la máquina, en lugar de una ISA. Esto permite que un programador utilice operaciones a nivel del SO (por ejemplo, creación/eliminación de tareas) en sus programas mientras conserva la portabilidad en una variedad de plataformas diferentes.

Muchos de los primeros sistemas informáticos no tenían ningún tipo de abstracción de hardware. Esto significaba que cualquiera que escribiera un programa para un sistema de este tipo tendría que saber cómo se comunicaba cada dispositivo de hardware con el resto del sistema. Esto suponía un reto importante para los desarrolladores de software, ya que tenían que saber cómo funcionaba cada dispositivo de hardware de un sistema para garantizar la compatibilidad del software . Con la abstracción de hardware, en lugar de que el programa se comunique directamente con el dispositivo de hardware, comunica al sistema operativo lo que debe hacer el dispositivo, que luego genera una instrucción dependiente del hardware para el dispositivo. Esto significaba que los programadores no necesitaban saber cómo funcionaban dispositivos específicos, lo que hacía que sus programas fueran compatibles con cualquier dispositivo.

Un ejemplo de esto podría ser una abstracción de "Joystick". El dispositivo joystick , del cual existen muchas implementaciones físicas, es legible/escribible a través de una API que muchos dispositivos similares a joysticks podrían compartir. La mayoría de los dispositivos joystick podrían informar direcciones de movimiento. Muchos dispositivos joystick podrían tener configuraciones de sensibilidad que pueden ser configuradas por una aplicación externa. Una abstracción de Joystick oculta detalles (por ejemplo, formato de registro, dirección I2C ) del hardware de modo que un programador que use la API abstraída no necesite entender los detalles de la interfaz física del dispositivo. Esto también permite la reutilización de código ya que el mismo código puede procesar mensajes estandarizados de cualquier tipo de implementación que proporcione la abstracción de "joystick". Un "empujón hacia adelante" puede ser de un potenciómetro o de un sensor táctil capacitivo que reconoce gestos de "deslizar", siempre que ambos proporcionen una señal relacionada con el "movimiento".

Como las limitaciones físicas (por ejemplo, la resolución del sensor, la frecuencia de actualización temporal) pueden variar según el hardware, una API puede hacer poco para ocultarlo, salvo asumiendo un modelo de "mínimo común denominador". Por lo tanto, ciertas decisiones arquitectónicas profundas de la implementación pueden volverse relevantes para los usuarios de una instancia particular de una abstracción.

Una buena metáfora es la abstracción del transporte. Tanto la bicicleta como el coche son medios de transporte. Ambos tienen puntos en común (por ejemplo, hay que conducir) y diferencias físicas (por ejemplo, el uso de los pies). Siempre se puede especificar la abstracción "conducir hasta" y dejar que el implementador decida si es mejor ir en bicicleta o conducir un coche. La función de "transporte terrestre sobre ruedas" se abstrae y se encapsulan los detalles de "cómo conducir".

Algunos ejemplos de "abstracciones" en una PC incluyen entrada de video, impresoras, entrada y salida de audio, dispositivos de bloque (por ejemplo, unidades de disco duro o unidades flash USB ), etc.

En ciertos dominios de la informática, como los sistemas operativos o los sistemas integrados, las abstracciones tienen apariencias ligeramente diferentes (por ejemplo, los sistemas operativos tienden a tener interfaces más estandarizadas), pero el concepto de abstracción y encapsulación de la complejidad son comunes y profundos.

La capa de abstracción de hardware reside debajo de la interfaz de programación de aplicaciones (API) en una pila de software, mientras que la capa de aplicación (a menudo escrita en un lenguaje de alto nivel) reside encima de la API y se comunica con el hardware llamando a funciones en la API.

Una capa de abstracción de hardware ( HAL ) es una capa de abstracción , implementada en software, entre el hardware físico de una computadora y el software que se ejecuta en esa computadora. Su función es ocultar las diferencias en el hardware de la mayor parte del núcleo del sistema operativo , de modo que la mayor parte del código en modo núcleo no necesite modificarse para ejecutarse en sistemas con hardware diferente. En Microsoft Windows, HAL puede considerarse básicamente como el controlador de la placa base y permite que las instrucciones de los lenguajes informáticos de nivel superior se comuniquen con los componentes de nivel inferior, pero impide el acceso directo al hardware.

CP/M ( CP/M BIOS ), DOS ( DOS BIOS ), Solaris , Linux , BSD , macOS y algunos otros sistemas operativos portátiles también tienen una HAL, incluso si no está explícitamente designada como tal. Algunos sistemas operativos, como Linux, tienen la capacidad de insertar una mientras se ejecutan, como Adeos . El sistema operativo NetBSD es ampliamente conocido por tener una capa de abstracción de hardware limpia que le permite ser altamente portable. ^[1] Como parte de este sistema están uvm(9)/ pmap(9), y otros subsistemas. Los buses populares que se utilizan en más de una arquitectura también están abstraídos, como ISA , EISA , PCI , PCIebus_space(9) , etc., lo que permite que los controladores también sean altamente portátiles con un mínimo de modificación de código.bus_dma(9)

Los sistemas operativos que tienen una HAL definida son más fáciles de transportar entre distintos tipos de hardware. Esto es especialmente importante para los sistemas integrados que se ejecutan en docenas de plataformas diferentes.

El núcleo de Windows NT tiene una HAL en el espacio del núcleo entre el hardware y los servicios ejecutivos que están contenidos en el archivo NTOSKRNL.EXE ^{[2] [3]} bajo %WINDOWS%\system32\hal.dll . Esto permite la portabilidad del código del modo núcleo de Windows NT a una variedad de procesadores, con diferentes arquitecturas de unidad de administración de memoria y una variedad de sistemas con diferentes arquitecturas de bus de E/S; la mayor parte de ese código se ejecuta sin cambios en esos sistemas, cuando se compila para el conjunto de instrucciones aplicable a esos sistemas. Por ejemplo, las estaciones de trabajo basadas en Intel x86 de SGI no eran estaciones de trabajo compatibles con IBM PC , pero debido a la HAL, Windows 2000 pudo ejecutarse en ellas. ^{[4] [ verificación fallida ]}

Desde Windows Vista y Windows Server 2008 , la HAL utilizada se determina automáticamente durante el inicio . ^[5]

Un ejemplo "extremo" de una HAL se puede encontrar en las arquitecturas System/38 y AS/400 , actualmente implementadas en el sistema operativo IBM i . La mayoría de los compiladores para esos sistemas generan un código de máquina abstracto; el Código Interno Licenciado, o LIC, traduce este código de máquina virtual en código nativo para el procesador en el que se ejecuta y ejecuta el código nativo resultante. ^[6] (Las excepciones son los compiladores que generan el LIC por sí mismos; esos compiladores no están disponibles fuera de IBM). Esto tuvo tanto éxito que el software de aplicación y el software del sistema operativo por encima de la capa LIC que se compilaron en el S/38 original se ejecutan sin modificaciones y sin recompilación en los últimos sistemas AS/400, a pesar del hecho de que el hardware subyacente ha cambiado drásticamente; se han utilizado al menos tres tipos diferentes de procesadores. ^[6]

Android introdujo una interfaz de alto nivel (HAL) conocida como "interfaz de proveedor" (cuyo nombre en código era "Project Treble") en la versión 8.0 "Oreo" . Esta interfaz abstrae el código de bajo nivel del marco del sistema operativo Android y debe hacerse compatible con versiones futuras de Android para facilitar el desarrollo de actualizaciones de firmware. ^[7] Antes de Project Treble, Android dependía de varias HAL heredadas no estandarizadas. ^[8]

Halium es un HAL basado en Android utilizado por varios sistemas operativos móviles como Ubuntu Touch y LuneOS para ejecutarse en teléfonos inteligentes con Android preinstalado.

• Sistema básico de entrada y salida (BIOS)
• Interfaz de firmware extensible unificada (UEFI)
• Firmware
• Interfaz avanzada de configuración y energía (ACPI)
• Árbol de dispositivos
• Paquete de soporte de la placa (BSP)
• Kit de dispositivo
• Kit de dispositivo Haiku
• HAL (programa)
• Software dependiente del hardware (HDS)
• Nanonúcleo
• Picokernel
• Anillo de protección

• "Especificación de computación RISC avanzada" (PDF) . MIPS Technologies . p. 23 . Consultado el 26 de febrero de 2013 .
• Silberschatz, Abraham; Galvin, Peter Bear; Gagne, Greg (2002). Conceptos de sistemas operativos (6.ª ed.). ISBN 0-471-41743-2.