Текст книги "Системное программное обеспечение. Лабораторный практикум"

Задание на курсовую работу

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

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

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

• входная программа начинается ключевым словом prog (program) и заканчивается ключевым словом end.;

• входная программа может быть разбита на строки произвольным образом, все пробелы и переводы строки должны игнорироваться компилятором;

• текст входной программы может содержать комментарии любой длины, которые должны игнорироваться компилятором (вид комментария задан в варианте задания);

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

• должны быть предусмотрены следующие варианты операторов входной программы:

– оператор присваивания вида <переменная>:=<выражение>;

– условный оператор вида if <выражение> then <оператор> либо if <выражение> then <оператор> else <оператор>;

– составной оператор вида begin… end;

– оператор цикла, предусмотренный вариантом задания;

• выражения в операторах могут содержать следующие операции (минимум):

– арифметические операции сложения (+) и вычитания (-);

– операции сравнения «меньше» (<), «больше» (>), «равно» (=);

– логические операции И (and), ИЛИ (or), НЕ (not);

– дополнительные арифметические операции, предусмотренные вариантом задания;

• операндами в выражениях могут выступать идентификаторы (переменные) и константы (тип допустимых констант указан в варианте задания);

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

• должны учитываться два предопределенных идентификатора InpVar и Compi 1 eTest, смысл которых будет ясен из приводимого далее описания выходного языка.

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

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

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

• не допускается присвоение значений константам;

• не допускается присвоение значения идентификатору InpVar;

• не допускается использовать идентификатор Compi 1 eTest, иначе как для присвоения ему значений.

В качестве выходного (результирующего) языка должен использоваться язык ассемблера процессоров типа Intel 80x86 в модификации встроенного языка ассемблера компилятора Pascal производства фирмы Borland.

Результирующая программа должна иметь следующий вид:

Prog <Имя_программы>;

{Имя программы выбирается исполнителем самостоятельно}

Var InpVar: <Тип_данных>;

{Тип данных указан в варианте задания}

Var <Список_переменных>: <Тип_данных>;

{Список переменных должен содержать перечень

всех переменных из исходной программы}

Function CompileTest(InpVar: <Тип_данных>): <Тип_данных>;

{Переменные CompileTest и InpVar являются предопределенными

в тексте исходной программы}

Begin

Asm

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

порожденный компилятором}

end;

end;

begin

readln(InpVar);

writeln(CompileTest(InpVar));

end.

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

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

Тип данных, используемый для всех переменных, задается в варианте задания.

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

Варианты заданий

Предлагаемые варианты заданий приведены в табл. 5.2.

Таблица 5.2. Варианты заданий на выполнение курсовой работы

Ниже поясняются цифровые обозначения, используемые в табл. 5.2. Типы констант:

2 – двоичные;

8 – восьмеричные;

16 – шестнадцатеричные.

Дополнительные операции:

*, / – умножение и деление;

>> << – сдвиги вправо и влево (арифметические или логические – по выбору);

++ – инкремент (увеличение значения переменной на 1);

– декремент (уменьшение значения переменной на 1).

Типы дополнительных операторов цикла:

1. Цикл с предусловием вида while <выражение> do <оператор>.

2. Цикл с постусловием типа repeat <оператор> until <выражение>.

3. Цикл с постусловием вида do <оператор> while <выражение>.

4. Два варианта цикла с перечислением по заданной переменной вида for <переменная>:=<выражение> to <выражение> do <оператор> либо for <переменная>:=<выражение> downto <выражение> do <оператор>.

Типы комментариев:

1. Комментарий в фигурных скобках: {…}.

2. Комментарий в круглых скобках со звездочкой: (*…*).

3. Комментарий за двойной косой чертой до конца строки: //….

4. Комментарий внутри косых черт со звездочкой: /*…*/.

Методы оптимизации:

1. Исключение лишних операций.

2. Свертка объектного кода.

Порядок оценки результатов работы

Выполненная курсовая работа оценивается по следующим показателям:

• содержание пояснительной записки;

• функциональность построенного компилятора;

