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

редактировать

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

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

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

Содержание

  • 1 Использование
  • 2 Canadian Cross
  • 3 Временная шкала ранних кросс-компиляторов
  • 4 GCC и кросс-компиляция
  • 5 Кросс-компиляторы Manx Aztec C
  • 6 кросс-компиляторы Microsoft C
    • 6.1 Ранняя история - 1980-е
    • 6.2 1987
    • 6.3 Начало 1990-х
    • 6.4 Конец 1990-х
    • 6.5.NET и более поздние версии
  • 7 Free Pascal
  • 8 Clang
  • 9 См. Также
  • 10 Ссылки
  • 11 Внешние ссылки

Использование

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

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

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

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

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

, из Шрусбери, Нью-Джерси, производили компиляторы C, начиная с 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, их собственный режим 8086 компилятор MS-DOS, также был кросс-компилятором. Хотя он не компилировал код для другого процессора, такого как их кросс-компиляторы 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 возможность создавать ROM -able «HEX» код, который затем можно было передать с помощью записывающего устройства ROM. напрямую к процессору на базе 8086. Паравиртуализация может быть более распространенной сегодня, но практика создания низкоуровневого кода ROM была более распространена на душу населения в те годы, когда разработка драйвера устройства часто выполнялась прикладными программистами для отдельных приложений, а новые устройства составили кустарный промысел. Для прикладных программистов было обычным делом напрямую взаимодействовать с оборудованием без поддержки со стороны производителя. Эта практика была похожа на Разработка встроенных систем сегодня.

Томас Фенвик и Джеймс Гуднау II были двумя основными разработчиками Aztec-C. Позже Фенвик стал известен как автор Microsoft Windows CE kernel или 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: Керниган и Ритч, которые написали его в унисон, работая на ATT (лаборатория). Первоначальные потребности KR заключались не только в элегантном синтаксисе синтаксического анализа 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, в частности, заключалось в передаче параметров в «обратном порядке» в стеке и возвращении значений в стеке, а не в регистр процессора. Существовали и другие правила программирования, которые заставляли все языки работать вместе, но это конкретное правило сохранялось в процессе кросс-языковой разработки, которая продолжалась в Windows 16- и 32-битных версиях, а также при разработке программ для OS / 2, которая сохраняется и по сей день. Он известен как соглашение о вызовах Pascal.

Другой тип кросс-компиляции, для которого в это время использовался Microsoft C, был в розничных приложениях, требующих портативных устройств, таких как Symbol Technologies 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. Была введена практика программирования под названием преобразователь, позволяющая передавать между 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 был выпущен с, а MSC 14 был выпущен с Visual Studio 2005, оба из которых по-прежнему создают код для старых систем, таких как Windows 95, но которые будут создавать код для нескольких целевых платформ. включая рынок мобильных устройств и архитектуру ARM.

.NET и не только

В 2001 году Microsoft разработала Common Language Runtime (CLR), которая стала ядром для их Компилятор.NET Framework в среде разработки Visual Studio. Этот уровень в операционной системе, который находится в 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) и всех других ОС (см.). Однако для компиляции в другую архитектуру сначала должна быть создана кросс-архитектурная версия компилятора. В имени полученного исполняемого файла компилятора перед целевой архитектурой будет добавлено слово ross. то есть если компилятор создан для целевой архитектуры x64, то исполняемый файл будет ppcrossx64.

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

.

Clang

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

См. Также

Ссылки

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

Последняя правка сделана 2021-05-16 09:43:32
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте