Создание компилятора с языка Pascal на язык С

СОДЕРЖАНИЕ
TOC \o "1-3" \h \z \u ВВЕДЕНИЕ PAGEREF _Toc75099085 \h 41 СТРУКТУРА И ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ КОМПИЛЯТОРА PAGEREF _Toc75099086 \h 52 ЛЕКСИЧЕСКИЙ АНАЛИЗ PAGEREF _Toc75099087 \h 73 СИНТАКСИЧЕСКИЙ АНАЛИЗ PAGEREF _Toc75099088 \h 114 СЕМАНТИЧЕСКИЙ АНАЛИЗ PAGEREF _Toc75099089 \h 155 ОПТИМИЗАЦИЯ PAGEREF _Toc75099090 \h 166 ГЕНЕРАЦИЯ КОДА PAGEREF _Toc75099091 \h 19ЗАКЛЮЧЕНИЕ PAGEREF _Toc75099092 \h 25СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ PAGEREF _Toc75099093 \h 26ПРИЛОЖЕНИЕ А PAGEREF _Toc75099094 \h 28ПРИЛОЖЕНИЕ Б PAGEREF _Toc75099095 \h 29ПРИЛОЖЕНИЕ В PAGEREF _Toc75099096 \h 31

ВВЕДЕНИЕДля преобразования программы, представленной на одном из языков программирования, в программу на другом языке и, в определенном смысле, равносильную первой существуют специальные программы - трансляторы.
Трансляторы делятся на интерпретаторы и компиляторы. Интерпретаторы исполняют программу сразу же в зависимости от реализации построчно или целиком после предварительного анализа. Компиляторы преобразуют программы в машинный язык, принимаемый и исполняемый непосредственно процессором. Некоторые компиляторы способны вести себя как интерпретаторы, компилирую программу непосредственно в память.
Следует также отметить, что крайне важной частью процесса трансляции является точная диагностика ошибок, допущенных во входной программе.
Задачей данной курсовой работы является создание компилятора с языка Pascal на язык Си.

1 СТРУКТУРА И ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ КОМПИЛЯТОРАБазовые требования к реализации компилятора, на удовлетворение которых должны быть направлены решения:
- полнота и конформность стандарту языка - реализация должна поддерживать все свойства языка С, определенные в стандарте, и обеспечивать полное соответствие стандарту;
- универсальность - реализация должна обеспечивать необходимую общность с тем, чтобы поддерживать не только задачи трансляции, но и целый ряд других операций над текстами С (анализ программ, извлечение семантической информации и т.д.);
- эффективность - реализация должна обеспечивать производительность, сравнимую с современными промышленными компиляторами С++.
Структура компилятора.
Процесс компиляции состоит из следующих этапов.
1.Лексический анализ. На этом этапе последовательность символов исходного файла преобразуется в последовательность лексем.
2.Синтаксический (грамматический) анализ. Последовательность лексем преобразуется в дерево разбора.
3.Семантический анализ. Дерево разбора обрабатывается с целью установления его семантики (смысла) - например, привязка идентификаторов к их декларациям, типам, проверка совместимости, определение типов выражений и т. д. Результат обычно называется «промежуточным представлением/кодом», и может быть дополненным деревом разбора, новым деревом, абстрактным набором команд или чем-то ещё, удобным для дальнейшей обработки.
4. Оптимизация. Выполняется удаление излишних конструкций и упрощение кода с сохранением его смысла. Оптимизация может быть на разных уровнях и этапах - например, над промежуточным кодом или над конечным машинным кодом.
5. Генерация кода. Из промежуточного представления порождается код на целевом языке.

