В программной инженерии , портирование это процесс адаптации программного обеспечения с целью достижения того или иную формы исполнения в вычислительной среде , отличные от того , что данная программа (предназначено для такого исполнения) была первоначально разработана для (например, различных CPU , операционная система или сторонняя библиотека ). Этот термин также используется, когда программное обеспечение / оборудование изменяется, чтобы сделать их пригодными для использования в различных средах. [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 .
Портирование видеоигр
Перенос также используется, когда видеоигра, предназначенная для работы на одной платформе, будь то аркада , игровая консоль или персональный компьютер , конвертируется для работы на другой платформе. С начала видеоигр до 1990-х годов «порты», в то время часто известные как «преобразования», часто были не настоящими портами, а скорее переработанными версиями игр из-за ограничений различных систем. Например, игра The Hobbit 1982 года , текстовое приключение, дополненное графическими изображениями, имеет значительно разные графические стили для всех персональных компьютеров, для которых были разработаны ее порты. [9] Однако многие видеоигры 21 века разрабатываются с использованием программного обеспечения (часто на C ++ ), которое может выводить код для одной или нескольких консолей, а также для ПК без необходимости фактического переноса (вместо этого полагаясь на общий перенос отдельных компонентов библиотеки ). [9]
Перенести аркадные игры на домашние системы с некачественным оборудованием было сложно. В перенесенной версии Pac-man для Atari 2600 были пропущены многие визуальные особенности оригинальной игры, чтобы компенсировать нехватку места в ПЗУ, а аппаратное обеспечение испытывало трудности, когда на экране появлялось несколько призраков, создавая эффект мерцания. Плохая производительность портированного Pac-Man упоминается некоторыми учеными как причина сбоя видеоигры в 1983 году . [10]
Многие ранние порты страдали от серьезных проблем с качеством игры, потому что компьютеры сильно различались. [11] Ричард Гэрриот заявил в 1984 году на выставке Origins Game Fair, что Origin Systems сначала разработала компьютерные игры для серии Apple II, а затем перенесла их на Commodore 64 и Atari 8-bit , поскольку спрайты последних машин и другие сложные функции сделали перенос из них Apple «гораздо сложнее, возможно, даже невозможно». [12] Обзоры жаловались на порты, которые пострадали от «конверсии Apple» [13], сохранив «паршивый звук от Apple и черно-бело-зелено-пурпурную графику»; [14] [15] после заявления Гэрриота, когда Дэн Бунтен спросил: «Люди из Atari и Commodore в аудитории, довольны ли вы переписыванием Apple?» публика кричала: «Нет!» Гэрриот ответил: «[в противном случае] версия для Apple никогда не будет готова. С точки зрения издателя, это не с точки зрения денег». [12]
Остальные работали иначе. Ozark Softscape , например, сначала написал MULE для Atari, потому что он предпочитал разрабатывать для самых продвинутых компьютеров, удаляя или изменяя функции по мере необходимости во время портирования. Такая политика не всегда была осуществима; Бунтен заявил, что «MULE нельзя сделать для Apple» [11], и что версии «Семи городов золота», не относящиеся к Atari, уступают. [16] Газета Compute! Писала в 1986 году, что при переносе с Atari на Commodore оригинал обычно лучше. Как сообщает журнал, качество последних игр улучшилось, когда в конце 1983 года разработчики начали создавать для них новое программное обеспечение. [17]
При переносе аркадных игр термины «идеальная аркада» или «точная аркада» часто использовались для описания того, насколько близко игровой процесс, графика и другие ресурсы в перенесенной версии соответствуют аркадной версии. Многие аркадные порты в начале 1980-х были далеки от аркадного совершенства, поскольку домашним консолям и компьютерам не хватало сложного оборудования для аркадных игр, но игры все же могли приблизиться к игровому процессу. Примечательно, что Space Invaders на Atari VCS , несмотря на свои отличия, стала смертоносным приложением для консоли [18], в то время как более поздний порт Pac-Man был печально известен своими отклонениями от аркадной версии. [19] Аркадные игры стали более распространенными, начиная с 1990-х годов, начиная с системы Neo Geo от SNK , которая предлагала как домашнюю консоль, так и аркадную систему с более продвинутыми версиями основного оборудования домашней консоли. Это позволяло играть дома в идеальные аркадные игры. Новые консоли, такие как PlayStation и Dreamcast , также основанные на аркадном оборудовании, сделали идеальные аркадные игры реальностью. [9]
«(Консольный) порт» - это игра, которая изначально была создана для консоли (такой как Wii или Xbox 360 ) до того, как была создана идентичная версия, в которую можно играть на персональном компьютере или любой другой консоли. Этот термин широко используется игровым сообществом. Процесс переноса игры с консоли на ПК часто рассматривается отрицательно из-за более высоких уровней производительности, которые компьютеры, как правило, недоиспользуются, частично из-за того, что оборудование консоли ремонтируется на протяжении всего их запуска (игры разрабатываются для консольных спецификаций), в то время как ПК становятся более мощными по мере развития оборудования, но также из-за того, что портированные игры иногда плохо оптимизированы для ПК или портируются лениво. Хотя в целом они схожи, могут существовать архитектурные различия, такие как использование единой памяти на консоли.
Смотрите также
- Переносимость программного обеспечения
- Привязка к языку
- Эмулятор консоли
- Список атрибутов качества системы
- Исходный порт
- Пишите один раз, компилируйте где угодно
- Пошлиб
- Кроссплатформенность
- Трансформация программы
- Значение непортированного
Заметки
- ^ Whitten, DE; Demaine, PAD (март 1975 г.). «Фортран, независимый от машины и конфигурации: Portable Fortran». IEEE Transactions по разработке программного обеспечения . SE-1 (1): 111–124. DOI : 10.1109 / TSE.1975.6312825 . S2CID 16485156 .
- ^ «Проблемы переносимости» .
.. обсуждает .. переносимость .. Fortran
- ^ "порт, v.2" . Оксфордский словарь английского языка (OED Online) . Издательство Оксфордского университета . Проверено 21 декабря 2017 года .
Происхождение: Множественное происхождение. Частично заимствование из французского. Отчасти заимствование из латыни. Этимоны: французский портер ; Латинский portāre . ... 1. пер. Нести, нести или передавать; принести.
- Перейти ↑ Tanenbaum 1984 , p. 3. §1.1 «Языки, уровни и виртуальные машины» описывает термины и их отношения.
- Перейти ↑ Tanenbaum 1984 , p. 2. гл. 1 Введение объясняет письменный и устный перевод.
- ^ Ричардс и Уитби-Стревенс 1984 , стр. 124. §7.1 Введение объясняет переносимость компилятора с использованием промежуточного кода.
- ^ Ричардс и Уитби-Стревенс 1984 , стр. 133. §7.4 Процесс начальной загрузки и INTCODE объясняет роль интерпретатора INTCODE.
- ^ Ричардс и Уитби-Стревенс 1984 , стр. 136. §7.4.3 Пример дает пример перевода программы BCPL в INTCODE для интерпретатора.
- ^ а б в Грабарчик, Павел; Ошет, Эспен (2019). «Перенос или преобразование? Онтологическая основа для классификации версий игры». Цитировать журнал требует
|journal=
( помощь ) - ^ Николл, Бенджамин (2015). «Преодоление разрыва: Neo Geo, медиа-воображаемое и приручение аркадных игр». Игры и культура . DOI : 10,1177 / 1555412015590048 . S2CID 147981978 .
- ^ а б Бунтен, Дэн (декабрь 1984). «Сообщения / идеи с фронта разработки стратегических игр» . Компьютерный игровой мир . п. 40 . Проверено 31 октября 2013 года .
- ^ а б «Конференция по компьютерным играм CGW» . Computer Gaming World (панельная дискуссия). Октябрь 1984. с. 30 . Проверено 31 октября 2013 года .
- ^ Даннингтон, Бенн; Brown, Mark R .; Малькольм, Том (январь – февраль 1987 г.). «Галерея 64/128» . Информация . С. 14–21.
- ^ Стэнтон, Джеффри; Уэллс, Роберт П .; Рохованский, Сандра; Меллид, Майкл, ред. (1984). Книга Аддисона-Уэсли об Atari Software . Эддисон-Уэсли. стр. 12, 21, 44, 126. ISBN 0-201-16454-X.
- ^ Бернштейн, Харви (май 1985 г.). «За пределами Замка Вольфенштейн» . Античный . п. 83 . Проверено 8 января 2015 года .
- ^ Бунтен, Дэн. «Коллекция игр» . Ozark Softscape MULE . Проверено 4 октября 2017 .
- ^ Якал, Кэти (июнь 1986 г.). «Эволюция коммодорной графики» . Compute! S Gazette . С. 34–42 . Проверено 18 июня 2019 .
- ^ Кент, Стивен (2001). Окончательная история видеоигр . Пресса трех рек . п. 190. ISBN 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.