Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Эта статья о переносе программного обеспечения в другую систему. Для настройки двигателя см. Портирование (двигатель) . Информацию о переносе телефонных номеров см. В разделе « Перенос местных номеров» .

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

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

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

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

По мнению разработчиков языка BCPL , интерпретируемый код (в случае BCPL) более компактен, чем машинный код; обычно в два раза больше. Однако интерпретируемый код работает примерно в десять раз медленнее, чем скомпилированный код на той же машине. [8]

Разработчики языка программирования Java пытаются воспользоваться преимуществами компактности интерпретируемого кода, потому что программу Java может потребоваться передать через Интернет, прежде чем выполнение может начаться на целевой виртуальной машине Java .

Портирование видеоигр [ править ]

«Порт (видеоигры)» и «Портирование видеоигр» перенаправляют сюда. Чтобы узнать о других значениях, см. Порт видеоигры .

Перенос также используется, когда видеоигра, предназначенная для работы на одной платформе, будь то аркада , игровая консоль или персональный компьютер , конвертируется для работы на другой платформе. С начала видеоигр до 1990-х годов «порты», в то время часто известные как «преобразования», часто были не настоящими портами, а скорее переработанными версиями игр. Однако многие видеоигры 21 века разрабатываются с использованием программного обеспечения (часто на C ++ ), которое может выводить код для одной или нескольких консолей, а также для ПК без необходимости фактического переноса (вместо этого полагаясь на общий перенос отдельных библиотек компонентов ).

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

Многие ранние порты страдали от серьезных проблем с качеством игры, потому что компьютеры сильно различались. [10] Ричард Гэрриот заявил в 1984 году на выставке Origins Game Fair, что Origin Systems сначала разработала компьютерные игры для серии Apple II, а затем перенесла их на Commodore 64 и Atari 8-bit , поскольку спрайты последних машин и другие сложные функции сделали перенос из них Apple «гораздо сложнее, возможно, даже невозможно». [11] Обзоры жаловались на порты, которые пострадали от «конверсии Apple» [12], сохранив «паршивый звук Apple и черно-бело-зелено-пурпурную графику»;[13][14] после заявления Гэрриота, когда Дэн Бунтен спросил: «Люди из Atari и Commodore в аудитории, довольны ли вы переписыванием Apple?» публика кричала: «Нет!» Гэрриот ответил: «[в противном случае] версия для Apple никогда не будет готова. С точки зрения издателя, это не с точки зрения денег». [11]

Остальные работали иначе. Ozark Softscape , например, сначала написал MULE для Atari, потому что он предпочитал разрабатывать для самых продвинутых компьютеров, удаляя или изменяя функции по мере необходимости во время портирования. Такая политика не всегда была осуществима; Бунтен заявил, что «MULE нельзя сделать для Apple», [10] и что версии «Семи городов золота», не относящиеся к Atari, уступают. [15] Газета Compute! Писала в 1986 году, что при переносе с Atari на Commodore оригинал обычно лучше. Как сообщает журнал, качество последних игр улучшилось, когда в конце 1983 года разработчики начали создавать для них новое программное обеспечение. [16]

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

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

См. Также [ править ]

  • Переносимость программного обеспечения
  • Привязка к языку
  • Эмулятор консоли
  • Список атрибутов качества системы
  • Исходный порт
  • Пишите один раз, компилируйте где угодно
  • Пошлиб
  • Кроссплатформенность
  • Трансформация программы
  • Значение непортированного

Заметки [ править ]

  1. ^ Whitten, DE; Demaine, PAD (март 1975 г.). «Фортран, независимый от машины и конфигурации: Portable Fortran». IEEE Transactions по разработке программного обеспечения . SE-1 (1): 111–124. DOI : 10.1109 / TSE.1975.6312825 . S2CID  16485156 .
  2. ^ «Проблемы переносимости» . .. обсуждает .. переносимость .. Fortran
  3. ^ "порт, v.2" . Оксфордский словарь английского языка (OED Online) . Издательство Оксфордского университета . Проверено 21 декабря 2017 года . Происхождение: Множественное происхождение. Частично заимствование из французского. Отчасти заимствование из латыни. Этимоны: французский портер ; Латинский portāre . ... 1. пер. Нести, нести или передавать; принести.
  4. Перейти ↑ Tanenbaum 1984 , p. 3. §1.1 «Языки, уровни и виртуальные машины» описывает термины и их отношения.
  5. Перейти ↑ Tanenbaum 1984 , p. 2. гл. 1 Введение объясняет письменный и устный перевод.
  6. ^ Ричардс и Уитби-Стревенс 1984 , стр. 124. §7.1 Введение объясняет переносимость компилятора с использованием промежуточного кода.
  7. ^ Ричардс и Уитби-Стревенс 1984 , стр. 133. §7.4 Процесс начальной загрузки и INTCODE объясняет роль интерпретатора INTCODE.
  8. ^ Ричардс и Уитби-Стревенс 1984 , стр. 136. §7.4.3 Пример дает пример перевода программы BCPL в INTCODE для интерпретатора.
  9. ^ Николл, Бенджамин (2015). «Преодоление разрыва: Neo Geo, медиа-воображаемое и приручение аркадных игр». Игры и культура . DOI : 10,1177 / 1555412015590048 . S2CID 147981978 . 
  10. ^ a b Бунтен, Дэн (декабрь 1984 г.). «Сообщения / идеи с фронта разработки стратегических игр» . Компьютерный игровой мир . п. 40 . Проверено 31 октября 2013 года .
  11. ^ а б «Конференция по компьютерным играм CGW» . Computer Gaming World (панельная дискуссия). Октябрь 1984. с. 30 . Проверено 31 октября 2013 года .
  12. ^ Даннингтон, Бенн; Brown, Mark R .; Малькольм, Том (январь – февраль 1987 г.). «Галерея 64/128» . Информация . С. 14–21.
  13. ^ Стэнтон, Джеффри; Уэллс, Роберт П .; Рохованский, Сандра; Меллид, Майкл, ред. (1984). Книга Аддисона-Уэсли об Atari Software . Эддисон-Уэсли. стр. 12, 21, 44, 126. ISBN 0-201-16454-X.
  14. ^ Бернштейн, Харви (май 1985). «За пределами Замка Вольфенштейн» . Античный . п. 83 . Проверено 8 января 2015 года .
  15. ^ Бунтен, Дэн. «Коллекция игр» . Ozark Softscape MULE . Проверено 4 октября 2017 .
  16. ^ Yakal, Kathy (июнь 1986). «Эволюция коммодорной графики» . Compute! S Gazette . С. 34–42 . Проверено 18 июня 2019 .

Ссылки [ править ]

  • Ричардс, Мартин ; Уитби-Стревенс, Колин (1984). BCPL, язык и его компилятор . ISBN 0-521-28681-6.
  • Таненбаум, Эндрю С. (1984). Структурированная компьютерная организация . ISBN 0-13-854605-3.