stringtranslate.com

Портирование

В разработке программного обеспечения портирование — это процесс адаптации программного обеспечения с целью достижения некоторой формы выполнения в вычислительной среде , отличной от той, для которой данная программа (предназначенная для такого выполнения) была изначально разработана (например, другой процессор , операционная система или сторонняя библиотека ). Этот термин также используется, когда программное/аппаратное обеспечение изменяется, чтобы сделать их пригодными для использования в различных средах. [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]

Написание исходников компилятора полностью на языке программирования, который компилятор должен транслировать, делает возможным на целевой машине следующий подход, более известный как загрузка компилятора :

  1. Портируйте интерпретатор. Это необходимо закодировать в ассемблерном коде , используя уже существующий ассемблер в целевой системе.
  2. Адаптируйте исходный код генератора кода к новой машине.
  3. Выполните адаптированный исходный код, используя интерпретатор с исходным кодом генератора кода в качестве входных данных. Это создаст машинный код для генератора кода.

Сложная часть кодирования процедур оптимизации выполняется с использованием языка высокого уровня вместо целевого языка ассемблера.

По мнению разработчиков языка 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] В обзорах жаловались на порты, пострадавшие от «конверсии Apple», [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]

«Консольный порт» — это игра, которая изначально была создана для консоли, прежде чем была создана идентичная версия, в которую можно играть на персональном компьютере . Этот термин широко используется игровым сообществом. Процесс переноса игры с консоли на ПК часто рассматривается негативно из-за более высокого уровня производительности, который компьютеры обычно не используют в полной мере, частично из-за того, что оборудование консоли исправляется на протяжении всего запуска (игры разрабатываются для консолей), в то время как ПК становятся более мощными по мере развития аппаратного обеспечения, но также и из-за того, что портированные игры иногда плохо оптимизированы для ПК или портируются лениво. Хотя в целом они схожи, могут существовать архитектурные различия, такие как использование единой памяти на консоли.

Смотрите также

Рекомендации

  1. ^ Уиттен, Делавэр; Демейн, PAD (март 1975 г.). «Фортран, независимый от машины и конфигурации: портативный Фортран». Транзакции IEEE по разработке программного обеспечения . СЭ-1 (1): 111–124. дои : 10.1109/TSE.1975.6312825. S2CID  16485156.
  2. ^ «Проблемы переносимости». .. обсуждает .. переносимость .. Фортрана
  3. ^ "порт, v.2" . Оксфордский словарь английского языка (OED Online) . Издательство Оксфордского университета . Проверено 21 декабря 2017 г. Происхождение: Различного происхождения. Частично заимствование из французского языка. Частично заимствование из латыни. Этимоны: французский портер ; Латинское portāre . ... 1. пер. Носить, нести или передавать; принести.
  4. ^ Таненбаум 1984, с. 3. §1.1 «Языки, уровни и виртуальные машины» описывает термины и их отношения.
  5. ^ Таненбаум 1984, с. 2. Ч. 1 Введение объясняет перевод и интерпретацию.
  6. ^ Ричардс и Уитби-Стивенс 1984, с. 124. §7.1 Введение объясняет переносимость компилятора с использованием промежуточного кода.
  7. ^ Ричардс и Уитби-Стивенс 1984, с. 133. §7.4 Процесс начальной загрузки и INTCODE объясняет роль интерпретатора INTCODE.
  8. ^ Ричардс и Уитби-Стивенс 1984, с. 136. В §7.4.3 Пример приводится пример перевода программы BCPL в INTCODE для интерпретатора.
  9. ^ Вольф, Марк JP (2008). «Глоссарий». Взрыв видеоигр: история от PONG до PlayStation и не только . Академик Блумсбери. п. 315. ИСБН 978-0-313-33868-7.
  10. ^ abc Грабарчик, Павел; Ошет, Эспен (2019), Порт или конверсия? Онтологическая основа классификации версий игр | Конференция ДиГРА 2019
  11. ^ Николл, Бенджамин (2015). «Преодоление разрыва: Neo Geo, воображаемое медиа и приручение аркадных игр». Игры и культура . дои : 10.1177/1555412015590048. S2CID  147981978.
  12. ^ Аб Бунтен, Дэн (декабрь 1984 г.). «Отправления / идеи с фронта дизайна стратегических игр». Мир компьютерных игр . п. 40 . Проверено 31 октября 2013 г.
  13. ^ ab "Конференция по компьютерным играм CGW". Мир компьютерных игр (панельная дискуссия). Октябрь 1984 г. с. 30 . Проверено 31 октября 2013 г.
  14. ^ Даннингтон, Бенн; Браун, Марк Р.; Малькольм, Том (январь – февраль 1987 г.). «Галерея 64/128». Информация . стр. 14–21.
  15. ^ Стэнтон, Джеффри; Уэллс, Роберт П.; Роховански, Сандра; Меллид, Майкл, ред. (1984). Книга Аддисона-Уэсли о программном обеспечении Atari. Аддисон-Уэсли. стр. 12, 21, 44, 126. ISBN . 0-201-16454-Х.
  16. ^ Бернштейн, Харви (май 1985 г.). «За пределами замка Вольфенштейн». Антик . п. 83 . Проверено 8 января 2015 г.
  17. ^ Бунтен, Дэн. «Коллекция игр». Озарк Softscape MULE . Проверено 4 октября 2017 г.
  18. ^ Якал, Кэти (июнь 1986 г.). «Эволюция графики Commodore». Бюллетень Compute ! стр. 34–42 . Проверено 18 июня 2019 г.
  19. ^ Кент, Стивен (2001). Полная история видеоигр . Пресса «Три реки» . п. 190. ИСБН 0-7615-3643-4.
  20. ^ Кент, Стивен (2001). "Осень". Полная история видеоигр . Пресса «Три реки» . стр. 237–239. ISBN 978-0-7615-3643-7.