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

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

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

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

Используйте [ редактировать ]

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

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

• Собственный собственный компилятор для машины A (1) (например, компилятор из Microsoft Visual Studio ) используется для создания собственного компилятора gcc для машины A (2) .
• Собственный компилятор gcc для машины A (2) используется для сборки кросс-компилятора gcc с машины A на машину B (3)
• GCC кросс - компилятор из машины А , чтобы машина B (3) используется для построения GCC кросс - компилятор от машины В к машине 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 Assembler . Следовательно, сначала необходимо правильно скомпилировать binutils с переключателем, --target=some-targetотправленным сценарию настройки . GCC также должен быть настроен с такой же --targetопцией. Затем GCC можно запустить в обычном режиме при условии, что инструменты, которые создает binutils , доступны по пути , что можно сделать, используя следующее (в UNIX-подобных операционных системах с bash):

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

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

В GNU Autotools пакеты (т.е. Autoconf , Automake и LIBTOOL ) используют понятие сборки платформы , на хост - платформы , и целевую платформу . Платформа сборки - это место, где фактически компилируется компилятор. В большинстве случаев сборку следует оставить неопределенной (она будет по умолчанию с хоста). На платформе хоста всегда будут выполняться артефакты вывода от компилятора, независимо от того, является ли вывод другим компилятором или нет. Целевой платформы используется при кросс-компиляции кросс - компиляторов, он представляет , какой тип кода объекта один пакет сам будет производить; в противном случаенастройка целевой платформы не имеет значения. ^[2] Например, рассмотрите возможность кросс-компиляции видеоигры, которая будет работать на Dreamcast . Машина, на которой скомпилирована игра, является платформой сборки, а Dreamcast - платформой хоста . Имена host и target относятся к используемому компилятору и сдвигаются, как son и grand-son . ^[3]

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

Кросс-компиляторы языка Manx Aztec C [ править ]

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

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

С 1980-х годов и в течение 1990-х годов до исчезновения Manx Software Systems версия Aztec C ^{[5] для} MS-DOS предлагалась как в качестве компилятора в собственном режиме, так и в качестве кросс-компилятора для других платформ с другими процессорами, включая 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. Паравиртуализация может быть более распространенной сегодня, но практика создания низкоуровневого кода ROM была более распространена на душу населения в те годы, когда разработка драйверов устройств часто выполнялась прикладными программистами для отдельных приложений, а новые устройства составляли отдельную отрасль . Для прикладных программистов было обычным делом напрямую взаимодействовать с оборудованием без поддержки со стороны производителя. Эта практика была похожа на сегодняшнюю разработку встраиваемых систем .

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

Кросс-компиляторы Microsoft C [ править ]

Ранняя история - 1980-е [ править ]

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-го уровня.

1987 [ править ]

Программы на 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 , купившая Symbol.

Начало 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 . Практика программирования, называемая преобразователембыл введен, чтобы разрешить передачу между 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 [ править ]

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 изначально является кросс-компилятором, во время сборки вы можете выбрать, на какие архитектуры вы хотите, чтобы Clang мог ориентироваться.

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

• MinGW
• Scratchbox
• Свободный Паскаль
• Кросс-ассемблер

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

Внешние ссылки [ править ]

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