stringtranslate.com

Компилятор

В вычислительной технике компилятор — это компьютерная программа , которая переводит компьютерный код, написанный на одном языке программирования ( исходный язык), на другой язык ( целевой язык). Название «компилятор» в основном используется для программ, которые переводят исходный код с языка программирования высокого уровня на язык программирования низкого уровня (например, язык ассемблера , объектный код или машинный код ) для создания исполняемой программы. [1] [2] : p1  [3]

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

Сопутствующее программное обеспечение включает декомпиляторы — программы, которые переводят с языков низкого уровня на языки более высокого уровня; программы, которые переводят между языками высокого уровня, обычно называемые компиляторами исходного кода или транспиляторами ; рерайтеры языков — обычно программы, которые переводят форму выражений без изменения языка; и компиляторы-компиляторы — компиляторы, которые производят компиляторы (или их части), часто универсальным и повторно используемым способом, чтобы иметь возможность производить множество различных компиляторов.

Компилятор, скорее всего, выполнит некоторые или все из следующих операций, часто называемых фазами: предварительная обработка , лексический анализ , синтаксический анализ , семантический анализ ( синтаксически-управляемый перевод ), преобразование входных программ в промежуточное представление , оптимизация кода и машинно-специфическая генерация кода . Компиляторы обычно реализуют эти фазы как модульные компоненты, способствуя эффективному проектированию и корректности преобразований исходного ввода в целевой вывод. Ошибки программы, вызванные неправильным поведением компилятора, может быть очень трудно отследить и обойти; поэтому разработчики компиляторов вкладывают значительные усилия, чтобы обеспечить корректность компилятора . [4]

Компиляторы — не единственный языковой процессор, используемый для преобразования исходных программ. Интерпретатор — это компьютерное программное обеспечение, которое преобразует и затем выполняет указанные операции. [2] : p2  Процесс трансляции влияет на разработку компьютерных языков, что приводит к предпочтению компиляции или интерпретации. Теоретически язык программирования может иметь как компилятор, так и интерпретатор. На практике языки программирования, как правило, связаны только с одним (компилятором или интерпретатором).

История

Схема работы типичного многоязыкового многоцелевого компилятора

Теоретические вычислительные концепции, разработанные учеными, математиками и инженерами, легли в основу развития современных цифровых вычислений во время Второй мировой войны. Примитивные двоичные языки развивались, поскольку цифровые устройства понимают только единицы и нули и схемы схем в базовой архитектуре машины. В конце 1940-х годов были созданы языки ассемблера, чтобы предложить более работоспособную абстракцию компьютерных архитектур. [5] Ограниченный объем памяти ранних компьютеров привел к существенным техническим проблемам при проектировании первых компиляторов. Поэтому процесс компиляции необходимо было разделить на несколько небольших программ. Программы front-end производят продукты анализа, используемые программами back-end для генерации целевого кода. Поскольку компьютерные технологии предоставляли больше ресурсов, конструкции компиляторов могли лучше соответствовать процессу компиляции.

Обычно программисту более продуктивно использовать язык высокого уровня, поэтому разработка языков высокого уровня естественным образом вытекала из возможностей, предлагаемых цифровыми компьютерами. Языки высокого уровня — это формальные языки , которые строго определены их синтаксисом и семантикой , которые формируют архитектуру языка высокого уровня. Элементы этих формальных языков включают:

Предложения в языке могут быть определены набором правил, называемых грамматикой. [6]

Форма Бэкуса–Наура (БНФ) описывает синтаксис «предложений» языка. Она была разработана Джоном Бэкусом и использовалась для синтаксиса Algol 60. [7] Идеи вытекают из концепций контекстно-свободной грамматики лингвиста Ноама Хомского . [8] «БНФ и ее расширения стали стандартными инструментами для описания синтаксиса программных нотаций. Во многих случаях части компиляторов генерируются автоматически из описания БНФ». [9]

Между 1942 и 1945 годами Конрад Цузе разработал первый (алгоритмический) язык программирования для компьютеров под названием Plankalkül («Плановое исчисление»). Цузе также задумал Planfertigungsgerät («Устройство сборки планов») для автоматического перевода математической формулировки программы в машиночитаемую перфорированную кинопленку . [10] Хотя фактическая реализация не произошла до 1970-х годов, она представила концепции, позже увиденные в APL, разработанном Кеном Айверсоном в конце 1950-х годов. [11] APL — это язык для математических вычислений.