• способность исполнителя отвечать на вопросы по содержанию пояснительной записки и по сути работы.

Текст пояснительной записки должен удовлетворять требованиям ГОСТ и стандартов университета. Содержание пояснительной записки должно удовлетворять требованиям настоящего задания на выполнение курсовой работы.

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

Функциональность компилятора в первую очередь оценивается по заданным минимальным требованиям и по работоспособности компилятора (отсутствие «зависаний» и нерегламентированных сообщений об ошибках при любых входных данных).

Дополнительные бонусы при оценке компилятора могут быть получены за следующие расширения заданной минимальной функциональности:

• реализация дополнительных ключей и параметров управления работой компилятора;

• наличие у компилятора дополнительного интерактивного интерфейса с пользователем;

• эффективная («сокращенная») обработка логических операций и операций сравнения (метод ее реализации описан в примере выполнения лабораторной работы № 4 в части, посвященной описанию генератора кода и схем СУ-перевода);

• реализация дополнительных операторов и операций входного языка. В качестве наиболее очевидного расширения входного языка предлагается реализовать оператор выхода из цикла (break) и перехода к следующей итерации цикла (continue);

• дополнительный семантический контроль входной программы;

• любые дополнительные методы оптимизации результирующей программы (как машинно-независимые, так и машинно-зависимые);

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

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

Дополнительные бонусы не учитываются и не засчитываются, если не реализована минимальная функциональность компилятора, предусмотренная вариантом задания.

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

Рекомендации по выполнению работы

В любом случае при знакомстве с примером выполнения работы и при выполнении работы по своему заданию надо обратить внимание на следующие основные моменты:

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

2. Выполняющий курсовую работу должен решить для себя, как он будет строить лексический и синтаксический анализаторы: самостоятельно (вручную) или автоматизированным методом (с использованием специализированного ПО – рекомендуются программы LEX и YACC). Автоматизированный метод проще и быстрее, но требует от автора работы времени на освоение специализированного программного обеспечения. Возможно сочетать оба метода: например, построить лексический анализатор с помощью программы LEX (она достаточно проста в использовании), а синтаксический анализатор – вручную. Рекомендации на этот счет каждый должен выбрать, оценив свои силы в возможности освоения нового программного обеспечения.

3. Создание лексического анализатора – это этап, не представляющий особой сложности, так как построение КА для лексического анализатора представляет собой полностью формализованный процесс (при выполнении которого в первую очередь важна внимательность). Но при выполнении этого этапа главная задача не в том, чтобы грамотно построить КА – в этом, чаще всего, нет проблем, – а в том, чтобы максимально эффективно разделить анализ, выполняемый лексическим анализатором, и анализ, выполняемый анализатором синтаксическим. Как правило, чем больше работы выполняет лексический анализатор, тем лучше. Уже построив грамматику языка, нужно иметь представление о том, какие элементы языка будут выделяться на этапе лексического анализа.

4. Выбор класса КС-грамматики для создания синтаксического анализатора – это, с точки зрения автора, второй по важности этап после построения грамматики. Задание составлено так, что любой входной язык может быть задан грамматиками, анализируемыми по крайней мере тремя методами: методом рекурсивного спуска (или же ХХ(1) – грамматикой), методом на основе грамматик операторного предшествования и методом на основе LR(1) или LALR(1) – грамматик. Важно построить грамматику входного языка так, чтобы она соответствовала интересующему методу, или же уметь преобразовать ее к требуемому виду. К сожалению, тут нет формализованных рекомендаций. Самый простой подход – взять для описания грамматики языка приемы и правила, рассмотренные при выполнении лабораторной работы № 3, тогда для построения синтаксического распознавателя с большой вероятностью подойдет метод на основе грамматик операторного предшествования.

5. Выбор формы внутреннего представления программы, методов оптимизации и генерации результирующего кода – это взаимозависимые процессы. Поскольку рассмотренные ранее методы и алгоритмы были основаны на использовании триад, автор не рекомендует пытаться использовать другие формы внутреннего представления.

Необходимую дополнительную информацию можно найти в литературе по компиляторам и системам программирования [1–4, 7].

