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 года The Hobbit , текстовое приключение, дополненное графическими изображениями, имеет значительно разные графические стили в диапазоне персональных компьютеров, для которых были разработаны ее порты. [10] Однако многие видеоигры 21-го века разрабатываются с использованием программного обеспечения (часто на C++ ), которое может выводить код для одной или нескольких консолей, а также для ПК без необходимости фактического портирования (вместо этого полагаясь на общее портирование отдельных библиотек компонентов ). [10]

Перенос аркадных игр на домашние системы с некачественным оборудованием был сложным. Перенесенная версия Pac-Man для Atari 2600 опустила многие визуальные особенности оригинальной игры, чтобы компенсировать нехватку места в ПЗУ , и оборудование боролось, когда на экране появлялось несколько призраков, создавая эффект мерцания. Некоторые ученые называют низкую производительность Atari 2600 Pac-Man причиной краха видеоигр в 1983 году . [11]

Многие ранние порты страдали от значительных проблем с качеством игрового процесса, поскольку компьютеры сильно различались. [12] Ричард Гэрриот заявил в 1984 году на ярмарке игр Origins , что Origin Systems сначала разработала видеоигры для Apple II , а затем портировала их на компьютеры Commodore 64 и Atari 8-bit , поскольку спрайты и другие сложные функции последних машин делали портирование с них на 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. ^ Whitten, DE; Demaine, PAD (март 1975). «Независимый от машины и конфигурации Fortran: Portable Fortran». IEEE Transactions on Software Engineering . SE-1 (1): 111–124. doi :10.1109/TSE.1975.6312825. S2CID  16485156.
  2. ^ "Проблемы переносимости". .. обсуждает .. переносимость .. Fortran
  3. ^ "port, v.2" . Oxford English Dictionary (OED Online) . Oxford University Press . Получено 21 декабря 2017 г. . Происхождение: Имеет несколько источников. Частично заимствование из французского. Частично заимствование из латыни. Этимоны: фр. porter ; лат. 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. ^ Вольф, Марк Дж. П. (2008). «Глоссарий». Взрыв видеоигр: история от PONG до Playstation и далее . Bloomsbury Academic. стр. 315. ISBN 978-0-313-33868-7.
  10. ^ abc Грабарчик, Павел; Аарсет, Эспен (2019), Порт или преобразование? Онтологическая структура для классификации версий игр | Конференция DiGRA 2019
  11. ^ Николл, Бенджамин (2015). «Преодоление разрыва: Neo Geo, медиа-воображаемое и одомашнивание аркадных игр». Игры и культура . doi : 10.1177/1555412015590048. S2CID  147981978.
  12. ^ ab Bunten, Dan (декабрь 1984 г.). «Отчеты / Взгляд с фронта разработки стратегических игр». Computer Gaming World . стр. 40. Получено 31 октября 2013 г.
  13. ^ ab "The CGW Computer Game Conference". Computer Gaming World (панельная дискуссия). Октябрь 1984. стр. 30. Получено 31 октября 2013 .
  14. ^ Даннингтон, Бенн; Браун, Марк Р.; Малкольм, Том (январь–февраль 1987 г.). «Галерея 64/128». Информация . стр. 14–21.
  15. ^ Стэнтон, Джеффри; Уэллс, Роберт П.; Роховански, Сандра; Меллид, Майкл, ред. (1984). Книга Эддисона-Уэсли о программном обеспечении Atari. Эддисон-Уэсли. стр. 12, 21, 44, 126. ISBN 0-201-16454-X.
  16. ^ Бернстайн, Харви (май 1985). "Beyond Castle Wolfenstein". Antic . стр. 83. Получено 8 января 2015 г.
  17. ^ Бантен, Дэн. «Коллекция игр». Ozark Softscape MULE . Получено 04.10.2017 .
  18. ^ Якал, Кэти (июнь 1986 г.). «Эволюция графики Commodore». Compute!'s Gazette . стр. 34–42 . Получено 18 июня 2019 г.
  19. ^ Кент, Стивен (2001). Полная история видеоигр . Three Rivers Press . стр. 190. ISBN 0-7615-3643-4.
  20. ^ Кент, Стивен (2001). «Падение». Полная история видеоигр . Three Rivers Press . С. 237–239. ISBN 978-0-7615-3643-7.