Портирование
В разработке программного обеспечения портирование — это процесс адаптации программного обеспечения с целью достижения некоторой формы выполнения в вычислительной среде , отличной от той, для которой данная программа (предназначенная для такого выполнения) была изначально разработана (например, другой процессор , операционная система или сторонняя библиотека ). Этот термин также используется, когда программное/аппаратное обеспечение изменяется, чтобы сделать их пригодными для использования в различных средах. [1] [2]
Программное обеспечение является переносимым , когда стоимость его переноса на новую платформу значительно меньше, чем стоимость его написания с нуля. Чем ниже стоимость переноса программного обеспечения относительно стоимости его реализации, тем более переносимым оно считается.
Этимология
[ редактировать ]Термин «порт» происходит от латинского portāre , что означает «переносить». [3] Если код несовместим с конкретной операционной системой или архитектурой , его необходимо «перенести» в новую систему.
Этот термин обычно не применяется к процессу адаптации программного обеспечения для работы с меньшим объемом памяти на том же процессоре и операционной системе.
Разработчики программного обеспечения часто заявляют, что написанное ими программное обеспечение является переносимым , а это означает, что для его адаптации к новой среде не требуется особых усилий. Фактически необходимый объем усилий зависит от нескольких факторов, включая степень, в которой исходная среда ( исходная платформа ) отличается от новой среды ( целевая платформа ), опыт первоначальных авторов в знании того, какие конструкции языка программирования и сторонние библиотечные вызовы вряд ли будут переносимыми, а также количество усилий, вложенных первоначальными авторами в использование только переносимых конструкций (конструкции, специфичные для платформы, часто обеспечивают более дешевое решение).
История
[ редактировать ]Количество существенно отличающихся процессоров и операционных систем, используемых сегодня на настольных компьютерах, намного меньше, чем в прошлом. Доминирование x86 архитектуры означает, что большая часть настольного программного обеспечения никогда не переносится на другой процессор. На том же рынке выбор операционных систем фактически сократился до трех: Microsoft Windows , macOS и Linux . Однако на встраиваемых систем и мобильных устройств рынках портативность остается серьезной проблемой, поскольку ARM широко используемой альтернативой является .
Международные стандарты, например, принятые ISO , значительно облегчают портирование, определяя детали вычислительной среды таким образом, чтобы уменьшить различия между различными платформами , соответствующими стандартам . Написание программного обеспечения, которое не выходит за рамки, определенные этими стандартами, представляет собой практическую, хотя и нетривиальную задачу. Портирование такой программы между двумя платформами, совместимыми со стандартами (такими как POSIX.1 ), может быть просто вопросом загрузки исходного кода и его перекомпиляции на новой платформе, но практики часто обнаруживают, что требуются различные незначительные исправления из-за тонкостей платформы. различия. Большинство стандартов страдают от «серых зон», где различия в интерпретации стандартов приводят к небольшим различиям от платформы к платформе.
Также существует постоянно растущее число инструментов для облегчения портирования, таких как GNU Compiler Collection , которая обеспечивает единообразные языки программирования на разных платформах, и Autotools , который автоматизирует обнаружение незначительных изменений в среде и соответствующим образом адаптирует программное обеспечение перед компиляцией. .
Компиляторы некоторых языков программирования высокого уровня (например, Eiffel , Esterel ) обеспечивают переносимость за счет вывода исходного кода на другой промежуточный язык высокого уровня (например, C ), для которого обычно доступны компиляторы для многих платформ.
Два вида деятельности, связанные с портированием (но отличающиеся от него), — это эмуляция и кросс-компиляция .
Портирование компиляторов
[ редактировать ]Вместо прямой трансляции в машинный код современные компиляторы преобразуют в машинно-независимый промежуточный код , чтобы повысить переносимость компилятора и минимизировать усилия по проектированию. Промежуточный язык определяет виртуальную машину , которая может выполнять все программы, написанные на промежуточном языке (машина определяется своим языком и наоборот). [4] Инструкции промежуточного кода преобразуются в эквивалентные последовательности машинного кода генератором кода для создания исполняемого кода . Также можно пропустить генерацию машинного кода, фактически реализовав интерпретатор или JIT для виртуальной машины. [5]
Использование промежуточного кода повышает переносимость компилятора, поскольку на целевую машину необходимо переносить только машинно-зависимый код (интерпретатор или генератор кода) самого компилятора. Остальная часть компилятора может быть импортирована как промежуточный код, а затем дополнительно обработана генератором или интерпретатором перенесенного кода, создавая таким образом программное обеспечение компилятора или непосредственно выполняя промежуточный код на интерпретаторе. Независимая от машины часть может быть разработана и протестирована на другой машине ( главной машине ). Это значительно сокращает усилия по проектированию, поскольку машинно-независимую часть необходимо разработать только один раз для создания переносимого промежуточного кода. [6]
Интерпретатор менее сложен и, следовательно, его легче портировать, чем генератор кода, поскольку он не способен выполнять оптимизацию кода из-за ограниченного обзора программного кода (он видит только одну инструкцию за раз, и пользователям нужна последовательность действий). оптимизация). Некоторые интерпретаторы чрезвычайно легко портировать, поскольку они делают лишь минимальные предположения о наборе команд базового оборудования. В результате виртуальная машина оказывается даже проще целевого процессора. [7]
Написание исходных кодов компилятора полностью на языке программирования, который компилятор должен транслировать, делает следующий подход, более известный как загрузка компилятора возможным на целевой машине :
- Портируйте интерпретатор. Это необходимо закодировать в ассемблерном коде , используя уже существующий ассемблер в целевой системе.
- Адаптируйте исходный код генератора кода к новой машине.
- Выполните адаптированный исходный код, используя интерпретатор с исходным кодом генератора кода в качестве входных данных. Это создаст машинный код для генератора кода.
Сложная часть кодирования процедур оптимизации выполняется с использованием языка высокого уровня вместо целевого языка ассемблера.
По мнению разработчиков языка BCPL , интерпретируемый код (в случае BCPL) более компактен, чем машинный код, обычно в два раза. Однако интерпретируемый код работает примерно в десять раз медленнее, чем скомпилированный код на той же машине. [8]
Разработчики языка программирования Java стараются воспользоваться компактностью интерпретируемого кода, поскольку программу Java может потребоваться передать через Интернет, прежде чем ее выполнение сможет начаться на целевой виртуальной машине Java (JVM).
Портирование видеоигр
[ редактировать ]Портирование — это также термин, используемый, когда видеоигра , предназначенная для работы на одной платформе, будь то аркадная консоль , игровая консоль или персональный компьютер , преобразуется для работы на другой платформе, возможно, с некоторыми незначительными отличиями. [9] С момента появления видеоигр до 1990-х годов «порты», в то время часто называемые «конверсиями», часто были не настоящими портами, а скорее переработанными версиями игр из-за ограничений различных систем. Например, игра 1982 года «Хоббит» , текстовое приключение, дополненное графическими изображениями, имеет существенно разные графические стили на разных персональных компьютерах, для которых были разработаны ее порты. [10] Однако многие видеоигры 21 века разрабатываются с использованием программного обеспечения (часто на C++ ), которое может выводить код для одной или нескольких консолей, а также для ПК без необходимости фактического портирования (вместо этого полагаясь на общее портирование отдельных библиотек компонентов ). [10]
Портировать аркадные игры на домашние системы с некачественным оборудованием было сложно. В портированной версии Pac-Man для Atari 2600 были исключены многие визуальные особенности оригинальной игры, чтобы компенсировать нехватку места в ПЗУ , а оборудование давало сбои, когда на экране появлялось несколько призраков, создавая эффект мерцания. Плохая производительность Atari 2600 Pac-Man некоторые ученые называют причиной краха видеоигр в 1983 году . [11]
Многие ранние порты страдали от серьезных проблем с качеством игрового процесса, поскольку компьютеры сильно различались. [12] Ричард Гэрриот заявил в 1984 году на выставке Origins Game Fair , что Origin Systems разрабатывала видеоигры для Apple II, сначала Commodore 64 и а затем портировала их на 8-битные компьютеры и другие сложные функции последних машин Atari, поскольку спрайты затрудняли перенос с них на Apple». гораздо труднее, возможно, даже невозможно». [13] В обзорах жаловались на порты, страдавшие «яблочным конверсионитом», [14] сохранение «паршивого звука и черно-бело-зелено-фиолетовой графики Apple»; [15] [16] после заявления Гэрриотта, когда Дэн Бунтен спросил: «Люди из Atari и Commodore в аудитории, вы довольны переписыванием Apple?» публика кричала «Нет!» Гэрриот ответил: «[иначе] версия для Apple никогда не будет выпущена. С точки зрения издателя, это неразумно с точки зрения денег». [13]
Другие работали по-другому. Ozark Softscape , например, сначала написала MULE для Atari, потому что предпочитала разрабатывать для самых продвинутых компьютеров, удаляя или изменяя функции по мере необходимости во время портирования. Такая политика не всегда была осуществима; Бунтен заявил, что «MULE невозможно сделать для Apple», [12] и что версии The Seven Cities of Gold, созданные не для Atari, были хуже. [17] Газета Compute! в 1986 году писала, что при портировании с Atari на Commodore оригинал обычно был лучше. Качество последних игр улучшилось, когда в конце 1983 года разработчики начали создавать для них новое программное обеспечение, сообщает журнал. [18]
При портировании аркадных игр термины «идеальная аркада» или «точная аркада» часто использовались для описания того, насколько близко игровой процесс, графика и другие ресурсы в портированной версии соответствуют аркадной версии. Многие аркадные порты в начале 1980-х годов были далеки от совершенства для аркадных игр, поскольку домашним консолям и компьютерам не хватало сложного оборудования для аркадных игр, но игры все равно могли приближаться к игровому процессу. Примечательно, что Space Invaders на Atari VCS для консоли, стала убийственным приложением несмотря на свои различия. [19] в то время как более поздний Pac-Man порт был известен своими отклонениями от аркадной версии. [20] Аркадные игры стали более распространенными, начиная с 1990-х годов, когда домашние консоли догнали аркадные системы. Примечательно, что система Neo Geo от SNK , которая была представлена как аркадная система с несколькими играми, также будет предлагаться в качестве домашней консоли с теми же характеристиками. Это позволило играть в идеальные аркадные игры дома. [10]
«Консольный порт» — это игра, которая изначально была создана для консоли, прежде чем была создана идентичная версия, в которую можно играть на персональном компьютере . Этот термин широко используется игровым сообществом. Процесс переноса игры с консоли на ПК часто рассматривается негативно из-за более высокого уровня производительности, который компьютеры обычно используют недостаточно, частично из-за того, что оборудование консоли исправляется на протяжении всего запуска (игры разрабатываются для консолей), в то время как ПК становятся более мощными по мере развития аппаратного обеспечения, но также и из-за того, что портированные игры иногда плохо оптимизированы для ПК или портируются лениво. Хотя в целом они схожи, могут существовать архитектурные различия, такие как использование единой памяти на консоли.
См. также
[ редактировать ]- Эмулятор консоли
- Кросс-платформенный
- Языковая привязка
- Список атрибутов качества системы
- Poshlib
- Трансформация программы
- Переносимость программного обеспечения
- Компилятор исходного кода
- Исходный порт
- Напишите один раз, скомпилируйте где угодно
- Значение слова непортированный
Ссылки
[ редактировать ]- ^ Уиттен, Делавэр; Демейн, PAD (март 1975 г.). «Фортран, независимый от машины и конфигурации: портативный Фортран». Транзакции IEEE по разработке программного обеспечения . СЭ-1 (1): 111–124. дои : 10.1109/TSE.1975.6312825 . S2CID 16485156 .
- ^ «Проблемы переносимости» .
.. обсуждает .. переносимость .. Фортрана
- ^ "порт, v.2" . Оксфордский словарь английского языка (OED Online) . Издательство Оксфордского университета . Проверено 21 декабря 2017 г.
Происхождение: Различного происхождения. Частично заимствование из французского языка. Частично заимствование из латыни. Этимоны: французский портер ; Латинское portāre . ... 1. пер. Носить, нести или передавать; принести.
- ^ Таненбаум 1984 , с. 3, § 1.1 Языки, уровни и виртуальные машины описывают термины и их отношения.
- ^ Таненбаум 1984 , с. 2. Ч. 1 Введение объясняет перевод и интерпретацию.
- ^ Ричардс и Уитби-Стривенс 1984 , с. 124, § 7.1 Введение объясняет переносимость компилятора с использованием промежуточного кода.
- ^ Ричардс и Уитби-Стривенс 1984 , с. 133, § 7.4 Процесс начальной загрузки и INTCODE объясняют роль интерпретатора INTCODE.
- ^ Ричардс и Уитби-Стривенс 1984 , с. 136, § 7.4.3 В примере приведен пример перевода программы BCPL в INTCODE для интерпретатора.
- ^ Вольф, Марк Дж. П. (2008). «Глоссарий» . Взрыв видеоигр: история от PONG до PlayStation и не только . Академик Блумсбери. п. 315. ИСБН 978-0-313-33868-7 .
- ^ Перейти обратно: а б с Грабарчик, Павел; Ошет, Эспен (2019), Порт или конверсия? Онтологическая основа классификации версий игр | Конференция ДиГРА 2019
- ^ Николл, Бенджамин (2015). «Преодоление разрыва: Neo Geo, воображаемое медиа и приручение аркадных игр». Игры и культура . дои : 10.1177/1555412015590048 . S2CID 147981978 .
- ^ Перейти обратно: а б Бунтен, Дэн (декабрь 1984 г.). «Отправления / идеи с фронта дизайна стратегических игр» . Мир компьютерных игр . п. 40 . Проверено 31 октября 2013 г.
- ^ Перейти обратно: а б «Конференция компьютерных игр CGW» . Мир компьютерных игр (панельная дискуссия). Октябрь 1984 г. с. 30 . Проверено 31 октября 2013 г.
- ^ Даннингтон, Бенн; Браун, Марк Р.; Малькольм, Том (январь – февраль 1987 г.). «Галерея 64/128» . Информация . стр. 14–21.
- ^ Стэнтон, Джеффри; Уэллс, Роберт П.; Роховански, Сандра; Меллид, Майкл, ред. (1984). Книга Аддисона-Уэсли о программном обеспечении Atari . Аддисон-Уэсли. стр. 12, 21, 44, 126. ISBN. 0-201-16454-Х .
- ^ Бернштейн, Харви (май 1985 г.). «За пределами замка Вольфенштейн» . Антик . п. 83 . Проверено 8 января 2015 г.
- ^ Бунтен, Дэн. «Сборник игр» . Озарк Softscape MULE . Проверено 4 октября 2017 г.
- ^ Якал, Кэти (июнь 1986 г.). «Эволюция графики Commodore» . Бюллетень Compute ! стр. 34–42 . Проверено 18 июня 2019 г.
- ^ Кент, Стивен (2001). Полная история видеоигр . Пресса «Три реки» . п. 190. ИСБН 0-7615-3643-4 .
- ^ Кент, Стивен (2001). «Падение». Полная история видеоигр . Пресса «Три реки» . стр. 237–239. ISBN 978-0-7615-3643-7 .
- Ричардс, Мартин ; Уитби-Стривенс, Колин (1984). BCPL, язык и его компилятор . Издательство Кембриджского университета. ISBN 0-521-28681-6 .
- Таненбаум, Эндрю С. (1984). Структурированная компьютерная организация . Прентис-Холл. ISBN 0-13-854605-3 .