Office

Как сделать компиляцию. Как создать свой язык программирования: теория, инструменты и советы от практика

Компиляция / Компилятор

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

После ввода текста функции обработки события и сохранения проекта можно из меню Project выбрать команду Compile и выполнить компиляцию. Процесс и результат компиляции отражаются в диалоговом окне Compiling (РИС. В38). В это окно компилятор выводит ошибки (Errors), предупреждений (warnings) и подсказок (Hints). Сами сообщения об ошибках, предупреждения и подсказки отображаются в нижней части окна редактора кода (рис. В39).

Примечание

Если во время компиляции окна Compiling на экране нет, то выберите из меню Tools команду Environment options и на вкладке Preferences установите во включенное состояние переключатель Show compiler progr ess.

Компилятор

Компилятор

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

Как работает компилятор?

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

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

Как правило, компилятор состоит из нескольких стандартных частей: парсера, лексического анализатора, кодогенератора, оптимизатора. Парсер следит за правильностью структуры программы, лексический анализатор выделяет из потока парсера лексемы, определяет их и составляет внутренние таблицы переменных, вызовов процедур и т.д. Если компилятор является однопроходным, то в процессе анализа лексем может работать кодогенератор, формируя выходной машинный код. Так как компьютеры сейчас очень быстрые, то имеет смысл разработка многопроходных компиляторов: в этом случае вся программа переводится в промежуточный код – к примеру, пи-код. Пи-код интересен тем, что позволяет оптимизировать программу еще на начальном этапе, а кодогенератор способен преобразовать ее не только в коды данного компьютера, но и в выходной код другой платформы. Таким образом можно получить многоплатформенный компилятор, работающий, скажем, под DOS/DOS32/Windows и Linux.

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

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

Предлагаю вам перевод дневника Руи Уэяма (Rui Ueyama), программиста из Google, который он вел во время работы над реализацией компилятора языка C около трех с половиной лет назад.
Этот дневник не несет какой-то практической пользы и не является туториалом, но мне было очень интересно его прочитать, надеюсь и вам эта история тоже понравится:)

Я написал C компилятор за 40 дней, который назвал 8cc. Это дневник написанный мной в то время. Код и его историю можно посмотреть на GitHub .

День 8

Я пишу компилятор. Он начал работать после написания примерно 1000 строк кода. Вот несколько примеров, которые уже работают:

Int a = 1; a + 2; // => 3 int a = 61; int *b = &a; *b; // => 61

Массивы корректно преобразовываются в указатели, так что код ниже тоже работает. Также поддерживается вызов функций.

Char *c = "ab" + 1; printf("%c", *c); // => b

Реализовать это было не сложно, т.к. я делаю это уже второй раз. Я научился лучше управляться с массивами и указателями.

День 15

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

Конечно ему не хватает многих функций. Эти примеры программ подобраны так, чтобы не использовать их.
Реализация довольно проста; нет даже распределения регистров (register allocation).
Он компилирует программы на стеке, используя стек машины как стек. Каждая операция требует обращения к памяти. Но пока меня это устраивает.

В начале компилятор умещался примерно в 20 строк и единственное на что он был способен это прочитать целое значение со стандартного входа и запустить программу которая тут же завершается возвращая это целое.

Теперь он содержит около 2000 строк. Если посмотреть git, то кажется он развивался таким образом:

добавлены "+" и "-"
разделены фазы синтаксического анализа и генерации кода
добавлены "*" и "/"
добавлены переменные (неявно подразумевающие тип int)
добавлен вызов функций
добавлены строки
разделены генератор меток (tokenizer) и анализ синтаксиса
поддержка объявления базовых типов
добавлены указатели и массивы
поддержка выражений инициализации массивов
добавлен «if»
поддерживается объявление функций
добавлены «for» и «return»
поддерживается присвоение указателей
добавлено "=="
добавлены индексация массивов и арифметика указателей
добавлены "++", "--" и "!"

День 17

Я успешно реализовал структуры. Структура - это такой объект, который может занимать больше одного машинного слова. Их сложнее реализовать, чем примитивные типы, но это было легче чем я ожидал.

Кажется, это работает как надо; я могу определить структуру, содержащую структуру. Я могу определить указатель на структуру и разыменовать его. Структуры, содержащие массивы и массивы структур также работают. Хотя я уже знал, что код теоретически должен работать, я все равно обрадовался, когда он действительно заработал, даже в таком сложном случае.

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

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

День 18

Реализовать объединения было легче, т.к. это просто вариант структуры, в котором все поля имеют одинаковое смещение. Также реализован оператор "->". Проще простого.

Организовать поддержку чисел с плавающей точкой было тяжело. Похоже неявное преобразование типов между int и float работает, но числа с плавающей точкой не могут быть переданы в функции. В моем компиляторе все параметры функций сначала помещаются на стек, а затем записываются в регистры в порядке определенном в соглашении о вызовах x86-64. Но в этом процессе видимо есть баг. Он возвращает ошибку доступа к памяти (SIGSEGV). Его сложно отлаживать, рассматривая ассемблерный вывод, потому что мой компилятор не оптимизирует ассемблер для чтения. Я думал, что смогу закончить с этим за день, но я ошибался.

День 19

