World Library  
Flag as Inappropriate
Email this Article

Hardware Abstraction Layer

Article Id: WHEBN0001894098
Reproduction Date:

Title: Hardware Abstraction Layer  
Author: World Heritage Encyclopedia
Language: English
Subject: Mach (kernel), Windows 2000, Music tracker, NTLDR, System Idle Process, SGI Visual Workstation, A9home, List of Microsoft Windows components, Windows Vista, RedBoot
Collection:
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Hardware Abstraction Layer

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

Hardware abstractions are sets of routines in software that emulate some platform-specific details, giving programs direct access to the hardware resources.

They 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 (i.e. task creation/deletion) in their programs while still remaining portable over a variety of different platforms.

Overview

Many early computer systems do not have any form of hardware abstraction. This means that anyone writing a program for such a system must know how each hardware device communicates. This becomes a significant challenge to software developers, who must know how every device available works to ensure it's compatible. With hardware abstraction, the program instead tells the operating system what the device should do, and the operating system gives the instruction. This means that programmers don't need to know how individual devices work, and their programs are compatible with any device.

An Example of this might be a "Joystick" abstraction. The joystick device, 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 formats, I2C address) of the hardware so that a programmer using the abstracted API needn't understand the details of the device physical interface. This also allows code reuse since the same code can process standardised 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, OSes tend to have more standardized interfaces), but the concept of abstraction and encapsulation of complexity are common, and deep.

Hardware abstraction layers are of an even lower level in computer languages than application programming interfaces (API) because they interact directly with hardware instead of a system kernel, therefore HALs require less processing time than APIs. Higher level languages often use HALs and APIs to communicate with lower level components.

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.

PCI-E, 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 operating system has a HAL in the kernel space between hardware and the Windows NT executive services that are contained in the file NTOSKRNL.EXE.[1][2] 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 NT was able to run on them.

Windows Vista and later (Windows Server 2008 and later for servers) automatically detect which hardware abstraction layer (HAL) should be used at boot time.[3]

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.[4] (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.[4]

References

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.