2 ЛЕКСИЧЕСКИЙ АНАЛИЗЛексический анализ - первая фаза компиляции. На этом этапе исходный текст программы на транслируемом языке преобразовывается в последовательность лексем, принадлежащих различным лексическим классам. В таком виде синтаксический анализатор получает исходную программу.
Помимо этого, лексический анализатор может решать и другие задачи, такие как:
-отбрасывание пробельных символов и комментариев (пробел, символы табуляции и новой строки, а также, возможно, некоторые другие символы, использующиеся для отделения токенов друг от друга во входном потоке);
-синхронизация сообщений об ошибках с исходным текстом программ (лексический анализатор может отслеживать количество символов новой строки, чтобы каждое сообщение об ошибке сопровождалось номером строки, в которой она обнаружена).
Существует несколько способов реализации лексического анализа: конечные автоматы или генераторы лексических анализаторов (lex, Flex, gplex, OOlex).
Для реализации был выбран непрямой лексический анализатор на основе диаграмм переходов.
Непрямой лексический анализатор реализуется как совокупность независимых конечных автоматов, проверяющих принадлежность к отдельным лексемам, автоматы можно описать с использованием диаграмм Вирта.
Каждый автомат представлен соответствующей функцией, осуществляющей имитацию переходов от начального состояния к одному из заключительных.
Принципы программной реализации:
-каждому состоянию ставится в соответствии метка;
-анализируемые альтернативы проверяются условными операторами;
-если результат проверки является истиной, проводится обработка контекста, берется следующий символ и осуществляется переход на новую метку (в новое состояние);
-процесс повторяется до тех пор, пока не произойдет переход в одно из заключительных состояний.
Алгоритм работы лексического анализатора.
В программе лексемы разделены на классы: ключевые слова, операторы, пунктуаторы, символы, скобки, числа.
Описание класса:
class KeyWord{ private:
list<AnsiString> keyword; //список ключевых слов
public:();operator ()(const AnsiString s); // проверяет принадлежность к списку
};
Входные данные помещаются в массив vector<struct symbol> sym_table (посимвольно).
Структура symbol передает символ, строку, столбец, длину символа и позицию от начала.
Выходные данные формируются в массиве vector<struct cell> scaner_result.
Структура cell содержит описание типа, саму лексему, строку, столбец, длину лексемы и позицию от начала.
Символ из массива sym_table проверяется на принадлежность к определенному классу лексем, если функция возвращает значение истина, то символ переписывается в переменную curr_cell (объект структуры cell) и переходим к следующему символу, так же проверяем на принадлежность к этому же классу лексем, если функция возвращает значение ложь, то записываем данные из переменной curr_cell в массив scanner_result, обнуляем переменную curr_cell, проверяем если ли в массиве sym_table еще символы, если он не пустой, то переходим к следующему.
Данные об ошибках хранятся в массиве error_result.
Как только массив sym_table оказался пуст, данные из массивов scanner_result и error_result выводятся в таблицы.
Исходный код программы, выбранной для разбора, представлен в Приложении А. Результат разбора кода лексическим анализатором представлен на рисунке 1.

Рисунок 1 - Результат работы лексического анализатора
В фазе лексического анализа возможны следующие ошибки - не закрыт комментарий, незавершенная строка, ошибка в определении вещественной константы, ошибка в определении символьной константы.
Так «область видимости» лексического анализатора узка, то без помощи других компонентов компилятора ему достаточно сложно обнаружить ошибки в исходном тексте программы, например, если в программе токен F впервые встретился в контексте F=a*33. Поскольку F является корректной лексемой, лексический анализатор должен вернуть этот токен синтаксическому анализатору, который в свою очередь должен обработать ошибку «Неопределенный тип».

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

3 СИНТАКСИЧЕСКИЙ АНАЛИЗСинтаксический анализ - вторая фаза компиляции. На этом этапе программа работает с последовательностью токенов, созданной лексическим анализатором. Синтаксический анализатор, или парсер, должен проверить корректность последовательности токенов для транслируемого языка и на выходе должно получиться промежуточное представление программы.
Также от синтаксического анализатора ожидаются сообщения обо всех выявленных ошибках. В случае корректной программы синтаксический анализатор строит дерево разбора и передает его следующей части компилятора для дальнейшей обработки.

