Кросс-компилятор

Кросс -компилятор — это компилятор, способный создавать исполняемый код для платформы, отличной от той, на которой работает компилятор. Например, компилятор, который работает на ПК , но генерирует код, который работает на устройствах Android, является кросс-компилятором.

Кросс-компилятор полезен для компиляции кода для нескольких платформ с одного хоста разработки. Прямая компиляция на целевой платформе может оказаться невозможной, например, во встроенных системах с ограниченными вычислительными ресурсами.

Кросс-компиляторы отличаются от компиляторов исходного кода . Кросс-компилятор предназначен для кроссплатформенной генерации машинного кода, а компилятор из исходного кода переводит с одного языка кодирования на другой в текстовом коде. Оба являются инструментами программирования .

Использовать

Основное использование кросс-компилятора — отделение среды сборки от целевой среды. Это полезно в нескольких ситуациях:

• Встроенные компьютеры , устройства которых имеют сильно ограниченные ресурсы. Например, микроволновая печь будет иметь очень маленький компьютер, который будет считывать данные с клавиатуры и дверного датчика, обеспечивать вывод данных на цифровой дисплей и динамик, а также управлять микроволновой печью для приготовления пищи. Этот компьютер обычно недостаточно мощный для запуска компилятора, файловой системы или среды разработки.
• Компиляция для нескольких машин. Например, компания может захотеть поддерживать несколько разных версий операционной системы или несколько разных операционных систем. Используя кросс-компилятор, можно настроить единую среду сборки для компиляции для каждой из этих целей.
• Компиляция на ферме серверов . Подобно компиляции для нескольких машин, сложная сборка, включающая множество операций компиляции, может быть выполнена на любой свободной машине, независимо от ее базового оборудования или версии операционной системы, на которой она работает.
• Загрузка на новую платформу. При разработке программного обеспечения для новой платформы или эмулятора будущей платформы используется кросс-компилятор для компиляции необходимых инструментов, таких как операционная система и собственный компилятор.
• Компиляция собственного кода для эмуляторов для старых, ныне устаревших платформ, таких как Commodore 64 или Apple II, энтузиастами, использующими кросс-компиляторы, работающие на текущей платформе (например, кросс-компиляторы MS-DOS 6502 от Aztec C, работающие под Windows XP ).

Использование виртуальных машин (таких как Java JVM ) устраняет некоторые причины, по которым были разработаны кросс-компиляторы. Парадигма виртуальной машины позволяет использовать один и тот же вывод компилятора в нескольких целевых системах, хотя это не всегда идеально, поскольку виртуальные машины часто работают медленнее, и скомпилированную программу можно запускать только на компьютерах с этой виртуальной машиной.

Обычно аппаратная архитектура отличается (например, кодирование программы, предназначенной для архитектуры MIPS на компьютере x86 ), но кросс-компиляция также может использоваться, когда отличается только среда операционной системы , как при компиляции программы FreeBSD под Linux , или даже только системной библиотеки. , как при компиляции программ с помощью uClibc на хосте glibc .

Канадский крест

Канадский крест — это метод создания кросс-компиляторов для других машин, где исходная машина намного медленнее или менее удобна, чем целевая. Учитывая три машины A, B и C, одна использует машину A (например, с Windows XP на процессоре IA-32 ) для создания кросс-компилятора, который работает на машине B (например, с macOS на процессоре x86-64 ) для создания исполняемых файлов. для машины C (например, под управлением Android на процессоре ARM ). Практическое преимущество в этом примере состоит в том, что машина A медленная, но имеет собственный компилятор, тогда как машина B быстрая, но вообще не имеет компилятора, а машина C непрактично медленна, чтобы ее можно было использовать для компиляции.

При использовании Canadian Cross с GCC, как в этом примере, может быть задействовано четыре компилятора.

• Собственный собственный компилятор для машины A (1) (например, компилятор из Microsoft Visual Studio ) используется для создания собственного компилятора gcc для машины A (2) .
• Собственный компилятор gcc для машины A (2) используется для сборки кросс-компилятора gcc с машины A на машину B (3).
• Кросс-компилятор gcc с машины A на машину B (3) используется для сборки кросс-компилятора gcc с машины B на машину C (4).

Кросс-компилятор конечного результата (4) не сможет работать на машине сборки A; вместо этого он запускался на машине B для компиляции приложения в исполняемый код, который затем копировался на машину C и выполнялся на машине C.

Например, NetBSD предоставляет POSIX сценарий оболочки Unix с именем build.sh который сначала создаст свой собственный набор инструментов с помощью компилятора хоста; это, в свою очередь, будет использовано для создания кросс-компилятора, который будет использоваться для сборки всей системы.

