Categories: Ai

[Перевод] История POSIX: путь к портируемому ПО

В ранние годы развития компьютеров программисты могли лишь мечтать о портируемости. Все программы писались непосредственно в машинном коде для каждой компьютерной архитектуры, на которой они должны были работать. Языки ассемблера с мнемоническими именами каждой команды CPU и другие удобства сильно упростили жизнь программистов, но программы по-прежнему были привязаны к архитектуре. Тогда ещё не изобрели операционных систем, поэтому программа не только управляла всей компьютерной системой, но и должна была инициализировать всю периферию, а также управлять ею. На самом деле, такие низкоуровневые программы реализовывали драйверы для каждого используемого ими устройства. И каждый раз, когда программу нужно было перенести на оборудование с другой архитектурой, она в буквальном смысле переписывалась с учётом различий архитектуры набора команд CPU, структуры памяти и так далее.

Именно так произошло с Unix, который изначально был написан Кеном Томпсоном на языке ассемблера более пятидесяти лет назад. Первые версии Unix писались для платформы PDP-7, а для портирования его на PDP-11 нужно было переписывать код. Когда Дэннис Ритчи создал язык программирования C, и вместе с Томпсоном они переписали на нём основную часть кода Unix, внезапно оказалась возможной портируемость ПО. Тому были две главные причины. Во-первых, код, написанный на языке высокого уровня, не зависит от платформы, потому что компиляторы транслируют его в язык ассемблера целевой архитектуры. Это ещё важнее для целевых платформ на основе процессоров RISC, так как они требуют написания гораздо большего количества ассемблерных команд, чем процессоры CISC. Даже при портировании Unix на другую платформу основная сложность заключалась лишь в адаптации зависящих от архитектуры частей кода. С другой стороны, сама операционная система абстрагирует все особенности оборудования от пользовательской программы.

Программистам не нужно реализовывать многозадачность, управление памятью и драйверы для используемых ими устройств, потому что всё это часть ядра ОС и работает в адресном пространстве ядра. Пользовательские программы работают в пользовательском адресном пространстве и получают доступ ко всем предоставляемым ОС функциям при помощи интерфейса системных вызовов. В ОС реального времени, например, в Zephyr OS ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам:

Читать далее

Share
Published by

Recent Posts

Магия CSS на практике: советы по вёрстке от гика. Часть 4

Хабр, привет! Я снова пришёл к вам со статьёй, где показываю мои любимые техники вёрстки.…

3 месяца ago

JavaScript: структуры данных и алгоритмы. Часть 5

Привет, друзья! В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом…

3 месяца ago

Реализация событий через HTTP

Для некоторых задач, связанных с обновлением данных в реальном времени — например, новостные ленты, уведомления…

3 месяца ago

Каннибализм трафика. Нужно ли вести контекст по брендовым запросам?

Со времён появления контекстной рекламы маркетологов не перестаёт мучить вопрос:"А есть ли смысл вести контекст по…

3 месяца ago

Презентация Apple 2024: новая кнопка на iPhone 16, функция слухового аппарата у AirPods, кинокамера в iPhone Pro

Накануне в прямом эфире прошла большая презентация новой техники от компании Apple. Команда Тима Кука…

3 месяца ago

Сразу два аналога Notion, бесплатный сервис аналитики для продавцов на WB – эти и другие российские стартапы

10 новых российских сервисов для нарезки шортсов при помощи ИИ, публикации в цифровых СМИ, авто-ответов…

3 месяца ago