Рисунок 3 - Место синтаксического анализатора в модели компилятора
Существуют различные формы промежуточного представления программы, например, троичный код или абстрактное синтаксическое дерево. В данном случае используется абстрактное синтаксическое дерево.
Методы, обычно применяемые в компиляторах, можно классифицировать как нисходящие (сверху вниз - top-down) или восходящие (снизу вверх - bottom-up). Как следует из названий, нисходящие синтаксические анализаторы строят дерево разбора от корня и листьям, тогда как восходящие начинают с листьев и идут к корню. В обоих случаях входной поток синтаксического анализатора сканируется посимвольно слева направо.
Наиболее эффективные нисходящие и восходящие методы работают только с подклассами грамматик, однако некоторые из этих классов, такие как LL- и LR-грамматики, достаточно выразительны для описания основных синтаксических конструкций языков программирования. Реализованные вручную синтаксические анализаторы чаще работают с LL-грамматиками; например, предикативный подход работает с LL-грамматиками. Синтаксические анализаторы для большего класса LR-грамматик обычно создаются с помощью автоматизированных инструментов.
Выходом синтаксического анализатора является некоторое представление дерева разбора потока токенов от лексического анализатора. На практике имеется множество задач, которые могут сопровождать процесс разбора, такие как сбор информации о различных токенах в таблицу символов, выполнение проверки типов и других видов семантического анализа, а также генерация промежуточного кода.
Алгоритм работы синтаксического анализатора.
Создана структура TLexeme, переменная curr_par типа cell, в нее записываются данные из массива, который передает лексический анализатор. Из переменной curr_cell данные переписываются в массив Lexemes. Дальше работаем только с массивом Lexemes.
struct TLexeme{ String type; //тип токенаbody; //сам токенposition; //строка
};* Lexemes; // Найденные лексемы: тип, тело, строкаcurr_par; //объект структуры (сама структура в 1.h)
int Number = Form1->scaner_result.size(); //передаем количество лексем= new TLexeme [Number]; //нейденные лексемы(int i=0, j=0; i<Number; i++)
{ //в "строку" перемещаем данные из БОЛЬШОГО массива
curr_par=Form1->scaner_result[j];
//сразу записываем в новый
Lexemes[j].type=curr_par.type;
Lexemes[j].body=curr_par.value;[j].position=curr_par.str;++;
}
Дальше по циклу проверяем принадлежность лексемы к какой-либо синтаксической конструкции.
Если лексема принадлежит конструкции, записываем ее в корень, получаем необходимые параметры, для тела, если это цикл, структура, функция (т.е. для того, что в {}) вызывается рекурсия.
if (Lexemes[i].body=="struct")
{ add_tabs(dest,tabs);<<"struct"<<'\n';++; i++;(Lexemes[i].type=="Идентификатор")
{ add_tabs(dest,tabs);<<"Имя"<<'\n';++;_tabs(dest,tabs);<<Lexemes[i].body.c_str()<<'\n';++; tabs--;
}_tabs(dest,tabs);<<"{}"<<'\n';(Lexemes[i].body=="{")
{ //i++;
i=MakeBinTree(dest,tabs,tabs,i,1,"@#$%^&(",tecFN); //вызов рекурсии для того, что в {}++;
//tabs--;
}(Lexemes[i].type=="Идентификатор") //18:48 добавила условие, чтобы выводились объекты структуры
{ while (Lexemes[i].type=="Идентификатор" || Lexemes[i].body==",")
{ if (Lexemes[i].type=="Идентификатор")
{ add_tabs(dest,tabs);<<Lexemes[i].body.c_str()<<'\n';
}++;
}
}-;
}
Изначально дерево записывается в текстовый файл, как только программа анализирует весь массив, данные из текстового файла загружаются в объект TreeView.
Для записи объекта в текстовый файл используется функция add_tabs.
void add_tabs(ofstream &dest,int tabs)
{ //передаю уровень, иду по циклу ставлю табуляцию
for(int j=0;j<tabs;j++)
dest<<'\t';
}
В результате разбора строится синтаксическое дерево (рис. 4).
Синтаксические ошибки включают неверно поставленные точки с запятой или лишние недостающие скобки, отсутствие условий (для оператора while), отсутствие тела (switch, while, do while), неверное количесво параметров (for), неопределенный тип (если переменная не была объявлена).

Рисунок 4 - Результат работы синтаксического анализатора

Рисунок 5 - Результат работы синтаксического анализатора
с найденными ошибками

4 СЕМАНТИЧЕСКИЙ АНАЛИЗСемантический анализ - третья фаза компиляции. Так как на этапе синтаксического анализа нет достаточной информации о типах, парсер проверяет лишь формальную корректность последовательности токенов. Задача семантического анализа состоит в том, чтобы сконструировать пользовательские типы и проконтролировать соответствие типов в программе. В случае, когда типы не совпадают, но возможно неявное приведение, семантический анализатор должен встроить функции приведения типов в абстрактное синтаксическое дерево, полученное на входе.
Так как по факту выполняется не что иное, как обход дерева, семантический анализ реализуется набором рекурсивных функций для обхода блоков, абстрактного синтаксического дерева и для проверки корректности типа данных «Запись», так как он тоже имеет древовидную структуру.

