Кросс -компилятор — это компилятор , способный создавать исполняемый код для платформы , отличной от той, на которой работает компилятор. Например, компилятор, который работает на ПК , но генерирует код, который работает на смартфоне Android , является кросс-компилятором.
Кросс-компилятор полезен для компиляции кода для нескольких платформ с одного хоста разработки. Прямая компиляция на целевой платформе может оказаться невозможной, например, во встроенных системах с ограниченными вычислительными ресурсами.
Кросс-компиляторы отличаются от компиляторов исходного кода . Кросс-компилятор предназначен для кросс-платформенной генерации машинного кода, а компилятор из исходного кода переводит с одного языка кодирования на другой в текстовом коде. Оба являются инструментами программирования .
Основное использование кросс-компилятора — отделение среды сборки от целевой среды. Это полезно в нескольких ситуациях:
Использование виртуальных машин (таких как 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, как в этом примере, может быть задействовано четыре компилятора.
Кросс-компилятор конечного результата (4) не сможет работать на машине сборки A; вместо этого он запускался на машине B для компиляции приложения в исполняемый код, который затем копировался на машину C и выполнялся на машине C.
Например, NetBSD предоставляет сценарий оболочки POSIX Unixbuild.sh , который сначала создаст свою собственную цепочку инструментов с помощью компилятора хоста; это, в свою очередь, будет использовано для создания кросс-компилятора, который будет использоваться для сборки всей системы.
Термин «Канадский крест» возник потому, что на момент обсуждения этих вопросов в Канаде действовало три национальные политические партии. [1]
GCC , набор бесплатных компиляторов, можно настроить для кросс-компиляции. Он поддерживает множество платформ и языков.
GCC требует, чтобы скомпилированная копия binutils была доступна для каждой целевой платформы. Особенно важен GNU Assembler . Поэтому сначала нужно правильно скомпилировать binutils с переключателем, --target=some-targetотправленным в скрипт configure . GCC также необходимо настроить с той же --targetопцией. Затем GCC можно запустить в обычном режиме при условии, что инструменты, создаваемые binutils , доступны по пути , что можно сделать, используя следующее (в UNIX-подобных операционных системах с bash):
PATH=/путь/к/binutils/bin:${PATH} makeКросс-компиляция GCC требует, чтобы часть стандартной библиотеки C целевой платформы была доступна на хост-платформе . Программист может выбрать полную компиляцию библиотеки C, но этот выбор может оказаться ненадежным. Альтернативой является использование newlib — небольшой библиотеки C , содержащей только самые необходимые компоненты, необходимые для компиляции исходного кода C.
Пакеты GNU Autotools (т.е. autoconf , automake и libtool ) используют понятие платформы сборки , хост-платформы и целевой платформы . Платформа сборки — это место, где фактически компилируется компилятор. В большинстве случаев сборку следует оставить неопределенной (по умолчанию она будет установлена на хосте). Хост -платформа всегда является местом, где выходные артефакты компилятора будут выполняться независимо от того, является ли вывод другим компилятором или нет. Целевая платформа используется при кросс-компиляции кросс-компиляторов и определяет, какой тип объектного кода будет создавать пакет; в противном случае настройка целевой платформы не имеет значения. [2] Например, рассмотрим кросс-компиляцию видеоигры, которая будет работать на Dreamcast . Машина, на которой компилируется игра, является платформой сборки , а Dreamcast — хост-платформой . Имена хост и цель относятся к используемому компилятору и смещаются как сын и внук . [3]
Другой метод, широко используемый разработчиками встраиваемых систем Linux, включает комбинацию компиляторов GCC со специализированными песочницами, такими как Scratchbox, Scratchbox2 или PROot. Эти инструменты создают изолированную программную среду с chroot-окружением, в которой программист может создавать необходимые инструменты, библиотеки libc и библиотеки без необходимости устанавливать дополнительные пути. Также предусмотрены средства для «обмана» среды выполнения, чтобы она «полагала», что действительно работает на предполагаемом целевом ЦП (например, в архитектуре ARM); это позволяет сценариям настройки и т.п. запускаться без ошибок. Scratchbox работает медленнее по сравнению с «некорневыми» методами, и для работы большинство инструментов, находящихся на хосте, необходимо переместить в Scratchbox.
Компания Manx Software Systems из Шрусбери , штат Нью-Джерси , начиная с 1980-х годов выпускала компиляторы C , ориентированные на профессиональных разработчиков для различных платформ, включая ПК и Mac .
Язык программирования Aztec C компании Manx был доступен для различных платформ, включая MS-DOS , Apple II , DOS 3.3 и ProDOS , Commodore 64 , Mac 68k [4] и Amiga .
С 1980-х и до 1990-х годов, пока не исчезли Manx Software Systems, версия Aztec C для MS-DOS [5] предлагалась как в качестве компилятора в собственном режиме, так и в качестве кросс-компилятора для других платформ с другими процессорами, включая Commodore 64 [6]. ] и Apple II. [7] В Интернете все еще существуют дистрибутивы 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 [8] , которые были менее надежными, чем «базовая» MS-DOS. версия 3 и более поздние, на которые Aztec C86 ориентировался до своей кончины.
Наконец, Aztec C86 предоставил разработчикам языка C возможность создавать «HEX» -код, пригодный для ПЗУ, который затем можно было передать с помощью устройства записи ПЗУ непосредственно в процессор на базе 8086. Паравиртуализация может быть более распространена сегодня, но практика создания низкоуровневого ПЗУ-кода была более распространена на душу населения в те годы, когда разработка драйверов устройств часто выполнялась программистами приложений для отдельных приложений, а новые устройства были кустарным производством . Программисты приложений нередко взаимодействовали напрямую с оборудованием без поддержки производителя. Эта практика была похожа на сегодняшнюю разработку встраиваемых систем .
Томас Фенвик и Джеймс Гудноу II были двумя основными разработчиками Aztec-C. Позже Фенвик стал известен как автор ядра Microsoft Windows CE или NK («Новое ядро»), как его тогда называли. [9]
Microsoft C (MSC) имеет более короткую историю, чем другие [10] , начиная с 1980-х годов. Первые компиляторы Microsoft C были созданы той же компанией, которая создала Lattice C , и были переименованы Microsoft в их собственные, пока не был выпущен MSC 4, который стал первой версией, созданной Microsoft самостоятельно. [11]
В 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-го уровня.
Программы на языке C уже давно связаны с модулями, написанными на языке ассемблера . Большинство компиляторов C (даже современные компиляторы) предлагают проход на языке ассемблера (который можно настроить для повышения эффективности, а затем связать с остальной частью программы после сборки).
Компиляторы, такие как Aztec-C, преобразовывали все на язык ассемблера в отдельный проход, а затем собирали код в отдельный проход и были известны своим очень эффективным и небольшим кодом, но к 1987 году оптимизатор, встроенный в Microsoft C, был очень хорош, и только «Критически важные» части программы обычно рассматривались для переписывания. Фактически, программирование на языке C стало языком «самого низкого уровня», при этом программирование стало мультидисциплинарной развивающейся отраслью, а проекты стали крупнее, программисты писали пользовательские интерфейсы и интерфейсы баз данных на языках более высокого уровня, и возникла необходимость возникли для межъязыкового развития, которое продолжается и по сей день.
К 1987 году, с выпуском MSC 5.1, Microsoft предложила межъязыковую среду разработки для MS-DOS. 16-битный двоичный объектный код, написанный на языке ассемблера ( MASM ) и других языках Microsoft, включая QuickBASIC , Pascal и Fortran , можно было связать вместе в одну программу в процессе, который они назвали «Программирование на смешанных языках», а теперь и «Межъязыковой вызов». [12] Если в этом сочетании использовался BASIC , основная программа должна была быть на BASIC для поддержки внутренней системы выполнения , которая компилировала BASIC, необходимый для сборки мусора, и других управляемых операций, которые имитировали интерпретатор BASIC , такой как QBasic, в MS-DOS.
В частности, соглашение о вызовах для кода C заключалось в передаче параметров в «обратном порядке» в стеке и возврате значений в стеке, а не в регистре процессора . Существовали и другие правила программирования, обеспечивающие совместную работу всех языков, но это конкретное правило сохранялось в ходе межъязыковой разработки, которая продолжалась в 16- и 32-разрядных версиях Windows , а также при разработке программ для OS/2 и сохраняется до сих пор. день. Это известно как соглашение о вызовах Паскаля .
Другой тип кросс-компиляции, для которого в то время использовался Microsoft C, был в розничных приложениях, требующих портативных устройств , таких как Symbol Technologies PDT3100 (используемый для инвентаризации ) , который предоставлял библиотеку ссылок, ориентированную на считыватель штрих-кодов на базе 8088 . Приложение создавалось на главном компьютере, а затем передавалось на портативное устройство (по последовательному кабелю ), где оно запускалось, подобно тому, что сегодня делается для того же рынка с использованием Windows Mobile такими компаниями, как Motorola , купившими символ.
На протяжении 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 сегодня.
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 .
В 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) и всех других ОС (см. [13] ). Однако для компиляции в другую архитектуру сначала необходимо собрать кросс-архитектурную версию компилятора. В названии полученного исполняемого файла компилятора перед целевой архитектурой будет добавлено дополнительное слово «ross». т.е. если компилятор создан для x64, то исполняемым файлом будет ppcrossx64.
Для компиляции под выбранную архитектуру ОС можно использовать ключи компилятора (для драйвера компилятора fpc) -P и -T. Это также делается при кросс-компиляции самого компилятора, но устанавливается через опции make CPU_TARGET и OS_TARGET. Ассемблер и компоновщик GNU для целевой платформы требуются, если Free Pascal еще не имеет внутренней версии инструментов для целевой платформы.
Clang изначально является кросс-компилятором, и во время сборки вы можете выбрать, на какие архитектуры вы хотите, чтобы Clang мог ориентироваться.
Это называется «Канадский крест», потому что в то время, когда требовалось название, в Канаде действовало три национальные партии.
я386