Между 1949 и 1951 годами Хайнц Рутисхаузер предложил Суперплан — язык высокого уровня и автоматический переводчик. [12] Его идеи позднее были усовершенствованы Фридрихом Л. Бауэром и Клаусом Самельсоном . [13]

Разработка языков высокого уровня в годы становления цифровой вычислительной техники предоставила полезные инструменты программирования для различных приложений:

Технология компиляторов развилась из потребности в строго определенном преобразовании исходной программы высокого уровня в целевую программу низкого уровня для цифрового компьютера. Компилятор можно рассматривать как front end для анализа исходного кода и back end для синтеза анализа в целевой код. Оптимизация между front end и back end может производить более эффективный целевой код. [17]

Некоторые ранние вехи в развитии технологии компиляторов:

Ранние операционные системы и программное обеспечение были написаны на языке ассемблера. В 1960-х и начале 1970-х годов использование языков высокого уровня для системного программирования все еще было спорным из-за ограниченности ресурсов. Однако несколько исследовательских и промышленных усилий начали сдвиг в сторону языков системного программирования высокого уровня, например , BCPL , BLISS , B и C.

BCPL (Basic Combined Programming Language), разработанный в 1966 году Мартином Ричардсом в Кембриджском университете, изначально разрабатывался как инструмент для написания компиляторов. [29] Было реализовано несколько компиляторов, книга Ричардса дает представление о языке и его компиляторе. [30] BCPL был не только влиятельным языком системного программирования, который до сих пор используется в исследованиях [31] , но и послужил основой для разработки языков B и C.

BLISS (Basic Language for Implementation of System Software) был разработан для компьютера PDP-10 корпорации Digital Equipment Corporation (DEC) исследовательской группой WA Wulf из Университета Карнеги-Меллона (CMU). Группа CMU продолжила разработку компилятора BLISS-11 годом позже, в 1970 году.

Multics (Multiplexed Information and Computing Service), проект операционной системы с разделением времени, в котором участвовали MIT , Bell Labs , General Electric (позже Honeywell ) и который возглавлял Фернандо Корбато из MIT. [32] Multics был написан на языке PL/I , разработанном IBM и IBM User Group. [33] Целью IBM было удовлетворение требований делового, научного и системного программирования. Существовали и другие языки, которые можно было бы рассмотреть, но PL/I предлагал наиболее полное решение, хотя оно и не было реализовано. [34] В течение первых нескольких лет проекта Multics подмножество языка можно было скомпилировать в язык ассемблера с помощью компилятора Early PL/I (EPL) Дуга Макилори и Боба Морриса из Bell Labs. [35] EPL поддерживала проект до тех пор, пока не был разработан компилятор для полной загрузки PL/I. [36]

Bell Labs вышла из проекта Multics в 1969 году и разработала системный язык программирования B на основе концепций BCPL, написанный Деннисом Ритчи и Кеном Томпсоном . Ритчи создал компилятор начальной загрузки для B и написал операционную систему Unics (Uniplexed Information and Computing Service) для PDP-7 на языке B. В конечном итоге Unics стал писаться как Unix.

Bell Labs начала разработку и расширение C на основе B и BCPL. Компилятор BCPL был перенесен в Multics компанией Bell Labs, и BCPL был предпочтительным языком в Bell Labs. [37] Первоначально использовалась программа front-end для компилятора B Bell Labs, пока разрабатывался компилятор C. В 1971 году новый PDP-11 предоставил ресурс для определения расширений для B и переписывания компилятора. К 1973 году разработка языка C была по существу завершена, и ядро ​​Unix для PDP-11 было переписано на C. Стив Джонсон начал разработку Portable C Compiler (PCC) для поддержки перенацеливания компиляторов C на новые машины. [38] [39]

Объектно-ориентированное программирование (ООП) предлагало некоторые интересные возможности для разработки и обслуживания приложений. Концепции ООП появились еще раньше, но были частью науки о языках LISP и Simula . [40] Bell Labs заинтересовалась ООП с разработкой C++ . [41] C++ впервые был использован в 1980 году для системного программирования. Первоначальный проект использовал возможности системного программирования языка C с концепциями Simula. Объектно-ориентированные возможности были добавлены в 1983 году. [42] Программа Cfront реализовала интерфейс C++ для компилятора языка C84. В последующие годы было разработано несколько компиляторов C++ по мере роста популярности C++.

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