Пример выполнения курсовой работы

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

Многие методы, технические приемы и их реализация в курсовой работе будут взяты из лабораторных работ № 1–4, которые были рассмотрены ранее. Другие методы, наоборот, будут реализованы иначе, чтобы проиллюстрировать все существующие возможности, их преимущества и недостатки. В каждом случае будет дано пояснение, почему использован тот или иной метод.

В примере проиллюстрированы следующие интересные моменты:

• разделение лексического и синтаксического анализаторов с целью упрощения работы последнего (на примере унарной арифметической операции «-» и операции сравнения типа «не равно»);

• обнаружение присваивания значений константам на этапе синтаксического разбора (в лабораторных работах № 3 и 4 эта же операция выполнялась на этапе семантического анализа перед генерацией кода);

• возможности преобразования исходной грамматики, изменения синтаксиса входного языка и модификации алгоритма синтаксического разбора на основе анализа правил грамматики (на примере условного оператора);

• модификация остовной грамматики при необходимости различать правила;

• методы обработки логических операций и операций сравнения;

• простейший семантический анализ и модификация результирующего кода на этапе семантического анализа (на примере обработки переменных InpVar и CornpileTest);

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

Для реализации курсовой работы будут использоваться программные модули, созданные при выполнении лабораторных работ № 1–4, код которых не зависит от входного языка. Такой подход иллюстрирует, насколько удобно и эффективно выделять не зависящую от входного языка часть компилятора в отдельные модули или библиотеки.

Задание для примера выполнения работы

В качестве примера возьмем следующие условия для входного языка:

1. Тип допустимых констант: десятичные.

2. Дополнительная операция: унарный арифметический минус (-).

3. Оператор цикла: while (<выражение>) do <оператор>.

4. Оптимизация: оба метода (1 и 2).

5. Тип данных: Long integer (longint, 32 бит).

6. Тип комментария: фигурные скобки ({… }).

Кроме того, модифицируем синтаксис условного оператора (два типа):

• if (<выражение>) <оператор> else <оператор>;

• if (<выражение>) <оператор>;

и дополним перечень операций сравнения операцией «не равно» (<>).

Получим входной язык, сочетающий в себе элементы синтаксиса языков C++ (элементы оператора цикла и условный оператор) и Object Pascal (оператор цикла, составной оператор begin… end, оператор присваивания и комментарии).

В качестве результирующего (выходного) языка компилятора будем использовать язык ассемблера процессоров типа Intel 80386 и более поздних модификаций в модификации для системы программирования Delphi 5 [9, 23, 28, 41, 44]. Чтобы исключить неоднозначности при работе с этой системой программирования, изменим семантические ограничения входного языка:

• сделаем допустимым использование имени переменной CompileTest в любых операторах входного языка (а не только в операторах присваивания);

• запретим использование переменных с именем Result, так как такое имя переменной является предопределенным в целевой вычислительной системе.

Кроме того, в именах переменных во входном языке не должны различаться строчные и прописные буквы (например, переменные с именами i и I должны восприниматься как одна и та же переменная).

Грамматика входного языка

Грамматику входного языка построим на основе фрагментов грамматик, рассмотренных в заданиях по лабораторной работе № 3. Там имеются правила для линейных операций (арифметические и логические операции) и для условного оператора. По аналогии с условным оператором построим оператор цикла. Для составного оператора и всей программы в целом останется определить еще одно понятие – последовательность операторов. Будем рассматривать последовательность операторов как цепочку операторов, разделенных знаком «точка с запятой».

В результате получим КС-грамматику в форме Бэкуса—Наура:

G({prog,end.,if,else, begin, end,while, do, or,xor,and,not,<,>,=, <>, (,), – ,+,um,a,c,=},

{S,L, 0,B,C,D,E, T,F},P,S)

с правилами P:

S → prog L end.

L → О | L;0 | L;

О → if(B) О else О | if(B) О | begin L end | while(B)do О | a:=E

В → В or С | В xor С | С

С → С and D | D

D → E<E | E>E | E=E | E<>E | (В) | not(B)

