Войти
Аппаратная абстракция - это наборы процедур в программном обеспечении, которые предоставляют программам доступ к аппаратному обеспечению ресурсы через программные интерфейсы. Интерфейс программирования позволяет осуществлять доступ ко всем устройствам в конкретном классе аппаратных устройств C через идентичные интерфейсы, даже если C может содержать разные подклассы устройств, каждый из которых предоставляет свой аппаратный интерфейс.
Аппаратные абстракции часто позволяют программистам писать устройства -независимые, высокопроизводительные приложения, предоставляя аппаратным средствам стандартные вызовы операционной системы (ОС). Процесс абстрагирования аппаратного обеспечения часто выполняется с точки зрения CPU. Каждый тип ЦП имеет определенную архитектуру набора команд или ISA. ISA представляет примитивные операции машины, которые доступны для использования программистами сборки и разработчиками компиляторов. Одна из основных функций компилятора состоит в том, чтобы позволить программисту написать алгоритм на языке высокого уровня, не заботясь о специфичных для процессора инструкциях. Затем задача компилятора - создать исполняемый файл, специфичный для процессора. Тот же тип абстракции используется в операционных системах, но OS API теперь представляют примитивные операции машины, а не ISA. Это позволяет программисту использовать операции уровня ОС (например, создание / удаление задач) в своих программах, сохраняя при этом переносимость на различных платформах.
Многие ранние компьютерные системы не имели какой-либо формы аппаратной абстракции. Это означало, что любой, кто пишет программу для такой системы, должен знать, как каждое аппаратное устройство взаимодействует с остальной частью системы. Это было серьезной проблемой для разработчиков программного обеспечения, поскольку им нужно было знать, как каждое аппаратное устройство в системе работает, чтобы гарантировать совместимость. С помощью аппаратной абстракции, а не программы, напрямую связывающейся с аппаратным устройством, она сообщает операционной системе, что устройство должно делать, а затем генерирует аппаратно-зависимую инструкцию для устройства. Это означало, что программистам не нужно было знать, как работают определенные устройства, что делало их программы совместимыми с любым устройством.
Примером этого может быть абстракция «Джойстик». Устройство джойстик, которое существует во многих физических реализациях, доступно для чтения / записи через API, который может совместно использоваться многими устройствами, подобными джойстику. Большинство устройств-джойстиков могут сообщать направления движения. Многие устройства-джойстики могут иметь настройки чувствительности, которые могут быть настроены внешним приложением. Абстракция джойстика скрывает детали (например, формат регистра, адрес I2C ) оборудования, поэтому программисту, использующему абстрактный API, не нужно понимать детали физического интерфейса устройства. Это также позволяет повторно использовать код , поскольку один и тот же код может обрабатывать стандартизированные сообщения из любого вида реализации, которая предоставляет абстракцию «джойстик». «Сдвиг вперед» может происходить от потенциометра или от емкостного сенсорного датчика, который распознает жесты «смахивания», при условии, что они оба подают сигнал, связанный с «движением».
Поскольку физические ограничения (например, разрешение датчика, частота обновления во времени) могут варьироваться в зависимости от оборудования, API мало что может скрыть, кроме как путем использования модели «наименьшего общего знаменателя». Таким образом, определенные глубокие архитектурные решения из реализации могут стать актуальными для пользователей конкретного экземпляра абстракции.
Хорошая метафора - это абстракция транспорта. И езда на велосипеде, и вождение автомобиля - это транспорт. У них обоих есть общие черты (например, вы должны управлять) и физические различия (например, использование ног). Всегда можно указать абстракцию «ездить до» и позволить разработчику решить, что лучше - езда на велосипеде или вождение автомобиля. Функция «колесный наземный транспорт» абстрагирована, а детали «как водить» инкапсулируются.
Примеры «абстракций» на ПК включают видеовход, принтеры, аудиовход и выход, блочные устройства (например, жесткие диски или USB-накопитель ), и т. д.
В определенных областях информатики, таких как операционные системы или встроенные системы, абстракции имеют немного другой вид (например, операционные системы, как правило, имеют более стандартизированные интерфейсы), но концепция абстракции и инкапсуляции сложности бывают обычными и глубокими.
Уровень аппаратной абстракции находится ниже интерфейса прикладного программирования (API) в программном стеке, тогда как уровень приложения (часто написанный на языке высокого уровня) находится над API и взаимодействует с оборудование, вызывая функции в API.
A уровень абстракции оборудования (HAL ) - это уровень абстракции, реализованный программно, между физическим оборудованием компьютера и программного обеспечения, которое работает на этом компьютере. Его функция заключается в том, чтобы скрыть различия в оборудовании от большей части операционной системы ядра, так что большую часть кода режима ядра не нужно изменять для работы в системах с другим оборудованием.. На ПК HAL можно рассматривать как драйвер для материнской платы, который позволяет командам компьютерных языков более высокого уровня взаимодействовать с компонентами более низкого уровня, но предотвращает прямой доступ к оборудованию.
CP / M (CP / M BIOS ), DOS (DOS BIOS ), Solaris, Linux, BSD, macOS и некоторые другие переносимые операционные системы также имеют HAL, даже если он явно не обозначен как таковой. Некоторые операционные системы, такие как Linux, могут вставлять их во время работы, например, Adeos. Операционная система NetBSD широко известна как имеющая чистый уровень аппаратной абстракции, который позволяет ее легко переносить. В состав этой системы входят uvm(9) /pmap(9) , bus_space(9) , bus_dma(9) и другие подсистемы. Также абстрагируются популярные шины, которые используются более чем в одной архитектуре, например, ISA, EISA, PCI, PCIe и т. Д., что позволяет легко переносить драйверы с минимальным изменением кода.
Операционные системы с определенным HAL легко переносимы на различное оборудование. Это особенно важно для встроенных систем, которые работают на десятках различных платформ.
Ядро Windows NT имеет HAL в пространстве ядра между оборудованием и исполнительными службами, которые содержатся в файле NTOSKRNL.EXE в% WINDOWS% \ system32 \ hal.dll. Это обеспечивает переносимость кода режима ядра Windows NT на множество процессоров с разными архитектурами блока управления памятью и множеством систем с разными архитектурами шины ввода-вывода; большая часть этого кода выполняется без изменений в этих системах при компиляции для набора инструкций , применимого к этим системам. Например, рабочие станции SGI на базе Intel x86 не были рабочими станциями, совместимыми с IBM PC, но из-за HAL Windows 2000 могла работать на них.
Начиная с Windows Vista и Windows Server 2008, используемый HAL автоматически определяется при запуске.
«Крайний» пример HAL можно найти в архитектуре System / 38 и AS / 400. Большинство компиляторов для этих систем генерируют абстрактный машинный код; Лицензионный внутренний код, или LIC, переводит этот код виртуальной машины в собственный код процессора, на котором он работает, и выполняет полученный собственный код. (Исключение составляют компиляторы, которые генерируют сам LIC; эти компиляторы недоступны за пределами IBM.) Это было настолько успешным, что прикладное программное обеспечение и программное обеспечение операционной системы выше уровня LIC, которые были скомпилированы на исходном S / 38, работали без изменений и без перекомпиляции. в новейших системах AS / 400, несмотря на то, что базовое оборудование было радикально изменено; использовались по крайней мере три различных типа процессоров.
Android представил HAL, известный как «интерфейс поставщика» (кодовое название «Project Treble») в версии 8.0 » Орео ". Он абстрагирует низкоуровневый код от структуры ОС Android, и они должны быть совместимы с будущими версиями для поддержки будущих версий Android, чтобы упростить разработку обновлений прошивки. Android HAL существовал даже раньше.