Я потратил время впустую, потому что забыл что в соответствии с соглашением о вызовах x86-64 кадр стека должен быть выровнен на 16 байт. Я обнаружил, что printf() падает с SEGV, если передать ей несколько чисел с плавающей точкой. Я попытался найти условия при которых это можно воспроизвести. Оказалось что имеет значение положение стекового кадра, что заставило меня вспомнить про требования ABI x86-64.

Я совсем не позаботился об этом, так что кадр стека был выровнен только по 8 байт, но print() не жаловалась пока принимала только целые числа. Эта проблема может быть легко исправлена корректировкой стекового кадра до вызова инструкции CALL. Но таких проблем не избежать если, тщательно не читать спецификацию перед написанием кода.

День 20

Я поменял отступы в коде компилятора с 2 на 4. Я больше привык к использованию 2-ух пробельных отступов, потому что такие используются на моей работе в Google. Но по некоторым причинам мне кажется отступы в 4 пробела больше подходят для «красивой программы с открытым исходным кодом».

Есть еще одно, более значимое, изменение. Я переписал тесты из shell скриптов на C. До этого изменения каждая тестовая функция компилируемая моим компилятором, связываллась с main() которая компилировалась GCC и затем запускалась shell скриптом. Это было медленно, т.к. порождало много процессов для каждого теста. У меня не было выбора когда я начинал проект, т.к. у моего компилятора не было многих функций. Например, он не мог сравнить результат с ожидаемым значением из-за отсутствия операторов сравнения. Теперь он достаточно мощный, чтобы компилировать код тестов. Так что я переписал их, чтобы сделать их быстрее.

Еще я реализовал большие типы, такие как long и double. Написание кода было веселым потому что я очень быстро преуспел в реализации этих функций.

День 21

Я почти закончил реализацию препроцессора C за один день. На самом деле это порт из моей предыдущей попытки написать компилятор.

Реализация препроцессора C не простая задача.

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

День 31

Реализовал функции для varargs, а именно va_start, va_arg и va_end. Они используются не часто, но я нуждался в них для компиляции функций, например printf.

Спецификация vararg для C не очень хорошо продумана. Если вы передаете все аргументы функции через стек, va_start может быть реализован довольно легко, но на современных процессорах и в современных соглашениях о вызовах аргументы передаются через регистры, чтобы уменьшить накладные расходы на вызов функций. Поэтому спецификация не соответствует реальности.

Грубо говоря, ABI для x86-64, стандартизированное AMD, требует чтобы функции с переменным числом аргументов копировали все регистры в стек, чтобы подготовиться к последующему вызову va_start. Я понимаю, что у них не было другого выбора, но это все равно выглядит неуклюже.

Мне стало интересно как другие компиляторы обрабатывают функции с переменным числом аргументов. Я посмотрел на заголовки TCC и, похоже, они не совместимы с ABI x86-64. Если структура данных для varargs отличается, то функции передающие va_list (такие как vprintf) становятся несовместимыми. Или я ошибаюсь? [И я действительно ошибаюсь - они совместимы.] Я также посмотрел на Clang, но он выглядит запутанным. Я не стал читать его. Если я буду читать слишком много кода других компиляторов, это может испортить веселье от собственной реализации.

День 32

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

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

День 33

Еще три файла скомпилированы сегодня. Итого 6 из 11. Но если считать строки кода, то это около 10% от общего числа. Оставшиеся файлы намного больше, так как содержат код ядра компилятора.

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

День 34

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

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

Есть опция командной строки для печати внутреннего абстрактного синтаксического дерева. Если есть ошибка в синтаксическом анализаторе, я хочу посмотреть на синтаксическое дерево.

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

Большинство внутренних структур данных имеют функции для преобразования в строку. Это полезно при использовании printf для отладки.

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

День 36

Реализовал составные литералы и переписал инициализатор структур и массивов. Мне не нравилась предыдущая реализация. Теперь инициализатор стал лучше. Я должен был написать красивый код с самого начала, но поскольку я понял это, только написав рабочий код, переписывание было неизбежным.

Думаю, единственная особенность, которой не хватает для самокомпиляции, это присваивание структур. Надеюсь все будет работать как задумано без особой отладки, когда она будет реализована.

День 37

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

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

День 38

Я исправил проблему, возникавшую во втором поколении, если лексический анализатор был самоскомпилирован. Она вызывала баг при котором -1 > 0 иногда возвращало true (я забыл про знаковое расширение). Есть еще один баг в размещении структур (struct layout). Осталось только три файла.

День 39

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

Я исправил много проблем, вызванных плохим качеством кода, который я писал на ранней стадии этого проекта. Это утомило меня.

Я верил, что имел все возможности для самокомпиляции, но это не правда. Нет даже префиксных операторов инкремента/декремента. Для некоторых особенностей C99 я переписал часть компилятора, чтобы сделать его более удобным для компиляции. Так как я не ожидал добраться до возможности самокомпиляции так быстро, я использовал столько новых особенностей C, сколько хотел.

День 40

Ура! Мой компилятор теперь может полностью себя скомпилировать!

Это заняло около 40 дней. Это очень короткий промежуток времени, для написания самокомпилируемого компилятора C. Вы так не думаете? Я считаю, что мой подход - вначале сделать небольшой компилятор для очень ограниченного подмножества C, и затем преобразовать его в настоящий компилятор C очень хорошо сработал. В любом случае сегодня я очень счастлив.

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

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