Термин «Канадский крест» возник потому, что на момент обсуждения этих вопросов в Канаде действовало три национальные политические партии.

Хронология ранних кросс-компиляторов

• 1979 — АЛГОЛ 68C сгенерировал ZCODE ; это помогло перенести компилятор и другие приложения ALGOL 68 на альтернативные платформы. Для компиляции компилятора АЛГОЛ 68С требовалось около 120 КБ памяти. Память Z80 объемом 64 КБ слишком мала для фактической компиляции компилятора. Таким образом, для Z80 сам компилятор должен был быть кросс-компилирован с более крупного компьютера с возможностями CAP или мэйнфрейма IBM System/370 .

GCC и кросс-компиляция

GCC , набор бесплатных компиляторов, можно настроить для кросс-компиляции. Он поддерживает множество платформ и языков.

GCC требует, чтобы скомпилированная копия binutils была доступна для каждой целевой платформы. Особенно важен GNU Assembler . Поэтому сначала необходимо правильно скомпилировать binutils с помощью переключателя. --target=some-target отправляется в скрипт настройки . GCC также должен быть настроен с тем же --target вариант. Затем GCC можно запустить в обычном режиме при условии, что инструменты, создаваемые binutils , доступны по пути , что можно сделать, используя следующее (в UNIX-подобных операционных системах с bash):

PATH=/path/to/binutils/bin:${PATH} make

Кросс-компиляция GCC требует, чтобы часть целевой платформы стандартной библиотеки C была доступна на хост-платформе . Программист может выбрать полную компиляцию библиотеки C, но этот выбор может оказаться ненадежным. Альтернативой является использование newlib — небольшой библиотеки C, содержащей только самые необходимые компоненты, необходимые для компиляции C. исходного кода

Пакеты GNU Autotools (т.е. autoconf , automake и libtool ) используют понятие платформы сборки , хост-платформы и целевой платформы . Платформа сборки — это то место, где фактически компилируется компилятор. В большинстве случаев сборку следует оставить неопределенной (по умолчанию она будет установлена ​​на хосте). Хост -платформа всегда является местом, где выходные артефакты компилятора будут выполняться независимо от того, является ли вывод другим компилятором или нет. Целевая платформа используется при кросс-компиляции кросс-компиляторов и определяет, какой тип объектного кода будет создавать пакет; в противном случае настройка целевой платформы не имеет значения. Например, рассмотрим кросс-компиляцию видеоигры, которая будет работать на Dreamcast . Машина, на которой компилируется игра, является платформой сборки, а Dreamcast — хост-платформой . Имена хост и цель относятся к используемому компилятору и смещаются как сын и внук .

Другой метод, широко используемый разработчиками встраиваемых систем Linux, предполагает сочетание компиляторов GCC со специализированными песочницами, такими как Scratchbox и Scratchbox 2 или PROot . Эти инструменты создают изолированную программную среду с chroot -окружением, в которой программист может создавать необходимые инструменты, библиотеки libc и библиотеки без необходимости устанавливать дополнительные пути. Также предусмотрены средства для «обмана» среды выполнения, чтобы она «полагала», что действительно работает на предполагаемом целевом ЦП (например, в архитектуре ARM); это позволяет сценариям настройки и т.п. запускаться без ошибок. Scratchbox работает медленнее по сравнению с «некорневыми» методами, и для работы большинство инструментов, находящихся на хосте, необходимо переместить в Scratchbox.

Кросс-компиляторы Manx Aztec C

Компания Manx Software Systems из Шрусбери , штат Нью-Джерси , начиная с 1980-х годов, производила компиляторы C , ориентированные на профессиональных разработчиков для различных платформ, включая совместимые с IBM PC и Mac .

компании Manx Aztec C Язык программирования был доступен для различных платформ, включая MS-DOS , Apple II , DOS 3.3 и ProDOS , Commodore 64 , Mac 68k. и Друг .

С 1980-х годов и на протяжении 1990-х годов, пока не исчезли Manx Software Systems, версия Aztec C для MS-DOS предлагался как компилятор в собственном режиме, так и как кросс-компилятор для других платформ с разными процессорами, включая Commodore 64. и Apple II. В Интернете все еще существуют дистрибутивы Aztec C, включая их кросс-компиляторы на базе MS-DOS. Они используются до сих пор.

Aztec C86 компании Manx, их родной компилятор MS-DOS 8086 , также был кросс-компилятором. Хотя он не компилировал код для другого процессора, как их кросс-компиляторы Aztec C65 6502 для Commodore 64 и Apple II, он создавал двоичные исполняемые файлы для устаревших на тот момент операционных систем для 16-битного семейства процессоров 8086.

