View source for Hardware abstraction

{{short description |Software that hides details of hardware access}}
{{redirect |Hardware Abstraction Layer |the UNIX-like operating system subsystem |HAL (software)}}
{{Use dmy dates |date=March 2023}}
A '''hardware abstraction''' is [[software]] that provides access to [[Computer hardware |hardware]] in a way that hides details that might otherwise make using the hardware difficult. Typically, access is provided via an [[Interface (computing)|interface]] that allows devices that share a level of compatibility to be accessed via the same software interface even though the devices provide different hardware interfaces. A hardware abstraction can support the development of [[cross-platform]] [[application software |applications]]. 

Early software was developed without a hardware abstraction which required a developer to understand multiple devices in order to provide [[computer compatibility |compatibility]]. With hardware abstraction, the software leverages the abstraction to access significantly different hardware via the same interface. The abstraction (often implemented in the [[operating system]]) which then generates hardware-dependent instructions. This allows software to be compatible with all devices supported by the abstraction.

Consider the [[joystick]] device, of which there are many physical implementations. It could be accessible via an [[application programming interface]] (API) that support many different joysticks to support common operations such as moving, firing, configuring sensitivity and so on. A Joystick abstraction hides details (e.g., register format, [[I2C]] address) so that a programmer using the abstraction, does not need to understand the details of the device's physical interface. This also allows [[code reuse]] since the same code can process standardized messages from any kind of implementation which supplies the joystick abstraction. For example, a "nudge forward" can be from a [[potentiometer]] or from a capacitive touch sensor that recognizes "swipe" gestures, as long as they both provide a signal related to "movement".

As physical limitations may vary with hardware, an API can do little to hide that, other than by assuming a "least common denominator" model. Thus, certain deep architectural decisions from the implementation may become relevant to users of a particular instantiation of an abstraction.

A good metaphor is the abstraction of transportation. Both bicycling and driving a car are transportation. They both have commonalities (e.g., you must steer) and physical differences (e.g., power source). One can always specify the abstraction "drive to" and let the implementor decide whether bicycling or driving a car is best. The "wheeled terrestrial transport" function is abstracted and the details of "how to drive" are encapsulated.

==Programming==
A [[high-level programming language]] provides for hardware abstraction by allowing a [[programmer]] write an algorithm without using instructions that are unique to a 
[[central processing unit]] (CPU) or its [[instruction set architecture]] (ISA) {{endash}} the primitive operations of a CPU. For example, a [[compiler]] generates the CPU-specific instructions for a particular ISA. In this way, [[source code]] can support [[Software portability |portability]] across multiple platforms.

==Hardware abstraction layer==
A '''hardware abstraction layer''' (HAL) is an [[abstraction layer]], implemented in software, between the physical [[Computer hardware|hardware]] of a [[computer]] and the [[Computer software|software]] that runs on that computer. Its function is to hide differences in hardware from most of the [[operating system]] [[Kernel (operating system)|kernel]], so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. On Microsoft Windows, HAL can basically be considered to be the driver for the motherboard and allows instructions from higher level computer languages to communicate with lower level components, but prevents direct access to the hardware.

[[CP/M]] ([[CP/M BIOS]]), [[DOS]] ([[DOS BIOS]]), [[Solaris (operating system)|Solaris]], [[Linux]], [[BSD]], [[macOS]], and some other portable operating systems also have a HAL, even if it is not explicitly designated as such. Some operating systems, such as Linux, have the ability to insert one while running, like [[Adaptive Domain Environment for Operating Systems|Adeos]]. The [[NetBSD]] operating system is widely known as having a clean hardware abstraction layer which allows it to be highly portable.<ref name="NetBSD"/> As part of this system are {{man|9|uvm|NetBSD||inline}}/{{man|9|pmap|NetBSD||inline}}, {{man|9|bus_space|NetBSD||inline}}, {{man|9|bus_dma|NetBSD||inline}} and other subsystems. Popular buses which are used on more than one architecture are also abstracted, such as [[Industry Standard Architecture|ISA]], [[Extended Industry Standard Architecture|EISA]], [[Peripheral Component Interconnect|PCI]], [[PCIe]], etc., allowing drivers to also be highly portable with a minimum of code modification.

Operating systems having a defined HAL are more easily portable across different hardware. This is especially important for [[embedded system]]s that run on dozens of different platforms.

In a software stack, the HAL resides below the [[application programming interface]] (API), whereas the application layer (often written in a high-level language) resides above the API and communicates with the hardware by calling functions in the API.