DARPA (Управление перспективных исследовательских проектов в области обороны) спонсировало проект компилятора с исследовательской группой Вульфа из CMU в 1970 году. Проект компилятора качества производства PQCC должен был создать компилятор качества производства (PQC) из формальных определений исходного языка и целевого языка. [43] PQCC попытались расширить термин компилятор-компилятор за пределы традиционного значения как генератора синтаксических анализаторов (например, Yacc ), но без особого успеха. PQCC было бы правильнее называть генератором компилятора.

Исследование PQCC в области процесса генерации кода стремилось построить действительно автоматическую систему написания компилятора. В ходе работы была обнаружена и разработана фазовая структура PQC. Компилятор BLISS-11 предоставил начальную структуру. [44] Фазы включали анализ (фронт-энд), промежуточную трансляцию в виртуальную машину (средний конец) и трансляцию в целевой объект (бэк-энд). TCOL был разработан для исследования PQCC для обработки языковых конструкций в промежуточном представлении. [45] Вариации TCOL поддерживали различные языки. Проект PQCC исследовал методы автоматизированного построения компилятора. Концепции проектирования оказались полезными при оптимизации компиляторов и компиляторов для (с 1995 года объектно-ориентированного) языка программирования Ada .

Документ Ada STONEMAN [a] формализовал среду поддержки программ (APSE) вместе с ядром (KAPSE) и минимальным (MAPSE). Интерпретатор Ada NYU/ED поддерживал усилия по разработке и стандартизации совместно с Американским национальным институтом стандартов (ANSI) и Международной организацией по стандартизации (ISO). Первоначальная разработка компилятора Ada военными службами США включала компиляторы в полную интегрированную среду проектирования в соответствии с документом STONEMAN . Армия и флот работали над проектом Ada Language System (ALS), нацеленным на архитектуру DEC/VAX, в то время как ВВС начали работу над Ada Integrated Environment (AIE), нацеленным на серию IBM 370. Хотя проекты не дали желаемых результатов, они внесли вклад в общие усилия по разработке Ada. [46]

Другие усилия по компилятору Ada были предприняты в Великобритании в Университете Йорка и в Германии в Университете Карлсруэ. В США Verdix (позже приобретенная Rational) поставляла Verdix Ada Development System (VADS) для армии. VADS предоставляла набор инструментов разработки, включая компилятор. Unix/VADS могла размещаться на различных платформах Unix, таких как DEC Ultrix и Sun 3/60 Solaris, ориентированная на Motorola 68020 в оценке CECOM армии. [47] Вскоре появилось много доступных компиляторов Ada, которые прошли тесты Ada Validation. Проект Free Software Foundation GNU разработал GNU Compiler Collection (GCC), которая обеспечивает базовую возможность поддержки нескольких языков и целевых платформ. Версия Ada GNAT является одним из наиболее широко используемых компиляторов Ada. GNAT бесплатна, но есть и коммерческая поддержка, например, AdaCore, была основана в 1994 году для предоставления коммерческих программных решений для Ada. GNAT Pro включает в себя GNAT на базе GNU GCC с набором инструментов для предоставления интегрированной среды разработки .

Высокоуровневые языки продолжали стимулировать исследования и разработки компиляторов. Основные направления включали оптимизацию и автоматическую генерацию кода. Тенденции в языках программирования и средах разработки повлияли на технологию компиляторов. Все больше компиляторов стали включаться в дистрибутивы языков (PERL, Java Development Kit) и как компонент IDE (VADS, Eclipse, Ada Pro). Взаимосвязь и взаимозависимость технологий росли. Появление веб-сервисов способствовало росту веб-языков и языков сценариев. Скрипты восходят к ранним дням интерфейсов командной строки (CLI), где пользователь мог вводить команды, которые должны были выполняться системой. Концепции оболочки пользователя разрабатывались с помощью языков для написания программ оболочки. Ранние проекты Windows предлагали простую возможность пакетного программирования. Традиционное преобразование этих языков использовало интерпретатор. Хотя компиляторы Bash и Batch не получили широкого распространения, были написаны. Совсем недавно сложные интерпретируемые языки стали частью набора инструментов разработчиков. Современные языки сценариев включают PHP, Python, Ruby и Lua. (Lua широко используется в разработке игр.) Все они имеют поддержку интерпретатора и компилятора. [48]