Когда IBM PC был впервые представлен, он был доступен с выбором операционных систем, CP/M-86 и PC DOS двумя из которых были . Aztec C86 был снабжен библиотеками ссылок для генерации кода для обеих операционных систем IBM PC . На протяжении 1980-х годов в более поздних версиях Aztec C86 (3.xx, 4.xx и 5.xx) добавлялась поддержка MS-DOS 1 и 2. «временных» версий и которые были менее надежными, чем «базовая» версия MS-DOS 3 и более поздние версии, на которую Aztec C86 ориентировался до своей кончины.

Наконец, Aztec C86 предоставил разработчикам языка C возможность создавать -код, совместимый с ПЗУ «HEX» , который затем можно было передать с помощью устройства записи ПЗУ непосредственно в процессор на базе 8086. Паравиртуализация может быть более распространена сегодня, но практика создания низкоуровневого ПЗУ-кода была более распространена на душу населения в те годы, когда разработка драйверов устройств часто выполнялась программистами приложений для отдельных приложений, а новые устройства представляли собой кустарное производство . Программисты приложений нередко взаимодействовали напрямую с оборудованием без поддержки производителя. Эта практика была похожа на сегодняшнюю разработку встраиваемых систем .

Томас Фенвик и Джеймс Гудноу II были двумя основными разработчиками Aztec-C. Позже Фенвик стал известен как автор Microsoft Windows CE ядра или NK («Новое ядро»), как его тогда называли.

Кросс-компиляторы Microsoft C

Ранняя история - 1980-е годы.

Microsoft C (MSC) имеет более короткую историю, чем другие начиная с 1980-х годов. Первые компиляторы Microsoft C были созданы той же компанией, которая создала Lattice C , и были переименованы Microsoft в их собственные, пока не был выпущен MSC 4, который стал первой версией, созданной Microsoft самостоятельно.

В 1987 году многие разработчики начали переходить на Microsoft C, и многие другие последовали их примеру на протяжении всего развития Microsoft Windows до ее нынешнего состояния. Появились такие продукты, как Clipper и позже Clarion , которые предлагали легкую разработку приложений для баз данных с использованием межъязыковых методов, позволяя компилировать часть их программ с помощью Microsoft C.

Borland C (калифорнийская компания) можно было купить за несколько лет до того, как Microsoft выпустила свой первый продукт на языке C.

Задолго до Borland BSD Unix (Университет Беркли) получил C от авторов языка C: Кернигана и Ритчи , которые написали его в унисон, работая в AT&T (лаборатории). Первоначальные потребности K&R заключались не только в элегантном анализируемом синтаксисе 2-го уровня для замены синтаксиса синтаксиса синтаксического анализа 1-го уровня asm: он был разработан таким образом, чтобы минимальный объем кода asm был написан для поддержки каждой платформы (исходная конструкция C заключалась в возможности перекрестной компиляции с использованием C с минимум кода поддержки для каждой платформы, который им нужен.). Также вчерашний C напрямую связан с кодом ASM, если он не зависит от платформы. Сегодняшний C (особенно C++) больше не совместим с C, и базовый код asm может сильно отличаться от кода, написанного на конкретной платформе (в Linux: он иногда заменяет и обходит вызовы библиотеки с выбором дистрибьютора). Сегодняшний C — это язык 3-го или 4-го уровня, который по-старому используется как язык 2-го уровня.

1987

Программы на языке C уже давно связаны с модулями, написанными на языке ассемблера . Большинство компиляторов C (даже современные компиляторы) предлагают проход на языке ассемблера (который можно настроить для повышения эффективности, а затем связать с остальной частью программы после сборки).

Компиляторы, такие как Aztec-C, преобразовывали все на язык ассемблера в отдельный проход, а затем собирали код в отдельный проход и были известны своим очень эффективным и небольшим кодом, но к 1987 году оптимизатор, встроенный в Microsoft C, был очень хорош, и только «Критически важные» части программы обычно рассматривались для переписывания. Фактически, программирование на языке C стало языком «самого низкого уровня», при этом программирование стало мультидисциплинарной развивающейся отраслью, а проекты стали крупнее, программисты писали пользовательские интерфейсы и интерфейсы баз данных на языках более высокого уровня, и возникла необходимость возникли для межъязыкового развития, которое продолжается и по сей день.

К 1987 году, с выпуском MSC 5.1, Microsoft предложила межъязыковую среду разработки для MS-DOS. 16-битный двоичный объектный код, написанный на языке ассемблера ( MASM ) и других языках Microsoft, включая QuickBASIC , Pascal и Fortran , можно было связать вместе в одну программу в процессе, который они назвали «Программирование на смешанных языках», а теперь и «Межъязыковой вызов». Если BASIC в этом сочетании использовался , основная программа должна была быть на BASIC для поддержки внутренней системы выполнения , которая компилировала BASIC, необходимый для сборки мусора, и других управляемых операций, которые имитировали интерпретатор BASIC, такой как QBasic, в MS-DOS.

В частности, соглашение о вызовах для кода C заключалось в передаче параметров в «обратном порядке» в стеке и возврате значений в стеке, а не в регистре процессора . Существовали и другие правила программирования, обеспечивающие совместную работу всех языков, но это конкретное правило сохранялось в ходе межъязыковой разработки, которая продолжалась в 16- и 32-разрядных версиях Windows , а также при разработке программ для OS/2 и сохраняется до сих пор. день. Это известно как соглашение о вызовах Паскаля .

Другой тип кросс-компиляции, для которого в то время использовался Microsoft C, был в розничных приложениях, требующих портативных устройств , таких как Symbol Technologies PDT3100 (используемый для инвентаризации ), который предоставлял библиотеку ссылок, ориентированную на 8088 на базе считыватель штрих-кодов . Приложение создавалось на главном компьютере, а затем передавалось на портативное устройство (по последовательному кабелю ), где оно запускалось, подобно тому, что сегодня делается для того же рынка с использованием Windows Mobile такими компаниями, как Motorola , купившими символ.

Начало 1990-х

На протяжении 1990-х годов, начиная с MSC 6 (их первого компилятора, совместимого с ANSI C ), Microsoft переориентировала свои компиляторы C на развивающийся рынок Windows, а также на OS/2 и разработку программ с графическим интерфейсом . Совместимость со смешанными языками осталась в MSC 6 на стороне MS-DOS, но API для Microsoft Windows 3.0 и 3.1 был написан в MSC 6. MSC 6 также был расширен для обеспечения поддержки 32-битных сборок и поддержки новой Windows для рабочих групп. и Windows NT , которая легла в основу Windows XP . Была введена практика программирования, называемая thunk , чтобы обеспечить переход между 16- и 32-битными программами, которые использовали преимущества привязки во время выполнения ( динамическое связывание ), а не статическое связывание , которое предпочиталось в монолитных 16-битных приложениях MS-DOS. Некоторые разработчики собственного кода по-прежнему предпочитают статическое связывание, но оно обычно не обеспечивает степень повторного использования кода , требуемую новыми передовыми практиками, такими как модель зрелости возможностей (CMM).

Поддержка MS-DOS по-прежнему предоставлялась с выпуском первого компилятора C++ от Microsoft, MSC 7, который был обратно совместим с языком программирования C и MS-DOS и поддерживал генерацию как 16-, так и 32-битного кода.

MSC продолжила работу с того места, на котором Aztec C86 остановился . Доля рынка компиляторов C перешла к кросс-компиляторам, которые использовали преимущества новейших и лучших функций Windows, предлагали C и C++ в одном пакете и по-прежнему поддерживали системы MS-DOS, которым уже десять лет, а также небольшие компании, которые Созданные компиляторы, такие как Aztec C, больше не могли конкурировать и либо обратились к нишевым рынкам, таким как встроенные системы , либо исчезли.

Поддержка MS-DOS и генерации 16-битного кода продолжалась до версии MSC 8.00c, которая входила в состав Microsoft C++ и Microsoft Application Studio 1.5, предшественника Microsoft Visual Studio , которая представляет собой среду перекрестной разработки, предоставляемую Microsoft сегодня.

Конец 1990-х

MSC 12 был выпущен вместе с Microsoft Visual Studio 6 и больше не обеспечивал поддержку 16-битных двоичных файлов MS-DOS, вместо этого предоставляя поддержку 32-битных консольных приложений, но обеспечивал поддержку генерации кода Windows 95 и Windows 98, а также для Windows NT. . Библиотеки ссылок были доступны для других процессоров, работающих под управлением Microsoft Windows; практика, которую Microsoft продолжает и по сей день.

MSC 13 был выпущен вместе с Visual Studio 2003 , а MSC 14 — с Visual Studio 2005 , оба из которых по-прежнему создают код для старых систем, таких как Windows 95, но которые будут создавать код для нескольких целевых платформ, включая рынок мобильных устройств и архитектуру ARM .

.NET и не только