===Microsoft Windows===
[[File:Windows_2000_architecture.svg|thumb|The hardware abstraction layer in the [[architecture of Windows NT]]]]
The [[Windows NT]] kernel has a HAL in the kernel space between hardware and the executive services that are contained in the file [[ntoskrnl.exe|NTOSKRNL.EXE]]<ref name="nthal"/><ref name="Custer_1993"/> under ''%WINDOWS%\system32\hal.dll''. This allows portability of the Windows NT kernel-mode code to a variety of processors, with different [[memory management unit]] architectures, and a variety of systems with different I/O bus architectures; most of that code runs without change on those systems, when compiled for the [[instruction set]] applicable to those systems. For example, the [[Silicon Graphics|SGI]] Intel x86-based workstations were not [[IBM PC compatible]] workstations, but due to the HAL, [[Windows 2000]] was able to run on them.<ref>{{Cite web|title=Changing hardware abstraction layer in Windows 2000 / XP – Smallvoid.com|date=15 January 2001 |url=http://smallvoid.com/article/winnt-hardware-abstraction-layer.html|access-date=2020-09-18|language=en-US}}</ref>{{failed verification|date=October 2022}}

Since [[Windows Vista]] and [[Windows Server 2008]], the HAL used is automatically determined during [[Windows Vista startup process|startup]].<ref name="Russinovich_2008"/>

===AS/400===
An "extreme" example of a HAL can be found in the [[System/38]] and [[AS/400]] architectures, currently implemented in the [[IBM i]] operating system. Most compilers for those systems generate an abstract machine code; the Licensed Internal Code, or LIC, translates this virtual machine code into native code for the processor on which it is running and executes the resulting native code.<ref name="soltis"/> (The exceptions are compilers that generate the LIC itself; those compilers are not available outside IBM.) This was so successful that application software and operating system software above the LIC layer that were compiled on the original S/38 run without modification and without recompilation on the latest AS/400 systems, despite the fact that the underlying hardware has been changed dramatically; at least three different types of processors have been in use.<ref name="soltis"/>

=== Android ===
[[Android (operating system)|Android]] introduced a HAL known as the "vendor interface" (codenamed "Project Treble") on [[Android Oreo|version 8.0 "Oreo"]]. It abstracts low-level code from the Android OS framework, and they must be made [[forward compatible]] to support future versions of Android to ease the development of firmware updates.<ref name="ars-treble">{{cite web|title=Google's "Project Treble" solves one of Android's many update roadblocks|url=https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-android-updates-no-really-with-project-treble/|website=Ars Technica|date=12 May 2017|access-date=12 May 2017}}</ref> Before Project Treble, Android relied on various non-standardized legacy HALs.<ref>{{Cite web|url=https://source.android.com/devices/architecture/hal-types#legacy|website=Android Open Source Project|title=Conventional & legacy HALs}}</ref>

[[Halium]] is an Android-based HAL used by several mobile operating systems such as [[Ubuntu Touch]] and [[LuneOS]] to run on smartphones with Android pre-installed.

==See also==
*[[Basic Input/Output System]]
*[[Unified Extensible Firmware Interface]]
*[[Firmware]]
*[[Advanced Configuration and Power Interface]]
*[[Device tree]]
*[[Board support package]]
*[[DeviceKit]]
*[[Haiku Device Kit]]
*[[HAL (software)]]
*[[Hardware-dependent software]]
*[[Nanokernel]]
*[[Picokernel]]
*[[Protection ring]]

==References==
{{reflist|refs=
<ref name="NetBSD">{{cite web |url=http://www.netbsd.org/about/portability.html |title=Portability and supported hardware platforms |access-date=2009-05-12 |publisher=The NetBSD Foundation}}</ref>
<ref name="nthal">{{cite web |title=Windows NT Hardware Abstraction Layer (HAL) |url=http://support.microsoft.com/kb/99588 |publisher=[[Microsoft]] |date=2006-10-31 |access-date=2007-08-25}}</ref>
<ref name="Custer_1993">{{citation |title=Inside Windows NT |author-first=Helen |author-last=Custer |publisher=[[Microsoft Press]] |year=1993|bibcode=1993iwn..book.....C }}</ref>
<ref name="Russinovich_2008">{{cite book |author-last=Russinovich |author-first=Mark E. |title=Windows Internals: Including Windows Server 2008 and Windows Vista |year=2008 |publisher=[[Microsoft Press]] |location=Redmond, Washington, USA |isbn=978-0-7356-2530-3 |page=65 |edition=5 |author-last2=Solomon |author-first2=David A. |author-last3=Ionescu |author-first3=Alex}}</ref>
<ref name="soltis">{{cite book |author-last=Soltis |author-first=Frank G. |title=Inside the AS/400: Featuring the AS/400e Series |year=1997 |publisher=Duke Press |location=Loveland, Colorado, USA |isbn=978-1-882419-66-1 |edition=2}}</ref>
}}
==Further reading==
*{{cite web |url=http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf |title=Advanced RISC Computing Specification |page=23 |publisher=[[MIPS Technologies]] |access-date=2013-02-26}}
* {{cite book |author-first1=Abraham |author-last1=Silberschatz |author-first2=Peter Bear |author-last2=Galvin |author-first3=Greg |author-last3=Gagne |title=Operating System Concepts |edition=6 |date=2002 |isbn=0-471-41743-2}}
{{Operating System}}

[[Category:Booting]]
[[Category:Operating system technology]]
[[Category:Firmware]]
[[Category:Device drivers]]