E → E-T | E+T | T

T → um T | F

F → (E) | a | с

Жирным шрифтом выделены терминальные символы.

Всего в построенной грамматике G 28 правил. Нетерминальные символы грамматики имеют следующий смысл:

• S вся программа;

• L последовательность операторов (может состоять и из одного оператора);

• О – оператор (пять видов: полный условный оператор, неполный условный оператор, составной оператор, оператор цикла, оператор присваивания);

• В, С – логическое выражение и его элементы;

• D операция сравнения или логическое выражение в скобках;

• Е,Т, F – арифметическое выражение и его элементы.

Можно обратить внимание на следующие моменты в грамматике:

• операция um («унарный минус») обозначена отдельным терминальным символом, не совпадающим со знаком арифметической операции вычитания («-»), хотя в тексте исходной программы эти два символа идентичны;

• константы и переменные обозначены двумя различными терминальными символами – а и с соответственно – это говорит о том, что они должны различаться на этапе синтаксического анализа;

• операция отрицания not обязательно требует после себя выражения в скобках, что не совсем соответствует традиционной записи логических операций (но не противоречит заданию!), традиционная запись могла бы быть записана в виде правил:

D → not D | G

G → E<E | E>E | E=E | E<>E | (B)

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

Описание выбранного способа организации таблицы идентификаторов

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

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

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

Описание лексического анализатора

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

Задача лексического анализатора для описанного выше языка заключается в том, чтобы распознавать и выделять в исходном тексте программы все лексемы этого языка. Лексемами данного языка являются:

• двенадцать ключевых слов языка (prog, end., if, else, begin, end, while, end, not, or, xor и and);

• разделители: открывающая и закрывающая круглые скобки, точка с запятой;

• знаки операций: присваивание, сравнение (четыре знака), сложение, вычитание и унарный минус;

• идентификаторы;

• целые десятичные константы без знака.

Можно заметить, что end и end. – это разные лексемы.

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

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

Если не делать различий между унарным минусом и бинарным, то правила грамматики G для символов E, T и F имели бы следующий вид:

E → E—T | E+T | T

T → —T | F

F → (E) | a | c

Однако такая грамматика будет очень сложна для синтаксического анализа, поскольку в ней возникает проблема выбора правила между E—T и – T при выполнении свертки (можно проверить и прийти к выводу, что она, например, не является грамматикой операторного предшествования). Преобразования для этой грамматики неочевидны.

Но возможно более простое решение, если понять, как различить две операции (унарный и бинарный знаки «минус») на этапе лексического анализа. Различие можно сделать, если заметить, что бинарный минус всегда следует после операнда (переменной или константы) или после закрывающей круглой скобки, в то время как унарный минус – или после знака операции, или после открывающей круглой скобки. Такой анализ вполне по силам КА, если в него добавить еще одно состояние, которое будет определять, какую лексему (унарный или бинарный минус) сопоставлять с входным символом «—». Поскольку перед унарным минусом, как и перед любыми другими лексемами, может быть комментарий, то придется добавить два состояния (чтобы различать, в каком месте КА встретилось начало комментария, и после завершения комментария вернуться в то же место).

Таким образом, незначительное усложнение КА лексического анализатора позволит избежать серьезных проблем на этапе синтаксического анализа.

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

Другой пример из заданного входного языка еще более очевиден, хотя он и не ведет к столь серьезным осложнениям при лексическом разборе: это знак операции «не равно» – «<>». Его можно рассматривать как две лексемы или как одну. В первом случае проверка правильности этой операции будет идти на этапе синтаксического анализа, во втором случае – на этапе лексического анализа. Оба варианта могут быть без проблем реализованы, но второй из них представляется все же более логичным.

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

Например, в том же входном языке сочетания if(и while(могут быть рассмотрены как единые лексемы (обозначим их if_ и w_l) и выявлены на этапе лексического анализа. При этом синтаксический анализатор не получает никаких преимуществ, но правила грамматики для нетерминального символа будут иметь вид:

О → if_ В) О else О | if_ В) О | begin L end | w_l B)do О | а:=Е

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

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