В 2001 году Microsoft разработала среду Common Language Runtime (CLR), которая легла в основу компилятора .NET Framework в Visual Studio IDE. Этот уровень операционной системы, находящийся в API, позволяет смешивать языки разработки, скомпилированные на разных платформах, на которых работает операционная система Windows.

Среда выполнения .NET Framework и среда CLR обеспечивают уровень сопоставления основных процедур процессора и устройств на целевом компьютере. Компилятор C командной строки в Visual Studio компилирует собственный код для различных процессоров и может использоваться для создания самих основных процедур.

Приложения Microsoft .NET для целевых платформ, таких как Windows Mobile , на архитектуре ARM , кросс-компилируются на компьютерах Windows с различными процессорами, а Microsoft также предлагает эмуляторы и среды удаленного развертывания, которые требуют минимальной настройки, в отличие от кросс-компиляторов прошлых лет или сейчас. другие платформы.

Библиотеки времени выполнения, такие как Mono , обеспечивают совместимость кросс-скомпилированных программ .NET с другими операционными системами, такими как Linux .

Такие библиотеки, как Qt и его предшественники, включая XVT, обеспечивают возможность перекрестной разработки на уровне исходного кода с другими платформами, при этом по-прежнему используя Microsoft C для создания версий Windows. Другие компиляторы, такие как MinGW, также стали популярными в этой области, поскольку они более напрямую совместимы с Unix-системами, которые составляют не-Windows-сторону разработки программного обеспечения, что позволяет разработчикам ориентироваться на все платформы, используя знакомую среду сборки.

Бесплатный Паскаль

Free Pascal с самого начала разрабатывался как кросс-компилятор. Исполняемый файл компилятора (ppcXXX, где XXX — целевая архитектура) способен создавать исполняемые файлы (или просто объектные файлы, если внутренний компоновщик не существует, или даже просто файлы сборки, если внутренний ассемблер не существует) для всех ОС одной и той же архитектуры. Например, ppc386 способен создавать исполняемые файлы для i386-linux, i386-win32, i386-go32v2 (DOS) и всех других ОС (см. ). Однако для компиляции в другую архитектуру сначала необходимо собрать кросс-архитектурную версию компилятора. В названии полученного исполняемого файла компилятора перед целевой архитектурой будет добавлено дополнительное слово «ross». т.е. если компилятор создан для x64, то исполняемым файлом будет ppcrossx64.

Для компиляции под выбранную архитектуру ОС можно использовать ключи компилятора (для драйвера компилятора fpc) -P и -T. Это также делается при кросс-компиляции самого компилятора, но устанавливается через опции make CPU_TARGET и OS_TARGET. Ассемблер и компоновщик GNU для целевой платформы требуются, если Free Pascal еще не имеет внутренней версии инструментов для целевой платформы.

Кланг

Clang изначально является кросс-компилятором, и во время сборки вы можете выбрать, на какие архитектуры вы хотите, чтобы Clang мог ориентироваться.

См. также

• МинГВ
• Скретчбокс 2
• Бесплатный Паскаль
• Крестовый ассемблер

Внешние ссылки

• Инструменты кросс-компиляции - справочник по настройке инструментов кросс-компиляции GNU.
• Создание цепочек кросс-инструментов с помощью gcc — это вики, содержащая другие ссылки на кросс-компиляцию GCC.
• Scratchbox — это набор инструментов для кросс-компиляции Linux на ARM и x86.
• Grand Unified Builder (GUB) для Linux для перекрестной компиляции нескольких архитектур, например: Win32/Mac OS/FreeBSD/Linux, используемых GNU LilyPond.
• Crosstool — это полезная цепочка скриптов . , которая создает среду кросс-компиляции Linux для желаемой архитектуры, включая встроенные системы
• Crosstool-NG — это переписанная версия Crosstool, которая помогает создавать цепочки инструментов.
• buildroot — это еще один набор скриптов для создания цепочки инструментов на основе uClibc , обычно для встраиваемых систем. Он используется OpenWrt .
• ELDK (Комплект разработки для встроенного Linux) . Используется Das U-Boot .
• T2 SDE — это еще один набор сценариев для создания целых систем Linux на основе GNU libC, uClibc или Dietlibc для различных архитектур.
• Кросс-Linux с нуля. Проект
• У IBM есть очень четкое структурированное руководство по перекрестному построению цепочки инструментов GCC.
• (на французском языке) Кросс-компиляция avec GCC 4 sous Windows для Linux - Учебное пособие по созданию цепочки инструментов для перекрестных GCC, но при переходе от Windows к Linux эта тема разрабатывается редко.