Hardware abstraction

Hardware abstractions are sets of routines in software that provide programs with access to hardware resources through programming interfaces. The programming interface allows all devices in a particular class C of hardware devices to be accessed through identical interfaces even though C may contain different subclasses of devices that each provide a different hardware interface.

"Hardware Abstraction Layer" redirects here. For the UNIX-like operating system subsystem, see HAL (software).

Hardware abstractions often allow programmers to write device-independent, high performance applications by providing standard operating system (OS) calls to hardware. The process of abstracting pieces of hardware is often done from the perspective of a CPU. Each type of CPU has a specific instruction set architecture or ISA. The ISA represents the primitive operations of the machine that are available for use by assembly programmers and compiler writers. One of the main functions of a compiler is to allow a programmer to write an algorithm in a high-level language without having to care about CPU-specific instructions. Then it is the job of the compiler to generate a CPU-specific executable. The same type of abstraction is made in operating systems, but OS APIs now represent the primitive operations of the machine, rather than an ISA. This allows a programmer to use OS-level operations (e.g. task creation/deletion) in their programs while retaining portability over a variety of different platforms.

Overview

Many early computer systems did not have any form of hardware abstraction. This meant that anyone writing a program for such a system would have to know how each hardware device communicated with the rest of the system. This was a significant challenge to software developers since they then had to know how every hardware device in a system worked to ensure the software's compatibility. With hardware abstraction, rather than the program communicating directly with the hardware device, it communicates to the operating system what the device should do, which then generates a hardware-dependent instruction to the device. This meant programmers didn't need to know how specific devices worked, making their programs compatible with any device.

An example of this might be a "Joystick" abstraction. The joystick device, of which there are many physical implementations, is readable/writable through an API which many joystick-like devices might share. Most joystick-devices might report movement directions. Many joystick-devices might have sensitivity-settings that can be configured by an outside application. A Joystick abstraction hides details (e.g., register format, I2C address) of the hardware so that a programmer using the abstracted API, 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. A "nudge forward" can be from a potentiometer or from a capacitive touch sensor that recognises "swipe" gestures, as long as they both provide a signal related to "movement".

As physical limitations (e.g. resolution of sensor, temporal update frequency) 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., use of feet). 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.

Examples of "abstractions" on a PC include video input, printers, audio input and output, block devices (e.g. hard disk drives or USB flash drive), etc.

In certain computer science domains, such as operating systems or embedded systems, the abstractions have slightly different appearances (for instance, Operating Systems tend to have more standardized interfaces), but the concept of abstraction and encapsulation of complexity are common, and deep.

The hardware abstraction layer reside below the application programming interface (API) in a software stack, 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.

In operating systems

A hardware abstraction layer (HAL) is an abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. Its function is to hide differences in hardware from most of the 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 a PC, 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, 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 Adeos. The NetBSD operating system is widely known as having a clean hardware abstraction layer which allows it to be highly portable.[1] As part of this system are uvm(9)/pmap(9), bus_space(9), bus_dma(9) and other subsystems. Popular buses which are used on more than one architecture are also abstracted, such as ISA, EISA, PCI, PCIe, etc., allowing drivers to also be highly portable with a minimum of code modification.

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

Microsoft Windows

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[2][3] 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 SGI Intel x86-based workstations were not IBM PC compatible workstations, but due to the HAL, Windows 2000 was able to run on them.

Since Windows Vista and Windows Server 2008, the HAL used is automatically determined during startup.[4]

AS/400

An "extreme" example of a HAL can be found in the System/38 and AS/400 architecture. 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.[5] (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.[5] Additional points from Inside the AS/400, Featuring the AS/400e series, second edition, by Frank G. Soltis. Chapter 3, page 49. confusions about where the fine the operating system in the AS/400. OS/400 lacks most of the functions found in other operating systems. the high-level machine interface, called the MI, is a complete set of APIs for writing applications. OS/400 programs do not manage system resources. MI is technology-independent interface that has no knowledge of the memory configuration and characteristics. Thus memory management needs to be handled below the MI. OS/400 resides above the MI. No hardware-dependent components can be in OS/400, but must be beneath the MI to preserve technology independence.. the MI protects application programs and OS/400 from hardware changes. The operating-system software beneath the MI is called the licensed internal code (LIC). Page 50. OS/400 consists of objects and programs above the MI. The LKIC compress the data structures and programs below the MI.. The LIC is the link between the MI and the hardware. So the AS/400 operating system is the combination of OS/400 and the LIC. Kernel is a convenient way to describe the operation-sytem functions packaged under the MI. Work management with schedules jobs, can be predominantly I OS/400 because such functions have few hardware dependencies. Device driver support can be partially in OS/400 and partially in the LIC. Chapter 7 will show that system-wide security is in OS/400m whuke the authorization to system resources is below, in the LIC. Most major OS functions, like security, have some portions above and some portions below the MI. (end page 51) Page 52. decided to call the kernel microcode. Page 53> Internal code for the RISC-based systems is called System Licensed Internal Code (SLIC). Many changes were required to the LIC below the MI when Rochester began working on the RISC processor in 1991. Page 54. REdesigne and rewrote from scratch. Page 55. Selected C++ programming language for the new SLIC development. Page 56. The SLIC project began in June of 1992 produced more than 1 million lines of C++ code and more than 7,000 classes (classes = template that describes all objects that share the same operations and seat elements in Object-Oriented programming). Counting all the ported code, they had more than 3 million lines of trusted operating system code under the MI. SLIC is treated like the kernel of an operating system. Within the kernel, all code is assumed to be trusted. Only the SLIC developers in Rochester were allowed to generated code that runs in SLIC. No one else is allowed to write SLIC functionsRochester has never shared SLIC-level code with anyone outside the SLIC team.

Android

Android introduced a HAL known as the "vendor interface" (codenamed "Project Treble") on 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.[6]. An Android HAL existed even before.[7]

See also

References
  1. "Portability and supported hardware platforms". The NetBSD Foundation. Retrieved 2009-05-12.
  2. "Windows NT Hardware Abstraction Layer (HAL)". Microsoft. 2006-10-31. Retrieved 2007-08-25.
  3. Custer, Helen (1993), Inside Windows NT, Microsoft Press
  4. Russinovich, Mark E.; Solomon, David A.; Ionescu, Alex (2008). Windows Internals: Including Windows Server 2008 and Windows Vista (5 ed.). Redmond, Washington, USA: Microsoft Press. p. 65. ISBN 978-0-7356-2530-3.
  5. Soltis, Frank G. (1997). Inside the AS/400: Featuring the AS/400e Series (2 ed.). Loveland, Colorado, USA: Duke Press. ISBN 978-1-882419-66-1.
  6. "Google's "Project Treble" solves one of Android's many update roadblocks". Ars Technica. Retrieved 12 May 2017.
  7. https://www.e-consystems.com/blog/system-on-module-SOM/android-hal-and-device-driver-architecture/

Further reading
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.