«Когда в конце 50-х годов началась область компиляции, ее фокус был ограничен переводом программ на языке высокого уровня в машинный код... Область компиляции все больше переплетается с другими дисциплинами, включая архитектуру компьютеров, языки программирования, формальные методы, программную инженерию и компьютерную безопасность». [49] В статье «Исследования компиляторов: следующие 50 лет» отмечалась важность объектно-ориентированных языков и Java. Безопасность и параллельные вычисления были названы среди будущих целей исследований.

Конструкция компилятора

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

В ранние дни подход, принятый к проектированию компилятора, напрямую зависел от сложности обрабатываемого компьютерного языка, опыта человека(ов), проектирующего его, и доступных ресурсов. Ограничения ресурсов привели к необходимости проходить исходный код более одного раза.

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

Однопроходный компилятор по сравнению с многопроходным компилятором

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

Возможность компиляции за один проход традиционно рассматривалась как преимущество, поскольку она упрощает работу по написанию компилятора, а однопроходные компиляторы обычно выполняют компиляцию быстрее, чем многопроходные . Таким образом, отчасти из-за ограничений ресурсов ранних систем, многие ранние языки были специально разработаны так, чтобы их можно было компилировать за один проход (например, Pascal ).

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

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

Разделение компилятора на небольшие программы — это метод, используемый исследователями, заинтересованными в создании доказуемо корректных компиляторов. Доказательство корректности набора небольших программ часто требует меньших усилий, чем доказательство корректности более крупной, одиночной, эквивалентной программы.

Трехступенчатая структура компилятора

Проектирование компилятора

Независимо от точного количества фаз в конструкции компилятора, фазы могут быть отнесены к одному из трех этапов. Этапы включают в себя front end, middle end и back end.

Такой подход front-middle-back-end позволяет объединять front-end для разных языков с back-end для разных процессоров , при этом разделяя оптимизации middle-end. [50] Практическими примерами такого подхода являются GNU Compiler Collection , Clang ( компилятор C/C++ на основе LLVM ) [51] и Amsterdam Compiler Kit , которые имеют несколько front-end, общие оптимизации и несколько back-end.

Внешний интерфейс

Пример лексера и парсера для C . Начиная с последовательности символов " if(net>0.0)total+=net*(1.0+tax/100.0);", сканер составляет последовательность токенов и классифицирует каждый из них, например, как идентификатор , зарезервированное слово , числовой литерал или оператор . Последняя последовательность преобразуется парсером в синтаксическое дерево , которое затем обрабатывается оставшимися фазами компиляции. Сканер и парсер обрабатывают обычные и собственно контекстно-свободные части грамматики для C , соответственно.

Фронтенд анализирует исходный код для построения внутреннего представления программы, называемого промежуточным представлением (IR). Он также управляет таблицей символов , структурой данных, сопоставляющей каждый символ в исходном коде с соответствующей информацией, такой как местоположение, тип и область действия.

Хотя фронтенд может быть единой монолитной функцией или программой, как в парсере без сканера , он традиционно реализовывался и анализировался как несколько фаз, которые могут выполняться последовательно или одновременно. Этот метод пользуется популярностью из-за его модульности и разделения задач . Чаще всего фронтенд разбивается на три фазы: лексический анализ (также известный как лексирование или сканирование), синтаксический анализ (также известный как сканирование или разбор) и семантический анализ . Лексинг и разбор включают синтаксический анализ (синтаксис слова и синтаксис фразы соответственно), и в простых случаях эти модули (лексер и парсер) могут быть автоматически сгенерированы из грамматики языка, хотя в более сложных случаях они требуют ручной модификации. Лексическая грамматика и грамматика фразы обычно являются контекстно-свободными грамматиками , что значительно упрощает анализ, при этом контекстно-зависимость обрабатывается на этапе семантического анализа. Фаза семантического анализа, как правило, более сложная и пишется вручную, но может быть частично или полностью автоматизирована с использованием атрибутных грамматик . Эти фазы сами по себе могут быть далее разбиты: лексический анализ как сканирование и оценка, и парсинг как построение конкретного синтаксического дерева (CST, parse tree) и последующее преобразование его в абстрактное синтаксическое дерево (AST, syntax tree). В некоторых случаях используются дополнительные фазы, в частности, реконструкция строк и предварительная обработка, но они редки.