Приняв во внимание правила и соглашения, рассмотренные для КА в лабораторной работе № 2, полностью КА можно описать следующим образом:

M(Q,Σ,δ,q₀,F):

Q = {H, C, C1, G, S, L, V, D, P1, P2, P3, P4, E1, E2, E3, I1, I2, L2, L3, L4, B1, B2, B3, B4,

B5, W1, W2, W3, W4, W5, O1, O2, D1, D2, X1, X2, X3, A1, A2, A3, N1, N2, N3, F};

Σ = А (все допустимые алфавитно-цифровые символы);

q₀ = H;

F = {F, S}.

Функция переходов (δ) для этого КА приведена в приложении 2.

Из начального состояния КА литеры «p», «e», «i», «b», «w», «o», «x», «a» и «n» ведут в начало цепочек состояний, каждая из которых соответствует ключевому слову (цепочка, начинающаяся с «e», соответствует трем ключевым словам):

• состояния P1, P2, P3, P4 – ключевому слову prog;

• состояния E1, E2, E3 – ключевым словам end и end.;

• состояния I1, I2 – ключевому слову if;

• состояния B1, B2, B3, B4, B5 – ключевому слову begin;

• состояния W1, W2, W3, W4, B5 – ключевому слову while;

• состояния E1, L2, L3, L4 – ключевому слову else;

• состояния D1, D2 – ключевому слову do;

• состояния O1, O2 – ключевому слову or;

• состояния X1, X2, X3 – ключевому слову хог;

• состояния A1, A2, A3 – ключевому слову and;

• состояния N1, N2, N3 – ключевому слову not.

Остальные литеры ведут к состоянию, соответствующему переменной (идентификатору) – V. Если в какой-то из цепочек встречается литера, не соответствующая ключевому слову, или цифра, то КА также переходит в состояние V, а если встречается граница лексемы – запоминает уже прочитанную часть ключевого слова как переменную (чтобы правильно выделять такие идентификаторы, как «i» или «els», которые совпадают с началом ключевых слов).

Цифры ведут в состояние, соответствующее входной константе, – D. Открывающая фигурная скобка ведет в состояние C, которое соответствует обнаружению комментария – из этого состояния КА выходит, только если получит на вход закрывающую фигурную скобку. Еще одно состояние – G – соответствует лексеме «знак присваивания». В него КА переходит, получив на вход двоеточие, и ожидает в этом состоянии символа «равенство».

Рис. 5.1. Граф переходов сокращенного КА (без учета ключевых слов).

Знаки арифметических операций («+» и «—»), знаки операций сравнения («<.», «.>» и «=.»), открывающая круглая скобка, а также последние символы ключевых слов переводят КА в состояние S, которое отличается от начального состояния тем, что в этом состоянии КА воспринимает символ «—» как знак унарной операции отрицания, а не как знак операции вычитания. Если в состоянии S на вход КА поступает открывающая фигурная скобка, то он переходит в состояние C1 (а не в состояние C), из которого по закрывающей фигурной скобке опять возвращается в состояние S.

В еще одно состояние – состояние L – КА переходит, когда на его вход поступает знак «<.». В состоянии L автомат проверяет, является ли знак «<.» началом лексемы «<>» («неравно») или же это отдельная лексема «<.» («меньше»).

Состояние H – начальное состояние КА, а состояния F и S – его конечные состояния. Поскольку КА работает с непрерывным потоком лексем, перейдя в конечное состояние H, он тут же должен возвращаться в начальное состояние, чтобы распознавать очередную лексему. Поэтому в моделирующей программе два состояния (H и F) можно объединить в одно.

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

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

Реализация данного КА выполнена аналогично реализации КА, построенного в лабораторной работе № 2. Для описания структур данных лексем, которые не зависят от входного языка, используется модуль LexElem, который был создан при выполнении лабораторной работы № 2 (листинг П3.4, приложение 3). Типы допустимых лексем описаны в модуле LexType (листинг П3.3, приложение 3), а функционирование автомата моделируется в модуле LexAuto (листинг П3.5, приложение 3).