Рисунок 6 - Построение таблицы идентификаторов

5 ОПТИМИЗАЦИЯСуществуют различные методы машинно-зависимой и машинно-независимой оптимизации кода. Они могут применяться на всех синтаксических уровнях. Одним из простейших методов является «размножение констант». При его применении любая ссылка на константное значение замещается самим значением. В следующем примере повышается эффективность благодаря удалению трех адресных ссылок и замене их константами:
x = 2;
if( a
x = y;
if(a 10)
a[y*3] = 0;
Выделение этих выражений приводит к логически эквивалентному тексту:
T1 = y*3;
A1 = &a[T1];
A2 = &b[T1];
if( *A1 10)
*A1 = 0;
Выделение общих подвыражений обычно происходит внутри оператора или блока. «Глубокое выделение общих подвыражений» является более сложным и перекрывает базовые блоки. Выделение общего подвыражения, y*3, в операторе:
if(a == 0)
a = y * 3;
else b = y * 3;
приводит к логическому эквиваленту:
T1 = y * 3;
if(a == 0)
a = T1;
else b = T1;
«Снижение мощности» подразумевает замещение операций, которые требуют большего времени выполнения, более быстрыми.
Компилятор может применять снижение мощности несколькими способами. Например, применяя снижение мощности к сгенерированному коду, компилятор может подменять операции, которые умножают или делят целые числа на степени двойки, операциями сдвига.
«Удаление недостижимого кода» - еще один метод оптимизации. Недостижимый код - это некоторая последовательность инструкций программы, которая недостижима ни по одному пути в программе. Он может образоваться как следствие предыдущих операций оптимизации, кода условной отладки, или частых изменений программы многими программистами. Следующие операторы - это вариант кода для проверки компилятора на выполнение этого метода оптимизации.
#define DEBUG 0
if(DEBUG)
printf("Debug Function\n");
Манифестные константы часто могут скрывать существование
недостижимого кода, особенно если такой код определяется внутри
включаемого файла-заголовка.
«Удаление лишних присваиваний» включает нахождение промежутка жизни переменной и удаление присваиваний этой переменной, если эти присваивания не могут изменить логику программы. Этот метод освобождает ограниченные ресурсы, такие как пространство стека или машинные регистры.
В следующей последовательности команд:
a = 5;
b = 0;
a = b;
первый оператор есть лишнее присваивание и может быть удален безопасно. Лишние присваивания могут возникать непреднамеренно, когда промежуток жизни переменной велик и между вхождениями переменной имеется более-менее длинный код. Лишние присваивания могут быть также результатом предыдущих проходов оптимизации.
Оптимизация - не панацея, и ее применение не бесплатное. В зависимости от степени оптимизации время, требуемое для компиляции программы, может значительно возрастать. Для небольших программ требуемое время можно не принимать во внимание, но для больших оно может иметь значение.
Оптимизация также может усложнить отладку вследствие генерации кода, который трудно непосредственно связать с исходными операторами в программе. Оптимизация может неожиданно ввести ошибки в код, сгенерированный из вполне правильного текста программы. Ситуация, когда на переменную ссылаются как непосредственно по имени, так и посредством одного или нескольких указателей, может затруднить работу компилятора по
определению того, «жива» ли еще переменная и, следовательно, должна оставаться в регистре, или она «умерла» и тогда должна быть сохранена в памяти.
Вынесение инвариантного кода может быть потенциальным источником ошибок.

6 ГЕНЕРАЦИЯ КОДАВ SystemView имеется возможность генерировать исходный код на языке Си для отдельных элементов схемы, части схемы или полной схемы, используя встроенную утилиту C-Code Generator. Утилита C-Code Generator может быть использована также с Real-Time DSP Architect (RTDA) (связь с цифровыми сигнальными процессорами Texas Instruments) для обеспечения аппаратно-программного моделирования плат Evaluation Module (EVM) или DSP Starter Kit (DSK).
Генерируемый код полностью функционален, содержит команды для каждого из элементов SystemView, и при необходимости может включать в себя основную управляющую программу, которая осуществляет планирование работы системы и обработку данных, передаваемых от элемента к элементу. Создаваемые программы эффективны, учитывают установки параметров пользователя и имеют наглядные названия переменных.
Для создания исходного кода воспользуемся примером узкополосного модулятора GMSK (Gaussian Minimum Shift Keying — Гауссовская манипуляция с минимальным частотным сдвигом), построенного с использованием элементов из библиотеки DSP. С помощью курсора выделим элементы, для которых мы хотим сгенерировать исходный код. После выделения интересующих элементов следует выбрать пункт Code Generator из меню Tools, или просто щелкнуть правой кнопкой мыши и выбрать Code Generator (рис. 7).

Рисунок 7 - Пример узкополосного модулятора GMSK (пунктиром выделены элементы, для которых создаются коды на языке Си)
После этого появится показанное на рис. 8 диалоговое окно C-Code Generator, отображающее различные опции для создания исходного кода.

Рисунок 8 - Диалоговое окно C-Code GeneratorДанное диалоговое окно позволяет пользователю произвести организацию процесса генерации кода за 5 шагов:
выбрать заданный процессор;
выбрать тип оболочки для генерируемого кода;
установить размер буфера обработки;
выбрать элементы, исходный код которых следует поместить во внутреннюю часть программы управления;
выбрать директорию для размещения созданного кода.
На первом шаге задается тип процессора, на котором будет использоваться сгенерированный код. Имеются предварительно заданные опции для TI C6x и TI C5x, а также 32-разрядные конструкции Windows. Также обеспечиваются пользовательские настройки, в которых можно задать форматы представления данных для той базовой системы, которая будет использоваться. При использовании пользовательских опций генерация кода может быть выполнена для вычислительной машины практически любой конфигурации.
Если воспользоваться пользовательской опцией (Custom) и щелкнуть по кнопке Define, откроется диалоговое окно, с помощью которого задаются форматы данных, обеспечивающие совместимость с конфигурацией выбранной вычислительной машины (рис. 9).

Рисунок 9 - Диалоговое окно Custom Processor Definition
После определения типа процессора следует указать, какая оболочка, если таковая вообще имеется, требуется для функционирования генерируемого кода. От этого зависит, в каком виде он будет представлен. Code Generator позволяет создать три уровня кодов для выбранных элементов. Нижний уровень — код для отдельных элементов. Следующий уровень — это программа, которая управляет элементами и обменом данными между ними. Оболочка — высший уровень, который обеспечивает внешний интерфейс для управляющей программы. Пользователь имеет возможность выбрать одну из опций для оболочки, включая отсутствие оболочки, или создание стандартных программ для каждого элемента в отдельности без управляющей программы.
На третьем шаге в процессе генерации кода требуется выбрать минимальный размер буфера для обработки данных в выбранной подсистеме. Число, показанное в нижней части окна редактирования — это минимальное число входных отсчетов, которые могут быть обработаны созданной программой одновременно. Если у выбранного элемента имеется больше, чем один вход, число должно соответствовать размеру наименьшего входного буфера. Размеры других входных буферов будут изменены соответственно. Пользователь может увеличивать масштаб минимального размера буфера, задавая масштабный коэффициент в виде целого числа. Новый размер буфера будет отражен в созданном коде.
На четвертом шаге требуется указать, какие из выбранных элементов, если таковые вообще имеются, должны быть помещены во внутреннюю часть управляющей программы. Если щелкнуть по кнопке Select Inline в диалоговом окне C-Code Generator, откроется окно Inline Code Selection (рис. 10).

Рисунок 10 - Диалоговое окно Inline Code Selection
По умолчанию, для каждого отдельного элемента создается код, который помещается в отдельный файл. При наличии галочки, расположенной рядом с соответствующим элементом, код функционального элемента будет помещен внутри управляющей программы и отдельный файл для него создан не будет.
На пятом шаге в подготовке к созданию исходного кода выбирается директория, в которую он будет помещен. Как только директория будет выбрана, щелкните OK — генератор создаст необходимые файлы и поместит их в эту директорию.
Мы выберем элементы из нашей системы GMSK и создадим код для базовой системы Windows (x86), выбрав SystemView Custom Token как принятый тип оболочки. После выбора директории и щелчка по кнопке OK появится сообщение об успешном завершении процедуры генерации кода (рис. 11).

Рисунок 11 - Сообщение об успешном завершении генерации кодов
Информация о состоянии процесса создания программы после каждого шага записывается в системный журнал. Файл журнала помещается в директорию, куда производится запись генерируемого Си-кода, и имеет расширение .log.
Любые проблемы, которые возникают в процессе создания программы, могут быть исследованы при условии определения, в каком именно элементе произошел сбой. Директория (рис. 12) содержит перечень файлов, созданных генератором кода. Созданный для каждого элемента файл заголовка (header file) включает перечень, содержащий необходимые для элемента прототипы функций и определения структур.

Рисунок 12 - Перечень файлов, созданных генератором кода
В процессе генерации кода помимо файлов, содержащих исходный код для элемента (<элемент>.c), будут при необходимости созданы файлы, задающие начальные условия выполнения (<элемент>_init.c) и файлы указателей (<элемент>_ptr.c) для обмена данными, в случае, если данный элемент не был включен в основную управляющую программу.
Главная управляющая программа разделена на семь файлов. Каждый имеет в качестве приставки название моделируемой схемы в SystemView (в нашем примере это «GMSK»). Заголовочные «GMSK» файлы содержат информацию о распределении динамической и постоянной памяти, необходимой для каждого элемента.
В приложении В приведен листинг основной управляющей программы GMSK.C.

ЗАКЛЮЧЕНИЕВ процессе работы над курсовой были получены знания и навыки о поэтапной разработке компилятора, навык составления таблицы лексем для распознавания и формирования лексем языка. Разработано программное средство, реализующее лексический анализ текста программы на языке Си.
В данной курсовой работе были реализованы следующие фазы компиляции:
1) лексический анализ результатом, которого является таблица токенов;
2) синтаксический анализ результатом, которого может быть дерево разбора в случае корректности анализируемого кода;
3) построена таблица идентификаторов;
4) оптимизация;
5) генерация кода.
Реализованное приложение позволяет анализировать файлы с расширением и *.cpp, *.h, *.c, *.hpp.
Для реализации компилятора был выбран не самый оптимальный метод, т.к. уже существует множество различных генераторов лексического и синтаксического анализа, использование которых позволяет сократить время и повысить эффективность.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ1. Альфред, В. Ахо Компиляторы. Принципы, технологии и инструментарий / Альфред В. Ахо и др. - М.: Вильямс, 2015. - 781 c.
2. Дьюхарст Программирование на C++ / Дьюхарст, Старк Стефан; , Кэти. - М.: ДиаСофт, 2015. - 272 c.
3. Кетков, Юлий Практика программирования: Visual Basic, C++ Builder, Delphi. Самоучитель (+ дискета) / Юлий Кетков , Александр Кетков. - М.: БХВ-Петербург, 2016. - 464 c.
4. Мейерс, Скотт Эффективный и современный С++. 42 рекомендации по использованию C++11 и C++14 / Скотт Мейерс. - М.: Вильямс, 2015. - 304 c.
5. Панюкова, Т. А. Языки и методы программирования. Создание простых GUI-приложений с помощью Visual С++. Учебное пособие / Т.А. Панюкова, А.В. Панюков. - М.: Либроком, 2015. - 144 c.
6. Поляков, А. Методы и алгоритмы компьютерной графики в примерах на Visual C++ / А. Поляков. - М.: БХВ-Петербург, 2017. - 416 c.
7. Понамарев, Вячеслав Программирование на C++/C# в Visual Studio .NET 2003 / Вячеслав Понамарев. - М.: БХВ-Петербург, 2013. - 352 c.
8. Сафонов, В. О. Параметризованные типы данных. История, теория, реализация и применение / В.О. Сафонов. - М.: Издательство Санкт-Петербургского университета, 2013. - 116 c.
9. Секунов, Н.Ю. Самоучитель Visual C++ 6.0 / Н.Ю. Секунов. - М.: СПб: BHV, 2014. - 960 c.
10. Страуструп, Б. Язык программирования C++ / Б. Страуструп. - М.: Радио и связь, 2011. - 350 c.
11. Страуструп, Бьерн Дизайн и эволюция С++ / Бьерн Страуструп. - М.: ДМК Пресс, 2016. - 446 c.
12. Фридман, А. C/C++. Архив программ / А. Фридман, Л. Кландер, М. Михаэлис, и др.. - М.: ЗАО Издательство БИНОМ, 2016. - 640 c.
13. Халперн Стандартная библиотека С++ / Халперн, Пабло. - М.: Вильямс, 2014. - 336 c.
14. Хьюз, Камерон Параллельное и распределенное программирование с использованием C++: моногр. / Камерон Хьюз , Трейси Хьюз. - М.: Вильямс, 2016. - 672 c.
15. Шнайер, Брюс Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си / Брюс Шнайер. - М.: Триумф, 2012. - 816 c.
16. Ахо, Лам, Сети, Ульман. Компиляторы: принципы, технологии и инструментарий, 2-е изд.: Пер. с англ. - М.: ООО «И.Д. Вильямс», 2008. - 184 с.