Основные этапы фронтенда включают в себя следующее:

Средний конец

Средний конец, также известный как оптимизатор, выполняет оптимизацию промежуточного представления с целью повышения производительности и качества создаваемого машинного кода. [55] Средний конец содержит те оптимизации, которые не зависят от целевой архитектуры ЦП.

Основные фазы среднего этапа включают в себя следующее:

Анализ компилятора является предпосылкой для любой оптимизации компилятора, и они тесно работают вместе. Например, анализ зависимости имеет решающее значение для преобразования цикла .

Область анализа и оптимизации компилятора сильно различается; их область действия может варьироваться от работы в пределах базового блока до целых процедур или даже всей программы. Существует компромисс между степенью детализации оптимизаций и стоимостью компиляции. Например, оптимизация peephole выполняется быстро во время компиляции, но затрагивает только небольшой локальный фрагмент кода и может выполняться независимо от контекста, в котором появляется фрагмент кода. Напротив, межпроцедурная оптимизация требует больше времени компиляции и памяти, но позволяет проводить оптимизации, которые возможны только при одновременном рассмотрении поведения нескольких функций.

Межпроцедурный анализ и оптимизация распространены в современных коммерческих компиляторах от HP , IBM , SGI , Intel , Microsoft и Sun Microsystems . Свободное программное обеспечение GCC долгое время критиковалось за отсутствие мощных межпроцедурных оптимизаций, но оно меняется в этом отношении. Еще один компилятор с открытым исходным кодом с полной инфраструктурой анализа и оптимизации — Open64 , который используется многими организациями в исследовательских и коммерческих целях.

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

Бэк-энд

Бэкэнд отвечает за оптимизацию архитектуры ЦП и генерацию кода [55] .

Основные этапы бэкэнда включают в себя следующее:

Корректность компилятора

Корректность компилятора — это раздел программной инженерии, который занимается попытками показать, что компилятор ведет себя в соответствии со спецификацией своего языка . [57] Методы включают разработку компилятора с использованием формальных методов и использование строгого тестирования (часто называемого проверкой компилятора) на существующем компиляторе.

Компилируется по отношению к интерпретируемым языкам

Языки программирования более высокого уровня обычно появляются с учетом типа трансляции : либо разработанные как компилируемый язык , либо интерпретируемый язык . Однако на практике редко бывает так, чтобы язык требовал исключительно компилируемого или исключительно интерпретируемого языка, хотя можно разрабатывать языки, которые полагаются на повторную интерпретацию во время выполнения. Категоризация обычно отражает наиболее популярные или распространенные реализации языка — например, BASIC иногда называют интерпретируемым языком, а C — компилируемым, несмотря на существование компиляторов BASIC и интерпретаторов C.

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

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

Некоторые спецификации языка указывают, что реализации должны включать средство компиляции; например, Common Lisp . Однако в определении Common Lisp нет ничего, что мешало бы его интерпретировать. В других языках есть функции, которые очень легко реализовать в интерпретаторе, но которые значительно усложняют написание компилятора; например, APL , SNOBOL4 и многие скриптовые языки позволяют программам создавать произвольный исходный код во время выполнения с помощью обычных строковых операций, а затем выполнять этот код, передавая его специальной функции оценки . Чтобы реализовать эти функции в компилируемом языке, программы обычно должны поставляться с библиотекой времени выполнения , которая включает версию самого компилятора.

Типы

Одна из классификаций компиляторов — по платформе, на которой выполняется сгенерированный ими код. Это называется целевой платформой.

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

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

Язык более низкого уровня, который является целью компилятора, сам может быть языком программирования высокого уровня . C, рассматриваемый некоторыми как своего рода переносимый язык ассемблера, часто является целевым языком таких компиляторов. Например, Cfront , оригинальный компилятор для C++ , использовал C в качестве своего целевого языка. Код C, сгенерированный таким компилятором, обычно не предназначен для чтения и поддержки людьми, поэтому стиль отступов и создание красивого промежуточного кода C игнорируются. Некоторые из особенностей C, которые делают его хорошим целевым языком, включают #lineдирективу, которая может быть сгенерирована компилятором для поддержки отладки исходного кода, и широкую поддержку платформ, доступную с компиляторами C.