М. Черкашин Журнал "Монитор" N 4 1992 год Компилятор пишется так... Писать компилятор приходится чаще, чем обычно думают. Практически всякая большая система включает в себя входной язык - от примитивного до весьма сложного. Вспомним хотя бы dBASE - это ведь не язык программирования, а система баз данных. На нее даже программы пишутся. А раз нужен входной язык, то бывает нужен и компилятор. И часто нужен быстро. Конечно, всякий предпочтет компактный, быстрый, хорошо оптимизирующий компилятор, но далеко не всякому понравится такой компилятор писать. Чтобы писать сложные, эффективные и быстрые компиляторы, есть много рецептов. Но здесь речь пойдет не о них. Как написать компилятор просто - вот в чем вопрос! Ведь такой компилятор и короче, и отлаживается легче. Здесь не будет каких-то хитрых алгоритмов, позволяющих достигать чудес эффективности или каких- то особенных способов организации данных. Увы, с этими способами одна проблема: заставить их работать может только чудо. А в этой статье - только практические рекомендации, а работают они надежно! Оптимизацию и генерацию кода мы рассматривать не будем. Оптимизация - тема для отдельной статьи, а генерация кода - занятие для самоубийцы. Соломоново решение в данном случае - переводить программу не в коды машины, а на язык, который у вас уже есть. Так и делаем. Время компиляции, конечно, увеличивается, но зато мы избавляемся от большого количества неприятной возни. Модельный компилятор Лучший способ понять, как писать компилятор - написать его самому. Лучший способ объяснить это - предъявить текст программы. Вот мы и предлагаем статью-программу. Впрочем, ее можно читать и не заглядывая в листинг, но при этом вы много потеряете. Компилятор написан на Паскале, выходной язык - Паскаль, входной язык прост до идиотизма (pис.4). Читатели, владеющие с языком Паскаль, узнают и во входном языке знаковые конструкции. Посмотрим на рис 1. Наш модельный компилятор состоит из четырех частей: сканер, блок таблиц имен, основная часть компилятора и семантические подпрограммы. В том или ином виде эти части можно встретить в любом компиляторе. Сканер - это глаза компилятора, который обращается к тексту программы только через него. Сканер читает входной файл и избавляет остальные части копилятора от необходимости следить за каждым входным символом. В таблице имен хранится информация о переменных программы. Обращение к ней осуществляется в основном через процедуры блок таблицы имен. И, наконец, основная часть компилятора...компилирует. Точнее, следит за ходом компиляции. Как только становится ясно, с какой конструкцией мы имеем дело, управление передается специализированной, имеющей дело только с этой конструкцией, процедуре, которая называется семантической подпрограмммой. Сканер Среди всех конструкций, воспринимаемых компилятором, есть минимальные, и которые уже не исеет смысла делить на части. Например: идентификатор, число, строка, ключевое слово. Они называются лексемами. Компилятору нет нужды разбираться в их структуре. Кстати, в описании старого, доброго Алгола-60 использовался термин иероглифы, то есть нечто такое, что можно обозначить значком. Но у компьютера всего-то 256 символов - и приходится писать, например, "procedure". А посему идея следующая: отдельная процедура считывает программу из файла, выделяет оттуда лексемы и передает их основной части компилятора. А той до текста программы уже нет никакого дела. Такая подпрограмма называется сканером. В языке SIMPLE существуют пять видов лексем (pис.2): ключевые слова, идентификаторы, числа, спецсимволы и нечто в квадратных скобках. По поводу первых четырех типов, кажется, все ясно - см. рисунок. А пятый, последний - это наша хитрость. Дело в том, что компиляция выражений - это вопрос особый, и ему будет посвящена следующая статья. Поэтому, пользуясь тем, что выходной язык у нас Паскаль, мы перекладываем эту задачу на плечи компилятора с Паскаля. А чтобы у нас не возникало проблем - информацию, которые мы просто переписываеми в выходной файл, не разбираясь в его внутренней структуре, заключаем в квадратные скобки. Посмотрим на текст программы (Пример 1. Сканер). Основная процедура сканера - Scan. Вызывая ее, мы получаем очередную лексему. Мы можем даже считать ее аналогом процедуры ввода - со странного устройства, которое передает внутрь компьютера лексемы. Процедура Scan по первому символу лексемы определяет, что за лексема нас сейчас ждет, и вызывает "специализированную" процедуру, которая только этим типом лексем и занимается. Единственная загвоздка здесь - ключевые слова путаются с именами. Поэтому они считываются вместе, а уж потом одно отделяются от другого. Обратим внимание на вспомогательные процедуры GetCh и UngetCh. Процедура GetCh заменяет сиволы перевода строки и табуляции на пробелы и пропускает лишние пробелы (так получается, что несколько пробелов подряд эквивалентны одному). Процедура UngetCh используется, если мы "погорячились" и считали "лишний" символ. Тогда с помощью этой процедуры можно сказать: "Возьми обратно!" Процедура GetCh выдаст в следующий раз тот же символ. Таблица имен Когда человек пишет свою программу или разбирается в чужой, ему нужно держать в голове кое-какую информацию. Но машина железная, у нее головы нет. Поэтому необходима структура данных, которая про каждую переменную хранила бы определенную информацию. Эта структура называется таблицей имен. Без нее не обходится ни один компилятор. Таблица имен действительно похожа на таблицу. Она состоит из "строк" - ячеек таблицы имен, которые могут содержать инфорацию об одной простой переменной, например, переменной целого типа. (Обычно эти ячейки называют записями таблицы имен, но здесь сознательно используется другой термин, чтобы не было путаницы с языком SIMPLE). Посмотрим на рис.3. Там изображена структура нашей таблицей имен. Проще всего, когда переменная - целого типа. Для нее нужно хранить всего ничего - имя и тип (integer). В реальных, больших компиляторах, впрочем, есть еще кое-что - ее адрес, например. Но мы, слава Богу, компилируем в Паскаль! С записями будет посложнее. Даже в голове у нас они хранятся не целиком, а как нечто, сложенное из кусочков. Вот фрагмент описаний переменных языка SIMPLE (Рис 3А). В голове он превратится во что-то подобное рис 3Б. А к чему должно быть ближе то, что хранится в таблице имен? Наверное, к тому, что хранится в голове, а не на бумаге. Но в одну ячейку таблицы имен может поместиться информация максимум об одной переменной. Поэтому сейчас наша задача - "раскидать" по ячейкам информацию о структуре записи. Это можно сделать разными способами. Здесь выбран следующий. На любую переменную - i,j,u и т.д. - заводим одну запись таблицы имен. Если эта переменная - запись, то в поле Fields пишется ссылка на описание структуры ее полей. В данном случае ссылка - просто номер ячейки таблицы имен, содержащей заголовок этого описания. Таким образом, число в поле Fields соответствует жирным стрелкам на рис 3Б. Описание структуры записи представляет собой заголовок (слово (record) на Рис 3Б или ячейка со значком " в поле Pname на Рис 3В) и еще несколько - по одной на каждое поле - ячеек. Каждая из этих ячеек (в том числе и заголовок) содержит в поле Ref номер ячейки для следующего поля записи. Таким образом, число в поле Ref соответствует нежирной стрелке на Рис 3Б. Ячейка для последнего поля содержит в поле Ref ноль. Это означает "Дальше полей нет!" и обозначается на Рис 3В диагональным крестом. Если же поле записи снова запись, то соответствующая этому полю ячейка содержит в поле Fields ссылку на описание структуры полей. Первые MaxKey записей таблицы имен на самом деле не имена, а ключевые слова. Имена и ключевые слова вообще очень легко перепутать. Поэтому если имя будет найдено в таблице имен, но в записи с номером не большим, чем MaxKey, то это на самом деле не имя, а ключевое слово. Можно, конечно, завести для ключевых слов отдельный список, но так, как сделано здесь, проще. Для обращения к таблице имен (Пример 2) предусмотрено всего три процедуры: поиск имени в таблице, помещение имени в таблицу и определение по номеру записи, соответствует ли она ключевому слову или нет (это всего лишь сравнение с константой MaxKey - но тем не менее это полезно). Основной блок компилятора. К моменту, когда вы уже готовы сесть и начать писать текст этого блока, вы должны знать, что у вас делают остальные части (сканер, процедуры работы с таблицами и т.д.). Причем желательно, чтобы остальные части делали побольше, а эта поменьше. Отдельную небольшую подпрограмму вы всегда отладите, а вот процедуру, которая вызыввает несколько других процедур, отладить несколько сложнее. Короче, главные проблеы у вас будут все-таки с основной частью. Посмотрите на текст программы (Пример 3). Что должна делать основная часть? Читать описания переменных и заполнать таблицу имен. Потом содержимое таблицы имен должно быть вовремя записано в выходной файл в виде описаний переменных на языке Паскаль. Кроме того, для каждого оператора на языке SIMPLE в выходной файл должен быть записан эквивалентный ему оператор языка Паскаль. В описаниях основная проблема - это описания записей. "Разобраться" с ними - значит поместить их в таблицу имен. В данной программе это сделано рекурсивно. А действительно, как это еще сделать? Ведь и записи определены рекурсивно: "...содержит в качестве полей целые числа и [другие]_записи". Есть также определенные проблемы и с трансляцией описаний. Оператор присваивания или печати мы всегда можем считать целиком в память и уже потом компилировать. А вот оператор цикла сам может содержать внутри себя тысячи операторов. Поэтому нам остается только одно - встретив while...do, записать в выходной файл начало оператора цикла, потом как ни в чем ни бывало компилировать внутренние операторы цикла, а встретив close и вспомнив, что когда-то мы встречали while...do, записать в выходной файл все, что останется. К счастью, мы копилируе в Паскаль, а не в коды. И запоминать на самом деле нам ничего не надо. Достаточно, встретив while...do, написать "while ... do begin", а встретив close, написать "end" - и мы никогда не прогадаем, потому что "begin" ставим всегда. А вот если бы мы транслировали в машинный код нам необходимо было бы знать, с какого адреса начинался этот оператор. А для этого нужна структура данных, называемая стеком. Куда идти дальше? У тех, кто дошел до этого места, возможно, возникнут вопросы. Я не берусь предугадать их все, но на некоторые можно ответить заранее. - Что еще нужно сделать, если с компилятором будут работать часто? - Необходимо вставить диагностику ошибок. На практике компилятор в большинстве случаев выдает не скомпилированный текст, а сообщение об ошибке. Поэтому и писать компилятор нужно так, чтобы проверка на ошибки производилась как можно легче. В частности, чем больше хитрых приемов вы используете (например, ускоряющих компиляцию), тем больше вам придется ломать голову над тем, куда этот алгоритм забредет в случае ошибки и как сделать, чтобы копилятор не сбился с пути и обнаружил не только первую встретившуюся ошибку, но еще и какие-то другие. - Как вставлять новые конструкции в язык? - Если речь идет о структурах данных, то лучше добавить новое поле в запись таблицы имен, чем ломать голову над тем, как сэкономить лишнее поле. Если речь идет об операторах - добавьте еще одну специализированную процедуру, копилирующую данный оператор. Соответственно, вызов этой процедуры должен быть вставлен в процедуру Code. - А если хочется все-таки сделать компилятор более эффективным? - Ради Бога! Только сначала пусть он заработает. А потом его можно оптимизировать по вкусу. Кроме того, прежде чем применить многообещающий алгоритм, хорошенько проверьте, будет ли он столь эффективен в вашем случае. А то ведь все эти алгоритмы на практике хороши в весьма специальных случаях. Подумайте, стоит ли овчинка выделки. - Как отлаживать компилятор? - Компилятор - очень коварная программа. И выловить все ошибки из него обычно не удается. Не полагайтесь на свою интуицию. Сделайте себе набор тестов - небольших, но сам набор пусть будет представительнымм. И когда компилятор будет подходить к готовности, прогоните их все. (Да, в том числе и те, что уже когда-то проходили!) И напоследок еще один совет. Больше простоты! Если бы программисты всегда ему следовали, то работающих программ было бы несомненно больше (а недоотлаженных, брошенных на полдороге - меньше). Пример 1. Сканер (**************************************) (* Данные для сканера *) (**************************************) const ExprLen = 240; Type LexEnum = (LexKeyword, LexNames, LexNumber, LexSpecs, LexExpr); SpecEnum = (SemiColn, Comma, Assign); var LexType: LexEnum; LexVal: integer; (* Буфер для кое-чего в квадратных скобках *) Buf: string ; EndStream, LogEOF: boolean; (* Буфер и указатель буфера строки входного файла*) LineBuf: string ; LinePtr: integer; (* А вот здесь мы храним символ, от которого мы отказались с помощью функции UngetCh *) OldCh: char; (* True, если в OldCh что-то лежит*) Suspend: boolean; procedure IniScan; begin LineBuf:= " "; LinePtr:= 1; Suspend:=False; end; (* Сканер. Оставляет в переменных LexType и LexVal. Нечто в квадратных скобках остается в буфере Buf. Функции Alpha (c) и Num (c) равны True, если их аргумент буква или цифра соответственно. *) procedure Scan; var Ch: char; begin if Ch = " " then (* Бог с Ним! *) else UngetCh; if EndStream then LogEOF:= true (* Конец файла! *) (* Встретили квадратную скобку - впереди выражение *) else if Ch = "[" then Brackets (* Впереди ключевое слово или переменная, а вот что неясно *) else if Alpha (Ch) then KeyOrNames else if Num (Ch) then Numbers (* Число!*) else if Ch = ";" then Spech (SemiColn) else if Ch = "," then Spech (Comma) else if Ch = ":" then begin Ch:= GetCh; Ch:= GetCh; if Ch = "=" then Spech (Assign); (* := *) end; end; (* Сначала прочитать нечто алфавитно-цифровое, а потом уже разобраться, что это - ключевое слово или идентификатор *) procedure KeyOrNames; var LexBuf: bloc; i,t: integer; Ch: char; begin Ch:= GetCh; i:= 1; repeat LexBuf [i] := Ch; i:= i+1; Ch:= GetCh; until not (Alpha (Ch) or Num (Ch)); LexBuf := chr (i); UngetCh; t:= Find (LexBuf); if KeyEntry (t) then begin LexType:= LexKeyword; LexVal:= t; end else if t 0 then begin LexType:= LexNames; Lexal:= t; end else begin LexVal:= LexNames; t:= PutIn (LexBuf); end; end; (* Считать число *) procedure Numbers; Count: integer; Ch: char; begin Ch:= GetCh; Count:= 0; repeat Count:= 10*Count + (ord (Ch)-ord ("0")); Ch:= GetCh; until not Num (Ch); UngetCh; LexType:= LexNumber; LexVal:= Counter; end; (* Установить переменные LexType и LexVal для спецсимволов *) procedure Spech (Sym: EnumSpec); begin LexType:= LexSpecs; LexVal:= ord (Sym); end; (Нечто в квадратных скобках **) procedure Brackets; var Ch: char; i: integer; begin Ch:= GetCh; Ch:= GetCh; i:= 1; while Ch "]" do begin Buf [i] := Ch; Ch:= GetCh; i:= i+1; end; Buf := chr (i-1); LexType:= LexExpr; end; (* Вспомогательные подпрограммы для сканера *) Function GetCh: char; var i: integer; Ch: char; begin if Suspend then begin GetCh:= OldCh; Suspend:= False; end else repeat if LinePtr>legth (LineBuf) begin Ch:= " "; NewLine; end else begin Ch:= LineBuf ; LinePtr:= LinePtr+1; end; until ((Ch" ") and (Chchr (Tab))) or Eof (SRC); if Eof (SRC) then EndStream:= 1; end; procedure UngetCh; begin Suspend:=True; end; procedure NewLine; begin ReadLn (LineBuf); if Eof (SRC) then LinePtr:= 1; LinePtr:= 1; end; Пример 2. Таблица имен. (**************************************) (* Процедуры для таблицы имен *) (**************************************) const WordLen = 32; TabSize = 1024; MaxKey = 12; Type bloc = string ; EnumTag = (Dunno, TagRecord, TagInt); (* Ячейка таблицы имен *) ncell = record Pname: bloc; Tag: EnumTag; Ref: integer; Fields: integer; end; (* Таблица имен *) var TableOfNames: array of bloc; TabLen: integer; (* Размер таблицы имен *) procedure IniTab; begin TabLen:= 0; PutIn("procedure"); PutIn("main"); PutIn("end"); PutIn("int"); PutIn("record"); PutIn("if"); PutIn("then"); PutIn("else"); PutIn("close"); PutIn("while"); PutIn("do"); PutIn("print"); end; (* Найти переменную с данным именем *) int Find (Name: bloc); var i: integer; begin Find:= 0; for i:=MaxKey+1 to TabLen do if Name = TableOfNames [i].Pname; then Find:= i; end; (* Создать новую запись таблицы имен с данным именем *) procedure PutIn (Name:bloc); begin TabLen:= TabLen +1; With TableOfNames do begin Pname:= Name; Tag:= Dunno; end; end; (* Если номер записи не больше MaxKey, то это на самом деле не имя, а ключевое слово *) Function KeyEntry (t:integer) : boolean; begin KeyEntry:= (t>0) and (t LexKey or LexVal KeyProc do Declare; ProgInit; (* Вывести стандартный заголовок программы на Паскале *) CommonTop:= TabLen; while not LogEOF do ThisProc; (* Одна процедура *) ProgClose; (* Вывести стандартное окончание программы на Паскале *) end; (* Скомпилировать одну процедуру *) procedure ThisProc; begin TabLen:= ThisProc; while (LexType = LexKey) and (LexVal = ord (KeyInt) or LexVal = ord (KeyRecord)) do Declare; ProcInit; (* Заголовок процедуры *) Code; ProcClose; (* Окончание процедуры *) end; (* Обработать одно описание *) procedure Declare; var Y:integer; begin if (LexType=LexKey) and (LexVal=ord (KeyInt) then NameList (TagInt,0) else if (LexType=LexKey) and (LexVal=ord (LexRecord)) then begin PutIn (""); TableOfNames .Fields:= 0; Y:= TabLen; ReadFields (Y); NameList (TagRecord,Y); end; end; (* Считать список имен переменных после описателя и запихнуть эти имена в таблицу имен*) procedure NameList (TagVal, FldVal: integer); begin repeat Scan; With TableOfNames do begin Tag:= TagVal; Fields:= FldVal; Ref:= 0; end; Scan; until (LexType=LexSpecs) and (LexVal=ord (SemiColn)); end; (* Обработать поля записи *) procedure ReadFields (Y0: integer); var X,Y,Pre: integer; begin Y:= Y0; repeat Pre:= Y; Dcl1 (X,Y); TableOfNames .Ref:= X; until (LexType=LexKey) and (LexVal=ord (KeyEnd)); Table OfNames [Y].Ref:= 0; end; (* Dcl1 делает почти тоже, что и Declare, только описание, которое он считывает, является полем записи. Поэтому вместо NameList используется другая процедура *) procedure Dcl1 (var X,Y: integer); var C:integer; begin if (LexType=LexKey) and (LexVal=ord (KeyInt)) then NameList1 (TagInt,0) else if (LexType=LexKey) and (LexVal=ord (LexRecord)) then begin PutIn (""); TableOfNames .Fields:= 0; C:= TabLen; ReadFields (C); NameList1 (TagRecord,C,X,Y); end; end; (* Разница между NameList и NameList1 в том, что последняя устанавливает "указатели" Ref. *) procedure NameList1 (TagVal,FldVal: integer; var X,Y: integer); begin X:=0; Pre:=0; repeat Scan; if X=0 then X:=LexVal; Y:=LexVal; With TableOfNames do begin Tag:=TagVal; Fields:=FldVal; end; if Pre0 then TableOfNames .Ref:= LexVal; Pre:=LexVal; Scan; until (LexType=LexSpecs) and (LexVal=ord (SemiColn)); end; (* Скомпилировать все операторы в процедуре *) procedure Code; begin repeat Statement; until (LexType=LexKey) and (LexVal=ord (KeyEnd)); end; (* Скомпилировать один оператор *) procedure Statement; begin if LexType = LexKey then (*Большинство операторов можно распознать по первому ключевому слову*) begin if LexVal = ord (KeyIf) then SempIf else if LexVal = ord (KeyElse) then SempElse else if LexVal = ord (KeyWhile) then SempWhile else if LexVal = ord (KeyClose) then SempClose else if LexVal = ord (KeyPrint) then SempPrint end else if (LexType=LexNames) then SempAssignOrCall; (* Присваивание или вызов процедуры *) end; (* Семантические подпрограммы *) (* If...then *) procedure SempIf; begin WriteLn ("if"); Scan; WriteLn (Buf); WriteLn ("then begin"); Scan; (**) Scan; end; (* Else *) procedure SempElse; begin WriteLn ("end else begin"); Scan; end; (* Print...*) procedure SempPrint; begin Scan; Write ("WriteLn"); id:= TableOfNames .Pname; Write ("(","""",id," = ","""",",",id,")"); Scan; (*;*) Scan; end; (* По первой лексеме нельзя отличить вызов процедуры от присваивания. Поэтому отлдичаем одно от другого в одной семантической подпрограмме по ходу дела *) procedure SempAssignOrCall; begin Write (TableOfNames .Pname); Scan; (*:=*) if (LexType = LexSpecs) and (LexVal = ord (Assign)) (* Присваивание *) then begin Scan; WriteLn (" := ",Buf,";"); Scan; (*;*) end else if (LexType = LexSpecs) and (LExVal = ord (SemiColn)) then WriteLn (";"); (* Вызов процедуры *) Scan; end; (* While...do *) procedure SempWhile; begin WriteLn ("While"); Scan; WriteLn (Buf); WriteLn ("do begin"); Scan; Scan; end; (* Close *) procedure SempClose; begin WriteLn ("end;"); Scan; end; Краткий обзор языка SIMPLE Программа на языке SIMPLE есть: описания переменных, общих для всей программы; procedure имя; begin описание переменных процедуры; операторы; end; .... procedure имя; .... Одна из процедур носит имя main. Эта процедура и есть программа. Описание int список переменных через запятую; record описание; .... описание; end список переменных через запятую; Описание Присваивание: Имя:= [....]; Вызов процедуры: Имя; Печать: Print имя; Условный: if [....] then операторы else операторы close; Цикла: while [....] do операторы close; Ключевые слова (LexType = LexKey) procedure then main else end close int while record do if print Имена (LexType = LexNames) Например: sight gh218 slow1a6 Числа (LexType = LexNumber) Например: 17 0218 33 1 Спецсимволы (LexType = LexSpecs) := , : "Нечто в " (LexType = LexExpr) Например:

Здравствуйте, дорогие читатели! Сегодня мы с вами немного окунемся в теорию. Наверняка, вы все когда-то хотели отправить свою супер-пупер программу другу. Но как это сделать? Не заставлять же его устанавливать PascalABC.NET! О том, как это сделать, мы сегодня и поговорим.

Все языки программирования делятся на два типа - интерпретируемые и компилируемые .

Интерпретаторы

Программируя на интерпретируемом языке, мы пишем программу не для выполнения в процессоре, а для выполнения программой-интерпретатором. Ее также называют виртуальной машиной.

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

При интерпретации выполнение кода происходит последовательно строка за строкой (от инструкции до инструкции). Операционная система взаимодействует с интерпретатором, а не исходным кодом.

Примеры интерпретируемых языков: PHP, JavaScript, C#, Python.

Скомпилированные программы работают быстрее, но при этом очень много времени тратится на компиляция исходного кода.

Программы же, рассчитанные на интерпретаторы, могут выполняться в любой системе, где таковой интерпретатор присутствует. Типичный пример - код JavaScript. Интерпретатором его выступает любой современный браузер. Вы можете однократно написать код на JavaScript, включив его в html-файл, и он будет одинаково выполняться в любой среде, где есть браузер. Не важно, будет ли это Safari в Mac OS, или же Internet Explorer в Windows.

Компиляторы

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

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

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

Примеры компилируемых языков: C, C++, Pascal, Delphi.

Ход работы компилятора.

Препроцессинг

Эту операцию осуществляет текстовый препроцессор .

Исходный текст частично обрабатывается - производятся:

Замена комментариев пустыми строками
Подключение модулей и т. д. и т. п.

Компиляция

Результатом компиляции является объектный код .

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

Компоновка

Компоновка также может носить следующие названия: связывание , сборка или линковка .

Это последний этап процесса получения исполняемого файла, состоящий из связывания воедино всех объектных файлов проекта .

EXE файл.

После компоновки у вас образуется.EXE файл вашей программы. Вы можете кинуть ее другу, и она откроется у него прямо в командной строке, как в старом добром DOS. Давайте попробуем создать.EXE файл. Все действия будут приводится в PascalABC.NET.

Заходим в Сервис -> Настройки -> Опции компиляции. Поверяем, стоит ли галочка напротив 2 пункта. Если стоит, то убираем ее.

Теперь откройте свою программу и запустите ее.

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

Вот он,.EXE файл.

Кликаем по приложению. Как вы видите, после ввода данных, окошко сразу закрывается. Для того чтобы окно не закрывалось сразу, следует дописать две строчки кода, а именно: uses crt (перед разделом описания переменных) и readkey (в конце кода, перед оператором end).

Подключаем внешнюю библиотеку crt и используем встроенную в нее функцию readkey.

Теперь окно закроется по нажатию любой клавиши.

На заметку: PascalABC.NET - это интегрированная среда разработки.

Среда разработки включает в себя:

текстовый редактор;
компилятор;
средства автоматизации сборки;
отладчик.

На сегодня все! Задавайте любые вопросы в комментариях к этой статье. Не забывайте кликать по кнопочкам и делится ссылками на наш сайт со своими друзьями. А для того, чтобы не пропустить выход очередной статьи, рекомендую вам подписаться на рассылку новостей от нашего сайта. Одна из них находится в самом верху справа, другая - в футере сайта.

Кафедра компьютерной инженерии

Специальность «Системное программирование»

Как создать свой простой компилятор

Архитектура современных компиляторов

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

И так, что же такое современный компилятор? Рассмотрим его сначала как черный ящик. На входе компилятору поступает файл с некоторыми (обычно текстовыми) данными – описание программы на исходном языке компилятора. На выходе компилятор выдает файл с другими данными – описание той же программы, но уже на другом языке – зачастую в машинном коде, или на языке ассемблера. То есть, компилятор можно рассматривать как переводчик программ с одного машинного языка на другой. Тут возникает проблема масштабируемости. Сейчас существует множество языков и множество целевых платформ (не забываем так же про виртуальные процессоры, такие как JVM, CLR, Parrot и т.д.). Когда создается новый язык программирования, Появляется необходимость использовать его на разных архитектурах, а как следствие приходится писать множество компиляторов. Эту проблему достаточно быстро осознали, и перешли к 3х этапной модели компиляции программ .

Компилятор разделили на 3 относительно независимые части:

Парсер, генератор дерева синтаксического разбора
Оптимизатор промежуточного представления кода
Генератор кода из промежуточного представления в целевую платформу

Такая архитектура позволила уменьшить объем работы, связанный с созданием новых языков программирования, позволала переносить программы на новые платформы(кто бы мог подумать, есть способы конвертации С++ кода в JavaScript!), а так же упростила разработку и отладку компилятора в целом.

LLVM как библиотека для разработки компиляторов

Ярким примером такой системы компиляторов является Low Level Virtual Machine (LLVM) . На рисунке наглядно показано, как с помощью LLVM реализуется компиляция различных языков.

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

%char = type i8 %int = type i32 @msg = internal constant c"Hello World!\00" declare %int @puts(%char*) define %int @main() { call %int @puts(%char* getelementptr inbounds (* @msg, %int 0, %int 0)) ret %int 0 }

Лексический и грамматический анализ исходного кода

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

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

Написание парсеров и лексеров дело рутинное и сложное. Но прогресс не стоит на месте и появилось множество программ которые по описанию лексики и грамматики языка генерируют парсер и лексер на Вашем любимом языке программирования.

Так сложилось, что я предпочитаю С/С++, поэтому для примеров буду использовать flex для получения набора токенов и bison для построения дерева разбора.

Программа на языке LEX состоит из 3х частей, первая часть – это обычный код на С, заключенный в символы %{ … }%. Второй блок, это список регулярных выражений, и соответствующий им код на С. Каждый раз, когда лексер будет встречать что-то во входном потоке, подходящее под регулярное выражение , он будет исполнять соответствующий ему код на С. 3я часть программы, это тоже код на С, в данном примере она не требуется и потому отсутствует. Пример простейшей программы с использованием генератора lex:

%{ #include %} %% + printf("NUMBER\n"); * printf("WORD\n"); %% Откомпилировать и запустить программу можно так: $ lex example.l $ cc lex.yy.c -o example -lfl $ ./example foo WORD bar WORD 123 NUMBER bar123 WORD 123bar NUMBER WORD После чего вы получите программу, которая читает входной поток с клавиатуры, и при каждой встрече числа выводит слово «NUMBER», а каждый раз, когда встречает слово, выводит «WORD»

Грамматический анализ

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

Power on Двигатель включен! power off Двигатель выключен! set speed 100 Задана новая скорость вращения!

Необходимо распознавать следующие токены: power, on/off (состояние STATE), set, speed и числа (NUMBER). Lex-анализатор выглядит следующим образом

%{ #include #include "y.tab.h" %} %% + yylval=atoi(yytext, 10); return NUMBER; poer return TOKPOWER; on|off yylval=!strcmp(yytext,"on"); return STATE; set return TOKSET; speed return TOKSPEED; \n /* игнорируем символ конца строки */; [ \t]+ /* игнорируем пробелы и символы табуляции */; %%

В этом примере нужно отметить некоторые изменения, по сравнению с предыдущим примером. Во-первых, был подключен файл "y.tab.h", во-вторых, на экран больше ничего не выводится, а лишь возвращаются имена токенов. Это изменение нужно потому, что поток токенов отдается на вход YACC, которому неважно, что выводится на экран. В файле y.tab.h как раз находятся определения этих токенов.

Теперь про сам файл y.tab.h. Он генерируется парсером BISON из файла грамматики, который мы сейчас напишем. Наш язык очень прост,такой же простой будет и его грамматика:

%token NUMBER TOKPOWER STATE TOKSET TOKSPEED commands: /* empty */ | commands command ; command: power_switch | set_speed ; power_switch: TOKPOWER STATE { if($2) // вместо $2 будет подставлено yylval из lex файла для токена STATE printf("\Двигатель включен!\n"); else printf("\tДвигатель выключен!\n"); } ; set_speed: TOKSET TOKSPEED NUMBER { printf("\tЗадана новая скорость вращения - %d оборотов в минуту!\n", $3); } ;

Первая часть грамматики означает, что имеются "команды" (commands), и эти команды состоят из отдельных "команд" (command). Как нетрудно заметить, это определение рекурсивно, ведь оно содержит в себе само себя. Благодаря рекурсии, программа способна постепенно сокращать набор команд одну за одной. Второе правило определяет, что из себя представляет команда. Предпологается лишь два типа команд - power_switch (вкл/выкл двигателя) и set_speed (установка скорости). Здесь используется знак ИЛИ - | . В целом правило означает: "command может быть power_switch или set_speed". Правило power_switch состоит из токена POWER (это просто слово "power"), после которого идет состояние (оно определено в Lex-файле как "on" или "off"). Немного более сложным является последнее правило set_speed, состоящее из токена SET (слово "set"), токена SPEED (слово "speed") и числа.