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

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

Кросс - компилятор является компилятор может создавать исполняемый код для платформы , отличной от той , на которой компилятор работает. Например, компилятор, работающий на ПК, но генерирующий код, работающий на смартфоне 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который сначала создаст свою собственную цепочку инструментов с компилятором хоста; это, в свою очередь, будет использоваться для построения кросс-компилятора, который будет использоваться для построения всей системы.

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

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

  • 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): 

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

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

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

Другой метод, широко используемый разработчиками встраиваемого 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 и Amiga .

С 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. Паравиртуализация может быть более распространенной сегодня, но практика создания низкоуровневого кода ROM была более распространена на душу населения в те годы, когда разработка драйверов устройств часто выполнялась прикладными программистами для отдельных приложений, а новые устройства составляли отдельную отрасль . Для прикладных программистов было обычным делом напрямую взаимодействовать с оборудованием без поддержки со стороны производителя. Эта практика была похожа на сегодняшнюю разработку встраиваемых систем .

Томас Фенвик и Джеймс Гуднау 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 , купившая 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 с самого начала разрабатывался как кросс-компилятор. Исполняемый файл компилятора (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 мог ориентироваться.

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

использованная литература

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