Хотя распространенный тип компилятора выводит машинный код, существует множество других типов:

Assemblers, which translate human readable assembly language to the machine code instructions executed by hardware, are not considered compilers.[65][b] (The inverse program that translates machine code to assembly language is called a disassembler.)

See also

Notes and references

  1. ^ United States Department of Defense (18 February 1980) Stoneman requirements
  2. ^ "The many source-language features described in the preceding section result in a number of salient differences between compilers and assemblers. On any one item the distinction may not be clear-cut. Moreover, it may be difficult to distinguish a simple compiler from a powerful macro assembler. Nevertheless, the differences are usually substantial enough that there remains a qualitative distinction between assemblers and compilers."
  1. ^ "Encyclopedia: Definition of Compiler". PCMag.com. Retrieved 2 July 2022.
  2. ^ a b Compilers: Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman - Second Edition, 2007
  3. ^ Sudarsanam, Ashok; Malik, Sharad; Fujita, Masahiro (2002). "A Retargetable Compilation Methodology for Embedded Digital Signal Processors Using a Machine-Dependent Code Optimization Library". Readings in Hardware/Software Co-Design. Elsevier. pp. 506–515. doi:10.1016/b978-155860702-6/50045-4. ISBN 9781558607026. A compiler is a computer program that translates a program written in a high-level language (HLL), such as C, into an equivalent assembly language program [2].
  4. ^ Sun, Chengnian; Le, Vu; Zhang, Qirun; Su, Zhendong (2016). "Toward understanding compiler bugs in GCC and LLVM". Proceedings of the 25th International Symposium on Software Testing and Analysis. ISSTA 2016. ACM. pp. 294–305. doi:10.1145/2931037.2931074. ISBN 9781450343909. S2CID 8339241.
  5. ^ Baghai, Christian (4 April 2023). "The Evolution of Programming Languages: From Primitive Binary to High-Level Abstractions". Medium. Retrieved 10 July 2024.
  6. ^ Lecture notes. Compilers: Principles, Techniques, and Tools. Jing-Shin Chang. Department of Computer Science & Information Engineering. National Chi-Nan University
  7. ^ Naur, P. et al. "Report on ALGOL 60". Communications of the ACM 3 (May 1960), 299–314.
  8. ^ Chomsky, Noam; Lightfoot, David W. (2002). Syntactic Structures. Walter de Gruyter. ISBN 978-3-11-017279-9.
  9. ^ Gries, David (2012). "Appendix 1: Backus-Naur Form". The Science of Programming. Springer Science & Business Media. p. 304. ISBN 978-1461259831.
  10. ^ Hellige, Hans Dieter, ed. (2004) [November 2002]. Written at Bremen, Germany. Geschichten der Informatik - Visionen, Paradigmen, Leitmotive (in German) (1 ed.). Berlin / Heidelberg, Germany: Springer-Verlag. pp. 45, 104, 105. doi:10.1007/978-3-642-18631-8. ISBN 978-3-540-00217-8. ISBN 3-540-00217-0. (xii+514 pages)
  11. ^ Iverson, Kenneth E. (1962). A Programming Language. John Wiley & Sons. ISBN 978-0-471430-14-8.
  12. ^ Rutishauser, Heinz (1951). "Über automatische Rechenplanfertigung bei programmgesteuerten Rechenanlagen". Zeitschrift für Angewandte Mathematik und Mechanik (in German). 31: 255. doi:10.1002/zamm.19510310820.
  13. ^ Fothe, Michael; Wilke, Thomas, eds. (2015) [2014-11-14]. Written at Jena, Germany. Keller, Stack und automatisches Gedächtnis – eine Struktur mit Potenzial [Cellar, stack and automatic memory - a structure with potential] (PDF) (Tagungsband zum Kolloquium 14. November 2014 in Jena). GI Series: Lecture Notes in Informatics (LNI) – Thematics (in German). Vol. T-7. Bonn, Germany: Gesellschaft für Informatik (GI) / Köllen Druck + Verlag GmbH. pp. 20–21. ISBN 978-3-88579-426-4. ISSN 1614-3213. Archived (PDF) from the original on 12 April 2020. Retrieved 12 April 2020. [1] (77 pages)
  14. ^ Backus, John. "The history of FORTRAN I, II and III" (PDF). History of Programming Languages. Archived (PDF) from the original on 10 October 2022. {{cite book}}: |website= ignored (help)
  15. ^ Porter Adams, Vicki (5 October 1981). "Captain Grace M. Hopper: the Mother of COBOL". InfoWorld. 3 (20): 33. ISSN 0199-6649.
  16. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (March 1960). "LISP I Programmers Manual" (PDF). Boston, Massachusetts: Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory.
  17. ^ Compilers Principles, Techniques, & Tools 2nd edition by Aho, Lam, Sethi, Ullman ISBN 0-321-48681-1
  18. ^ Hopper, Grace Murray (1952). "The education of a computer". Proceedings of the 1952 ACM national meeting (Pittsburgh) on - ACM '52. pp. 243–249. doi:10.1145/609784.609818. S2CID 10081016.
  19. ^ Ridgway, Richard K. (1952). "Compiling routines". Proceedings of the 1952 ACM national meeting (Toronto) on - ACM '52. pp. 1–5. doi:10.1145/800259.808980. S2CID 14878552.
  20. ^ "List of early compilers and assemblers".
  21. ^ Hopper, Grace. "Keynote Address". Proceedings of the ACM SIGPLAN History of Programming Languages (HOPL) conference, June 1978. doi:10.1145/800025.1198341.
  22. ^ Bruderer, Herbert (21 December 2022). "Did Grace Hopper Create the First Compiler?".
  23. ^ Strawn, George; Strawn, Candace (2015). "Grace Hopper: Compilers and Cobol". IT Professional. 17 (Jan.-Feb. 2015): 62–64. doi:10.1109/MITP.2015.6.
  24. ^ Knuth, Donald E.; Pardo, Luis Trabb, "Early development of programming languages", Encyclopedia of Computer Science and Technology (Marcel Dekker) 7: 419–493
  25. ^ Hoare, C.A.R. (December 1973). "Hints on Programming Language Design" (PDF). p. 27. Archived (PDF) from the original on 10 October 2022. (This statement is sometimes erroneously attributed to Edsger W. Dijkstra, also involved in implementing the first ALGOL 60 compiler.)
  26. ^ Abelson, Hal; Dybvig, R. K.; et al. Rees, Jonathan; Clinger, William (eds.). "Revised(3) Report on the Algorithmic Language Scheme, (Dedicated to the Memory of ALGOL 60)". Retrieved 20 October 2009.
  27. ^ "Recursive Functions of Symbolic Expressions and Their Computation by Machine", Communications of the ACM, April 1960
  28. ^ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, Timothy P.; Levin, Michael I. (1965). Lisp 1.5 Programmers Manual. The MIT Press. ISBN 978-0-26213011-0.
  29. ^ "BCPL: A tool for compiler writing and system programming" M. Richards, University Mathematical Laboratory Cambridge, England 1969
  30. ^ BCPL: The Language and Its Compiler, M Richards, Cambridge University Press (first published 31 December 1981)
  31. ^ The BCPL Cintsys and Cintpos User Guide, M. Richards, 2017
  32. ^ Corbató, F. J.; Vyssotsky, V. A. "Introduction and Overview of the MULTICS System". 1965 Fall Joint Computer Conference. Multicians.org.
  33. ^ Report II of the SHARE Advanced Language Development Committee, 25 June 1964
  34. ^ Multicians.org "The Choice of PL/I" article, Editor /tom Van Vleck
  35. ^ "PL/I As a Tool for System Programming", F.J. Corbato, Datamation 6 May 1969 issue
  36. ^ "The Multics PL/1 Compiler", R. A. Freiburghouse, GE, Fall Joint Computer Conference 1969
  37. ^ Dennis M. Ritchie, "The Development of the C Language", ACM Second History of Programming Languages Conference, April 1993
  38. ^ S.C. Johnson, "a Portable C Compiler: Theory and Practice", 5th ACM POPL Symposium, January 1978
  39. ^ A. Snyder, A Portable Compiler for the Language C, MIT, 1974.
  40. ^ K. Nygaard, University of Oslo, Norway, "Basic Concepts in Object Oriented Programming", SIGPLAN Notices V21, 1986
  41. ^ B. Stroustrup: "What is Object-Oriented Programming?" Proceedings 14th ASU Conference, 1986.
  42. ^ Bjarne Stroustrup, "An Overview of the C++ Programming Language", Handbook of Object Technology (Editor: Saba Zamir, ISBN 0-8493-3135-8)
  43. ^ Leverett, Cattell, Hobbs, Newcomer, Reiner, Schatz, Wulf: "An Overview of the Production Quality Compiler-Compiler Project", CMU-CS-89-105, 1979
  44. ^ W. Wulf, K. Nori, "Delayed binding in PQCC generated compilers", CMU Research Showcase Report, CMU-CS-82-138, 1982
  45. ^ Joseph M. Newcomer, David Alex Lamb, Bruce W. Leverett, Michael Tighe, William A. Wulf - Carnegie-Mellon University and David Levine, Andrew H. Reinerit - Intermetrics: "TCOL Ada: Revised Report on An Intermediate Representation for the DOD Standard Programming Language", 1979
  46. ^ William A. Whitaker, "Ada - the project: the DoD High Order Working Group", ACM SIGPLAN Notices (Volume 28, No. 3, March 1991)
  47. ^ CECOM Center for Software Engineering Advanced Software Technology, "Final Report - Evaluation of the ACEC Benchmark Suite for Real-Time Applications", AD-A231 968, 1990
  48. ^ P.Biggar, E. de Vries, D. Gregg, "A Practical Solution for Scripting Language Compilers", submission to Science of Computer Programming, 2009
  49. ^ M.Hall, D. Padua, K. Pingali, "Compiler Research: The Next 50 Years", ACM Communications 2009 Vol 54 #2
  50. ^ Cooper and Torczon 2012, p. 8
  51. ^ Lattner, Chris (2017). "LLVM". In Brown, Amy; Wilson, Greg (eds.). The Architecture of Open Source Applications. Archived from the original on 2 December 2016. Retrieved 28 February 2017.
  52. ^ Aho, Lam, Sethi, Ullman 2007, p. 5-6, 109-189
  53. ^ Aho, Lam, Sethi, Ullman 2007, p. 111
  54. ^ Aho, Lam, Sethi, Ullman 2007, p. 8, 191-300
  55. ^ a b Blindell, Gabriel Hjort (3 June 2016). Instruction selection: Principles, methods, and applications. Switzerland: Springer. ISBN 978-3-31934019-7. OCLC 951745657.
  56. ^ Cooper and Toczon (2012), p. 540
  57. ^ "S1-A Simple Compiler", Compiler Construction Using Java, JavaCC, and Yacc, Hoboken, NJ, US: John Wiley & Sons, Inc., pp. 289–329, 28 February 2012, doi:10.1002/9781118112762.ch12, ISBN 978-1-118-11276-2, retrieved 17 May 2023
  58. ^ Ilyushin, Evgeniy; Namiot, Dmitry (2016). "On source-to-source compilers". International Journal of Open Information Technologies. 4 (5): 48–51. Archived from the original on 13 September 2022. Retrieved 14 September 2022.
  59. ^ Aycock, John (2003). "A Brief History of Just-in-Time". ACM Comput. Surv. 35 (2): 93–113. doi:10.1145/857076.857077. S2CID 15345671.
  60. ^ Swartz, Jordan S.; Betz, Vaugh; Rose, Jonathan (22–25 February 1998). "A fast routability-driven router for FPGAs" (PDF). Proceedings of the 1998 ACM/SIGDA sixth international symposium on Field programmable gate arrays - FPGA '98. Monterey, CA: ACM. pp. 140–149. doi:10.1145/275107.275134. ISBN 978-0897919784. S2CID 7128364. Archived (PDF) from the original on 9 August 2017.
  61. ^ Xilinx Staff (2009). "XST Synthesis Overview". Xilinx, Inc. Archived from the original on 2 November 2016. Retrieved 28 February 2017.
  62. ^ Altera Staff (2017). "Spectra-Q™ Engine". Altera.com. Archived from the original on 10 October 2016. Retrieved 28 February 2017.
  63. ^ "Decompilers - an overview | ScienceDirect Topics". www.sciencedirect.com. Retrieved 12 June 2022.
  64. ^ Chandrasekaran, Siddharth (26 January 2018). "Cross Compilation Demystified". embedjournal.com. Retrieved 5 March 2023.
  65. ^ Calingaert and Horowitz 1979, pp. 186-187

Further reading

External links

Look up compiler in Wiktionary, the free dictionary.
Wikibooks has a book on the topic of: Compiler Construction
Wikimedia Commons has media related to Compilers.