この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "Hardware Abstraction Layer"
Hardware Abstraction Layer (HAL、ハードウェア抽象化レイヤー) とは、コンピュータのハードウェアとそのコンピュータ上で動作するソフトウェアの間に存在する、ソフトウェアで実装した抽象化レイヤーである。オペレーティングシステム (OS) のカーネルからハードウェア毎に異なる差異を隠蔽する機能を持ち、それによってカーネルコードは異なるハードウェアのシステム上で動作してもほとんど変更する必要がなくなる。PCにおいては、HALは基本的にマザーボード用ドライバの形態をとり、上位のプログラムがハードウェアに直接アクセスする下位のコンポーネントに指示できるようにする。 多数存在するCPUアーキテクチャ毎の動作の違いなどがあっても、適切に設計されたHALを用意すれば動作できる。そのため、システムを開発するときにハードウェアの差異を意識することなく設計できる。これらはNTベースのMicrosoft Windows OSで用いられる技術である。NTベースのOSには、カーネル空間にHALがあり、カーネルやドライバや実行サービスとハードウェアの仲介をする[1][2]。これにより、Windows NT のカーネルモードのコードは各種の異なるメモリ管理ユニットのアーキテクチャのプロセッサに移植でき、各種I/Oバスアーキテクチャのシステムに移植できるようになっている。コードの大部分はそれらシステム上で、単にその命令セットアーキテクチャにコンパイルするだけでソースコードを修正することなく実行することができる。 BSD、macOS、Linux、CP/M、DOS、Solaris といったOSにもHALに相当する部分は存在しているが、明確にHALとして認識・区別されていない。Linuxなどでは、動作中のカーネルに対してAdeosのようなHALを後から挿入することができる。NetBSDはHAL層を明確に区別しており、非常に移植性が高い。このシステムは ⇒uvm(9)、 ⇒pmap(9)、 ⇒bus_space(9)、 ⇒bus_dma(9) といったサブシステムから構成される。ISA、EISA、PCI、PCI-Eなど、複数のアーキテクチャで使われているI/Oバスも抽象化されており、デバイスドライバも最小限の修正だけで移植可能である。 HALの極端な例として、System/38やAS/400のアーキテクチャがある。これらシステム上のコンパイラの多くは抽象化された機械語コードを生成する。Licensed Internal Code (LIC) はそれを動作中のシステムのプロセッサ用コードに変換し実行させる。LIC層より上のアプリケーションやOSのコードはSystem/38からAS/400に移行する際に全く修正も再コンパイルも不要だった（System/38とAS/400では少なくとも3種類の全く異なるプロセッサが使われている）。 HALは、カーネルの代わりにハードウェアと直接やり取りするものであるため、そのインタフェースはOSのAPIよりも下位に存在する。したがって、HALの処理にかかる時間はAPI（システムコール）にかかる時間よりも短くなければならない。 HALが定義されたOSは各種ハードウェアに容易に移植可能である。これは非常に様々なプラットフォーム上で動作することを要求される組み込みシステムでは特に重要である。 Windows向けのマルチメディア処理用APIであるDirectXにも、HALに対応したコンポーネントがいくつか存在する。 リアルタイム3次元コンピュータグラフィックスAPIであるDirect3Dには、ビデオカードなどのグラフィックスハードウェア (GPU) を抽象化するためのHALデバイス[3]が用意されている。ベンダー間の差異を吸収する層であるHALデバイスを利用することにより、ベンダー共通のDirect3D APIを用いてハードウェアの機能にアクセスできる。 なお、DirectDrawにはドライバーをユーザーモードでエミュレーションするためのHardware Emulation Layer (HEL) が用意されていた[4]。 DirectSoundにもサウンドカードのハードウェア支援を利用するHALが用意されていたが、Windows Vista以降はソフトウェアエミュレーションに置き換えられた[5]。
概要
DirectX