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

Выполнение программы
Общие понятия
Типы кода
Стратегии компиляции
Заметное время выполнения
Известные компиляторы и инструментальные средства

А кросс-компилятор это компилятор способен создавать исполняемый файл код для Платформа кроме того, на котором работает компилятор. Например, компилятор, работающий на Windows 7 ПК но генерирует код, который работает на Android смартфон это кросс-компилятор.

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

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

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

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

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

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

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

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

В Канадский крест это метод построения кросс-компиляторов для других машин. Учитывая три машины A, B и C, одна использует машину A (например, работает Windows XP на IA-32 процессор) для создания кросс-компилятора, который работает на машине B (например, работает Mac OS X на x86-64 процессор) для создания исполняемых файлов для машины C (например, запуск Android на РУКА процессор). При использовании канадского креста с 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 который сначала построит свой набор инструментов с компилятором хоста; это, в свою очередь, будет использоваться для построения кросс-компилятора, который будет использоваться для построения всей системы.

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

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

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

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

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

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

ПУТЬ = / путь / к / binutils / bin: $ {PATH} make

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

В Автоинструменты GNU пакеты (т.е. autoconf, автопроизводитель, и libtool ) используют понятие построить платформу, а хост-платформа, а целевая платформа. В построить платформу это место, где фактически компилируется компилятор. В большинстве случаев сборку следует оставить неопределенной (она будет по умолчанию с хоста). В хост-платформа всегда будут выполняться артефакты вывода от компилятора, независимо от того, является ли вывод другим компилятором или нет. В целевая платформа используется при кросс-компиляции кросс-компиляторов, он представляет, какой тип объектного кода будет создавать сам пакет; в противном случае целевая платформа настройка не имеет значения.[2] Например, рассмотрите возможность кросс-компиляции видеоигры, которая будет работать на Dreamcast. Машина, на которой скомпилирована игра, является построить платформу а Dreamcast - это хост-платформа. Имена хозяин и цель относятся к используемому компилятору и сдвигаются как сын и внук.[3]

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

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

Системы программного обеспечения острова Мэн, из Шрусбери, Нью-Джерси, произведено Компиляторы C начиная с 1980-х годов ориентирована на профессиональных разработчиков для различных платформ, включая ПК и Mac.

Манкс Ацтек C язык программирования был доступен для множества платформ, включая MS-DOS, Яблоко II, DOS 3.3 и ProDOS, Коммодор 64, Macintosh 68XXX[4] и Amiga.

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

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

Когда IBM PC был впервые представлен, он был доступен с выбором операционных систем, CP / M-86 и ПК 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 возможность создавать ROM-способный "HEX" код, который затем может быть передан с помощью ПЗУ напрямую к процессору на базе 8086. Паравиртуализация может быть более распространенным сегодня, но практика создания низкоуровневого кода ROM была более распространена на душу населения в те годы, когда драйвер устройства разработка часто велась прикладными программистами для отдельных приложений, и новые устройства составляли надомная промышленность. Для прикладных программистов было обычным делом напрямую взаимодействовать с оборудованием без поддержки со стороны производителя. Эта практика была похожа на Разработка встроенных систем сегодня.

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

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

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

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

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

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

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

1987

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

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

К 1987 году, с выпуском MSC 5.1, Microsoft предложила кросс-языковую среду разработки для MS-DOS. 16-битный двоичный объектный код, написанный на языке ассемблера (MASM ) и другие языки Microsoft, включая QuickBASIC, Паскаль, и Фортран могут быть связаны вместе в одну программу, в процессе, который они назвали «Программирование на разных языках», а теперь «Межъязыковой вызов».[12] Если БАЗОВЫЙ использовалась в этом миксе, основная программа должна была быть на BASIC для поддержки внутреннего система времени выполнения который скомпилировал BASIC, необходимый для сборки мусора и других управляемых операций, имитирующих BASIC устный переводчик подобно QBasic в MS-DOS.

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

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

Начало 1990-х

На протяжении 1990-х и начиная с MSC 6 (их первый ANSI C совместимый компилятор) Microsoft переориентировала свои компиляторы C на развивающийся рынок Windows, а также на OS / 2 и в развитии GUI программы. Смешанная языковая совместимость сохранялась через 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 взял на себя Ацтек 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 разработала общеязыковая среда выполнения (CLR), которые легли в основу их .NET Framework компилятор в интегрированной среде разработки Visual Studio. Этот уровень операционной системы, который находится в API позволяет смешивать языки разработки, скомпилированные для разных платформ, работающих под управлением операционной системы Windows.

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

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

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

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

Free Pascal

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 мог ориентироваться.

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

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

  1. ^ «4.9 Канадские кресты». CrossGCC. Архивировано из оригинал 9 октября 2004 г.. Получено 2012-08-08. Это называется «канадский крест», потому что в то время, когда требовалось название, в Канаде было три национальных партии.
  2. ^ https://www.gnu.org/s/libtool/manual/automake/Cross_002dCompilation.html
  3. ^ https://mesonbuild.com/Cross-compilation.html
  4. ^ «Устаревшие компьютеры Macintosh». Архивировано из оригинал на 2008-02-26. Получено 2008-03-10.
  5. ^ Ацтек C
  6. ^ Коммодор 64
  7. ^ Яблоко II
  8. ^ Хронология MS-DOS В архиве 2008-05-01 на Wayback Machine
  9. ^ Внутри Windows CE (ищите Фенвик)
  10. ^ История версий Microsoft Language Utility
  11. ^ История C-компиляторов на базе ПК В архиве 15 декабря 2007 г. Wayback Machine
  12. ^ Какие базовые версии могут ВЫЗЫВАТЬ C, FORTRAN, Pascal, MASM
  13. ^ «Список поддерживаемых платформ Free Pascal». Список платформ. Получено 2010-06-17. i386

внешняя ссылка