ПРИЛОЖЕНИЕ АТекст тестовой программы для проверки корректности работы лексического анализатора.
#include<math.h>
/*fbdfbdfbdfbdf fhdfh/* fdhfghf*/
//------------main(){const n=34u, m=12LU;l=12.6f, t=23.6L;u=11e-10f;a=0012, b=0xabcd, c=-12; float d=07;
a=12.11, t=12e2, u=-0.23e-12;
a='a', t='\0' , v='\123', k='\xab';
t[]="gfbfgnf\t\"""hmnghjmh\" ;
&=
>>=0;
}
Текст тестовой программы для проверки корректности работы синтаксического анализатора.
#include <iostream.h>
//testRET {red, green=1}main (int s, double z)
{ int a,b=4,c=0,d=121, q;=10;((a+b* c)<10 && c<c+a*b || a !=-d)
{ for (int i=0; i<5; i++)
{ q+=1;{++a;}(b+a<20)
}
}
/*/*olololo*/(a<10)(b>10 && b<15)
{ int s=b; }s=a; s;
}
//---------------------
ПРИЛОЖЕНИЕ БХранение лексем
bool Punkt::operator() (const AnsiString s)
{ return find(punkt.begin(),punkt.end(),s)!=punkt.end();
}::Punkt()
{ punkt.push_back("...");punkt.push_back(";");.push_back(":"); punkt.push_back(",");
Проверка на принадлежность
if (ISpunkt(sym_table[i].chr))
{ int len=0;_cell.str=sym_table[i].str;_cell.sym=sym_table[i].sym;_cell.pos=pos;="";{curr+=sym_table[i++].chr; len++; pos++;}(ISpunkt(sym_table[i].chr));(ISpunkt(curr))_cell.type="Пунктуатор";_cell.value=curr;_cell.len=len;.push_back(curr_cell);--;
continue;
}
Функция проверяет на наличие арифметических операций в выражении
int if_there_arifmetic_ops(long ii)
{ TLexeme* Lexemes; // Найденные лексемы: тип, тело, строка
cell curr_par; //объект структуры (сама структура в 1.h)
int Number=Form1->scaner_result.size();= new TLexeme [Number]; //нейденные лексемы(int t=0, j=0; t<Number; t++)
{ //в "строку" перемещаем данные из БОЛЬШОГО массива
curr_par=Form1->scaner_result[j];
//сразу записываем в новый
Lexemes[j].type=curr_par.type;
Lexemes[j].body=curr_par.value;[j].position=curr_par.str;++;
}f=0;i;cs=0;//Счет скобок(i=ii;i<Number;i++)
{ if(Lexemes[i].body==";" || Lexemes[i].body=="," ) break;(Lexemes[i].body=="&&" || Lexemes[i].body=="||" || Lexemes[i].body=="<" || Lexemes[i].body==">"
|| Lexemes[i].body=="!=" || Lexemes[i].body=="==" || Lexemes[i].body=="<=" || Lexemes[i].body==">=") break;(Lexemes[i].body=="(") cs++;(Lexemes[i].body==")") cs--;(cs<0) break;(Lexemes[i].body=="+" || Lexemes[i].body=="-" || Lexemes[i].body=="*" || Lexemes[i].body=="/" || Lexemes[i].body=="^")=1;
}f;[]Lexemes;
}

ПРИЛОЖЕНИЕ ВЛистинг основной управляющей программы GMSK.C.