Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Этот файл был взят с сайта
http://all-ebooks.com
Данный файл представлен исключительно в ознакомительных целях. После ознакомления с содержанием данного файла Вам следует его незамедлительно удалить. Сохраняя данный файл вы несете ответственность в соответствии с законодательством.
Любое коммерческое и иное использование кроме предварительного ознакомления запрещено. Публикация данного документа не преследует за собой никакой коммерческой выгоды.
Эта книга способствует профессиональному росту читателей и является рекламой бумажных изданий. Все авторские права принадлежат их уважаемым владельцам. Если Вы являетесь автором данной книги и её распространение ущемляет Ваши авторские права или если Вы хотите внести изменения в данный документ или опубликовать новую книгу свяжитесь с нами по email.
т А. Ю. Молчанов
СИСТЕМНОЕПРОГРАММНОЕОБЕСПЕЧЕНИ1
С^ППТЕР^
Ч Е БЧ Е Б/ЗОВ
Ч Е Б
Ч Е Б
А. Ю. Молчанов
СИСТЕМНОЕПРОГРАММНОЕОБЕСПЕЧЕНИЕ
Допущено Министерством образования Российской Федерации в качествеучебника для студентов высших учебных заведений, обучающихся
по специальностям «Вычислительные машины, комплексы, системы и сети»и «Автоматизированные системы обработки информации и управления»направления подготовки дипломиэоввтБТГспецйапис]рв^
«Информатика и вычислит^ль^Ятехника».-^県 卜• s
300.piter.com300.piter.com%7汾/
300.piter.com
300.piter.com
БИБЛИОТЕКА
Влали'^йПсгого цугосу«аг"тв^;ногог Aуи^зарс-пета
Издательская программа
300 лучших учебников для высшей школыв честь 300-летия Санкт-Петербургаосуществляется при поддержке Министерства образования РФ
С^ППТЕР^
Москва • Санкт-Петербург • Нижний Новгород • Воронеж • Ростов-на-ДонуЕкатеринбург ■ Самара ■ Киев • Харьков • Минск
2003
BBK 72.973-018я7
УДК 681.3.06(075),
М76
Рецензенты
Немолочнов О. Ф., Зав кафедрой информатики и прикладной математикиСанкт-Петербургского университета информационных технологий,механики и оптики, доктор технических наук, профессор
Яшин А. И., Доктор технических наук, профессор кафедры автоматизированных системобработки информации и управления СПбГЭТУ «ЛЭТИ»
М76 Системное программное обеспечение: Учебник для вузов / А. Ю. Молчанов.— СПб.: Питер, 2003. — 396 с.: ил.
ISBN 5-94723-562-5
В книге рассматриваются основные теоретические принципы и реализующие их технологии, лежащие в основе современных средств разработки программного обеспечения Содержится вся необходимая информация о трансляторах, компиляторах, интерпретаторах, а также о других составляющих систем программирования, начиная от базовых теоретических сведений до современных технологий разработки распределенных программ
Книга ориентирована прежде всего на студентов, обучающихся в технических вузах по специальностям, связанным с вычислительной техникой Но она будет также полезна всем, чья деятельность так или иначе связана с разработкой программного обеспечения Разработчики системных программ могут почерпнуть в ней для себя немало полезных сведений, а прикладные программисты более детально познакомятся с принципами функционирования инструментов, которыми они пользуются, что в любом случае будет способствовать повышению качества создаваемых ими программных средств
Допущено Министерством образования Российской Федерации в качестве учебника для студентов высших учебных заведений, обучающихся по специальностям « Вычи с лительные машины, комплексы, системы и сети» и «Автоматизированные системы обработки информации и управления» направления подготовки дипломированных специалистов «Информатика и вычислительная техника»
ББК72 973-018я7
УДК 681.3.06(075)
Информация содержащаяся в данной книге, получена из источников рассматриваемых издательством как надежные Тем не менее, имея в виду возможные человеческие или технические ошибки издательство не может гарантировать абсолютную
точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги
ISBN 5-94723-562-5ISBN 5-94723-562-5© ЗАО Издательский дом «Питер», 2003
ISBN 5-94723-562-5
ISBN 5-94723-562-5
Краткое содержание
Предисловие 10
Введение 12
Глава 1. Формальные языки и грамматики14
Глава 2. Основные принципы построения трансляторов54
Глава 3. Лексические анализаторы96
Глава 4, Синтаксические анализаторы 144
Глава 5. Генерация и оптимизация кода249
Глава 6. Современные системы программирования327
Указатель литературы386
Алфавитный указатель390
0 2 31110 2 3111
0 2 3
111
0 2 3
111
Содержание
Предисловие
Введение
От издательства
Глава 1- Формальные языки и грамматики
Языки и цепочки символов. Способы задания языков
Цепочки символов. Операции над цепочками символов
Понятие языка. Формальное определение языка
Способы задания языков. Синтаксис и семантика языка
Особенности языков программирования
Грамматики и распознаватели
Формальное определение грамматики. Форма Бзкуса—Наура ..
Принцип рекурсии в правилах грамматики1
Другие способы задания грамматик
Распознаватели. Общая схема распознавателя
Виды распознавателей
Задача разбора
Классификация языков и грамматик
Классификация грамматик. Четыре типа грамматик по Хомскому
Классификация языков
Классификация распознавателей
Примеры классификации языков и грамматик
Цепочки вывода. Сентенциальная форма
Вывод. Цепочки вывода
Сентенциальная форма грамматики. Язык, заданный грамматикой Левосторонний и правосторонний выводы
Дерево вывода. Методы построения дерева вывода
Проблемы однозначности и эквивалентности грамматик
Однозначные и неоднозначные грамматики
Проверка однозначности и эквивалентности грамматик
Правила, задающие неоднозначность в грамматиках
Контрольные вопросы и задачи
Вопросы
4 4 4 8 1355 5 5 6 64 4 4 8 1355 5 5 6 6Глава 2. Основные принципы построения трансляторов ...
4 4 4 8 13
55 5 5 6 6
4 4 4 8 13
55 5 5 6 6
Трансляторы, компиляторы и интерпретаторы — общая схема работы ....
Определения транслятора, компилятора, интерпретатора Этапы трансляции. Общая схема работы транслятора Понятие прохода. Многопроходные и однопроходные компиляторы ...
Современные компиляторы и интерпретаторы Компиляторы с языков высокого уровня Интерпретаторы. Особенности построения интерпретаторов Трансляторы с языка ассемблера («ассемблеры») Макроязыки и макрогенерация
Таблицы идентификаторов. Организация таблиц идентификаторов
Назначение и особенности построения таблиц идентификаторов .... Простейшие методы построения таблиц идентификаторов Построение таблиц идентификаторов по методу бинарного дерева ... Хэш-функции и хэш-адресация Комбинированные способы построения таблиц идентификаторов ....
Контрольные вопросы и задачи Вопросы
Глава 3. Лексические анализаторы
Лексические анализаторы (сканеры). Принципы построения сканеров
Назнвчение лексического анализатора
Принципы построения лексических анализаторов
Регулярные языки и грамматики
Регулярные и автоматные грамматики
Конечные автоматы
Детерминированные и недетерминированные конечные автоматы Минимизация конечных автоматов Регулярные множества и регулярные выражения
Свойства регулярных языков
Построение лексических анализаторов
Три способа задания регулярных языков
Построение регулярного выражения для языка, заданного леволинейной грамматикой
Построение конечного автомата на основе леволинейной грамматики ... Примеры построения лексических анализаторов
Автоматизация построения лексических анализаторов (программа LEX)...
Контрольные вопросы и задачи
Вопросы
Задачи
Глава 4. Синтаксические анализаторы 144
Основные принципы работы синтаксических анализаторов144
Назначение синтаксических анализаторов 144
Автоматы с магазинной памятью145
Построение синтаксических анализаторов148
Преобразование КС-грамматик. Приведенные грамматики153
Преобразование грамматик. Цель преобразования153
Приведенные грамматики154
Удаление бесплодных символов154
Удаление недостижимых символов155
Устранение ^-правил 156
Устранение цепных правил 158
Устранение левой рекурсии160
Синтаксические распознаватели с возвратом162
Принципы работы распознавателей с возвратом .. 162
Нисходящий распознаватель с возвратом 164
Распознаватель на основе ал「оритма «сдвиг-свертка»170
Нисходящие распознаватели КС-языков без возвратов176
Левосторонний разбор по методу рекурсивного спуска176
Расширенные варианты метода рекурсивного спуска180
Щк)-грамматики 184
Синтаксический разбор для Щ1)-грамматик187
Восходящие распознаватели КС-языков без возвратов197
1Я(к)-грамматики198
Синтаксический разбор для 1Я(0)-грамматик203
Синтаксический разбор для ЬЯ(1)-грамматик209
SLR(1) и и\ЬЯ(1)-грамматики214
Автоматизация построения синтаксических анализаторов (программа YACC)221
Синтаксические распознаватели на основе грамматик предшествования . . . . 223
Общие принципы грамматик предшествования223
Грамматики простого предшествования224
Грамматики операторного предшествования234
Контрольные вопросы и задачи245
Вопросы245
Задачи .. . . 247
Глава 5. Генерация и оптимизация кода249
Семантический анализ и подготовка к генерации кода249
Назначение семантического анализа249
Этапы семантического анализа250
Идентификация лексических единиц языков программирования256
Распределение памяти259
Принципы распределения памяти259
Виды переменных и областей памяти260
Виды областей памяти. Статическое и динамическое связывание263
Дисплей памяти процедуры (функции). Стековая организация
дисплея памяти
Исключительные ситуации и их обработка
Память для типов данных (RTTI-информация)
Генерация кода. Методы генерации кода Общие принципы генерации кода
Синтаксически управляемый перевод Способы внутреннего представления программ Обратная польская запись операций Схемы СУ-перевода
Оптимизация кода. Основные методы оптимизации301
Общие принципы оптимизации кода 301
Оптимизация линейных участков программы . . 305
Другие методы оптимизации программ312
Машинно-зависимые методы оптимизации319
Контрольные вопросы и задачи321
Вопросыг321
Задачи324
Глава 6. Современные системы программирования 327
Понятие и структура системы программирования327
Понятие о системе программирования327
Возникновение систем программирования328
Появление интегрированных сред разработки 330
Структура современной системы программирования332
Принципы функционирования систем программирования335
Функции текстовых редакторов в системах программирования335
Компилятор как составная часть системы программирования 338
Компоновщик. Назначение и функции компоновщика339
Загрузчики и отладчики. Функции загрузчика341
Библиотеки подпрограмм345
Библиотеки подпрограмм как составная часть систем программирования . . 345
Статические библиотеки подпрограмм 347
Динамические библиотеки подпрограмм348
Ресурсы_пользовательского интерфейса. Редакторы ресурсов350
Мобильность и переносимость программного обеспечения 351
Разработка приложений в архитектуре «клиент-сервер» .. . 357
История возникновения приложений с архитектурой «клиент-сервер» . . . 357
Структура приложения, построенного в архитектуре «клиент-сервер»358
Современные серверы данных. Язык запросов данных360
Принципы создания приложений в архитектуре «клиент-сервер»363
Разработка программ в многоуровневой архитектуре . . 365
Принципы разработки приложений в многоуровневой архитектуре365
Технологии взаимодействия с сервером приложений367
Организация серверов приложений371
Возможности многоуровневой архитектуры 372
Разработка программного обеспечения для сети Интернет373
Контрольные вопросы и задачи382
Вопросы 382
Задачи384
Указатель литературы386
Алфавитный указатель390
Посвящается моему сыну Ленечке Молчанову
Предисловие
Эта книга является логическим продолжением учебника «Системное программное обеспечение», вышедшего в свет в 2001 году, для которого автором книги была подготовлена вторая часть, посвященная трансляторам и формальным грамматикам. Главной целевой аудиторией книги «Системное программное обеспечение» были студенты технических вузов, обучающиеся по специальности «Вычислительные машины, комплексы, системы и сети» и родственным с ней направлениям, поэтому материал книги был подобран исходя из требований стандарта этой специальности.
С момента выпуска прошлой версии учебника в стандарт специальности «Вычислительные машины, комплексы, системы и сети» было внесено изменение: две части, составлявшие ранее дисциплину «Системное программное обеспечение», были разделены на самостоятельные, хотя и взаимосвязанные, курсы. Один из курсов получил название «Операционные системы» (что соответствует первой части прошлой версии учебника), а второй унаследовал название «Системное программное обеспечение».
Это обстоятельство, а также понимание того, что технологии разработки программного обеспечения за время, прошедшее с момента написания предыдущего учебника, получили существенное развитие, побудило автора подготовить новую редакцию учебника.
Данный учебник посвящен компиляторам и системам программирования, что полностью отвечает содержанию дисциплины «Системное программное обеспечение» по новой версии стандарта.
По сравнению со второй частью предыдущей редакции книги «Системное программное обеспечение» автор постарался придать материалу более практическую направленность. С одной стороны, это позволило сократить теоретические разделы книги, не отклоняясь от требований образовательного стандарта, что, по мнению автора, должно способствовать лучшему усвоению учебного материала, а с другой стороны, книга может оказаться полезной не только студентам, но и специалистам, чья деятельность напрямую связана с созданием средств обработки текстов и структурированных текстовых команд.
С точки зрения практической направленности претерпело изменение и изложение материала в книге. Естественно, наименьшим изменениям подверглись первые две главы, посвященные теории формальных грамматик и общей структуре трансляторов и компиляторов, — их содержимое осталось практически прежним, поскольку в этой области за прошедшее время не произошло (да и не могло произойти) никаких изменений.
Три следующие главы полностью перестроены автором. Теперь материал структурирован не в соответствии с разделами теории формальных языков, а исходя из общей структуры компилятора. Каждая глава соответствует одной из составляющих структуры компилятора — лексический анализ, синтаксический анализ и генерация кода. Главы дополнены содержательными примерами, которые помогут пользователю на практике усвоить излагаемый материал.
И наконец, полностью перестроена последняя глава, посвященная современным системам программирования. Во-первых, автор дополнил те разделы, на которые, по его мнению, ранее не было обращено должное внимание, а во-вторых, именно в этой части книги нашли свое отражение те самые происшедшие за ближайшее время существенные изменения технологий, о которых говорилось выше.
Введение
Традиционная архитектура компьютера (архитектура фон-Неймана) остается неизменной и преобладает в современных вычислительных системах. Столь же неизменными остаются и базовые принципы, на основе которых строятся средства разработки программного обеспечения для компьютеров — трансляторы, компиляторы и интерпретаторы. Но современные средства разработки, оставаясь на тех же базовых принципах, что и компьютеры традиционной архитектуры, прошли долгий путь совершенствования и развития от командных систем до интегрированных сред и систем программирования. И это обстоятельство нашло отражение в предлагаемом учебнике.
С одной стороны, компьютеры традиционной архитектуры умеют понимать только коды машинных команд. С другой стороны, разработчики не имеют возможности создавать прикладные и системные программы на уровне машинных кодов — слишком велик процент ошибок и непомерно велика трудоемкость такой работы. Поэтому давно возникла потребность в появлении «переводчиков» с различных языков программирования (языков ассемблера и языков высокого уровня) на язык машинных кодов. Такими переводчиками стали трансляторы. Само слово «транслятор» (translator) в переводе с английского означает не что иное, как «переводчик». Наряду с термином «транслятор» часто употребляется еще термин «компилятор» (compiler), имеющий почти то же значение. Разница между ними объясняется в этой книге, в той главе, где даются точные определения этих понятий; здесь же можно только сказать, что «транслятор» — понятие более широкое, а «компилятор» — более узкое (любой компилятор является транслятором, но не наоборот).
Ныне существует огромное количество разнообразных языков программирования. Все они имеют свою историю, свою область применения, и перечислять даже наиболее известные из них здесь не имеет смысла. По каждому из этих языков программирования существует масса литературы, посвященной именно этому языку и средствам разработки, основанным на нем. Но в этой книге излагаются принципы и технологии, лежащие в основе всех современных языков программирования, поскольку все эти языки построены на одном фундаментальном базисе, который составляет теория формальных языков и грамматик.
На этих принципах и технологиях построены все средства разработки, которые в настоящее время являются не просто трансляторами и компиляторами, а комплексами, представляющими собой системы программирования.
Автор надеется, что эта книга будет полезна не только студентам, изучающим данную дисциплину, но также тем, кто создает компиляторы и работает с ними, то есть подавляющему большинству практикующих программистов. Немаловажно знать инструмент, которым пользуешься, а потому в книге представлено много подсказок и советов, ориентированных прежде всего на разработчиков программ. Автор выражает благодарность и признательность своей жене Олесе за огромную выдержку и моральную поддержку, благодаря которой он смог закончить работу над новой редакцией книги в самый короткий срок.
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на веб-сайте издательства http://www.piter.com.
Глава 1 Формальные языки и грамматики
Языки и цепочки символов. Способы задания языков
Цепочки символов. Операции над цепочками символов
Цепочкой символов (или строкой) называют произвольную упорядоченную конечную последовательность символов, записанных один за другим. Понятие символа (или буквы) является базовым в теории формальных языков и не нуждается в определении.
Далее цепочки символов будем обозначать греческими буквами: а, 0, у.
Цепочка символов — это последовательность, в которую могут входить любые допустимые символы. Строка, которую вы сейчас читаете, является примером цепочки, допустимые символы в которой — строчные и заглавные русские буквы, знаки препинания и символ пробела. Но цепочка — это необязательно некоторая осмысленная последовательность символов. Последовательность <^аввв..аагръъ »лл» — тоже пример цепочки символов.
Цепочка символов — это упорядоченная последовательность символов. Это значит, что для цепочки символов имеют значение три фактора: состав входящих в цепочку символов, их количество, а также порядок символов в цепочке. Поэтому цепочки «а» и «аа», а также «〃6» и «6«» — это различные цепочки символов. Цепочки символов а и 0 равны (совпадают), а == 0, если они имеют один и тот же состав символов, одно и то же их количество и одинаковый порядок следования символов в цепочке.
Количество символов в цепочке называют длиной цепочки. Длина цепочки символов а обозначается как |а|. Очевидно, что если а = 0, то и |а| = |р|.
Основной операцией над цепочками символов является операция конкатенации (объединения или сложения) цепочек.
Конкатенация (сложение, объединение) двух цепочек символов — это дописывание второй цепочки в конец первой. Конкатенация цепочек а и 0 обозначается как ар. Выполнить конкатенацию цепочек просто: например, если а = 〃6, а 0 = вг, то ар н абвг.
ВНИМАНИЕ
Так как в цепочке важен порядок символов, то очевидно, что для операции конкатенации двух цепочек символов важно, в каком порядке записаны цепочки. Иными словами, конкатенация цепочек символов не обладает свойством коммутативности, то есть в общем случае Заир такие, что ар н ра (например, для а = 〃6 и 0 вг: ар р абвг, а Ра - вгаб и сф н Ра).
Также очевидно, что конкатенация обладает свойством ассоциативности, то есть (邛力 н а(Рт).
Любую цепочку символов языка можно представить как конкатенацию составляющих ее частей — разбить цепочку на несколько подцепочек. Такое разбиение можно выполнить несколькими способами произвольным образом. Например, цепочку у н абвг можно представить в виде конкатенации цепочек а = 〃6 и 0 = & (у ■ а|3), а можно — в виде конкатенации цепочек и = а и ①=6gz (у = и со). Чем длиннее исходная цепочка, тем больше вариантов разбиения ее на составляющие подцепочки.
Если некоторую цепочку символов разбить на составляющие ее подцепочки, а затем заменить одну из подцепочек на любую произвольную цепочку символов, то в результате получится новая цепочка символов. Такое действие называется заменой, или подстановкой, цепочки. Например, возьмем все ту же цепочку у " абвг, разобьем ее на три подцепочки: аиа, сов6иРивг(ув асор), и выполним подстановку цепочки и н аба вместо подцепочки со. Получим новую цепочку у' - аабавг (у' " аир). Любая подстановка выполняется с помощью разбиения исходной цепочки на подцепочки и операции конкатенации.
Можно выделить еще две операции над цепочками:
Обращение цепочки — это запись символов цепочки в обратном порядке. Обращение цепочки а обозначается как aR. Если a = «абвг», то aR = «28б〃». Для операции обращения справедливо следующее равенство V a,0: (ap)R = pRaR.
Итерация (повторение) цепочки п раз, где neN, п > 0 — это конкатенация цепочки самой с собой п раз. Итерация цепочки a п раз обозначается как an. Для операции повторения справедливы следующие равенства V a: а1 = а, а2 = аа, а3 = ааа, ... и т. д. Итерация цепочки символов определена и для п = 0 — в этом случае результатом итерации будет пустая цепочка символов.
Пустая цепочка символов — это цепочка, не содержащая ни одного символа. Пустую цепочку здесь везде будем обозначать греческой буквой 大(в литературе ее иногда обозначают латинской буквой е или греческой е).
Для пустой цепочки справедливы следующие равенства:
|х| = о
Da: Xa = aX = a
廿=入
Vn > 0: V = X
Da: a° =大
Понятие языка. Формальное определение языка
В общем случае язык — это заданный набор символов и правил, устанавливающих способы комбинации этих символов между собой для записи осмысленных текстов. Основой любого естественного или искусственного языка является алфавит, определяющий набор допустимых символов языка.
Алфавит — это счетное множество допустимых символов языка. Будем обозначать это множество символом V. Интересно, что согласно формальному определению, алфавит не обязательно должен быть конечным множеством, но реально все существующие языки строятся на основе конечных алфавитов.
Цепочка символов а является цепочкой над алфавитом V: a(V), если в нее входят только символы, принадлежащие множеству символов V. Для любого алфавита V пустая цепочка 大 может как являться, так и не являться цепочкой X(V). Это условие оговаривается дополнительно.
Если V — некоторый алфавит, то:
V+ — множество всех цепочек над алфавитом V без X;
V* — множество всех цепочек над алфавитом V, включая X.
Справедливо равенство: V* = V+u{X}.
Языком L над алфавитом V: L(V) называется некоторое счетное подмножество цепочек конечной длины из множества всех цепочек над алфавитом V. Из этого определения следует два вывода: во-первых, множество цепочек языка не обязано быть конечным; во-вторых, хотя каждая цепочка символов, входящая в язык, обязана иметь конечную длину, эта длина может быть сколь угодно большой и формально ничем не ограничена.
Все существующие языки подпадают под это определение. Большинство реальных естественных и искусственных языков содержат бесконечное множество цепочек. Также в большинстве языков длина цепочки ничем не ограничена (например, этот длинный текст — пример цепочки символов русского языка). Цепочку символов, принадлежащую заданному языку, часто называют предложением языка, а множество цепочек символов некоторого языка L(V) — множеством предложений этого языка.
Для любого языка L(V) справедливо: L(V)cV*.
Язык L(V) включает в себя язык L'(V): L'(V)qL(V), если VaeL(V): aeL'(V). Множество цепочек языка L'(V) является подмножеством множества цепочек
языка L(V) (или эти множества совпадают). Очевидно, что оба языка должны строиться на основе одного и того же алфавита.
Два языка L(V) и L'(V) совпадают (эквивалентны): L'(V) = L(V), если L'(V)c L(V) и L(V)qL'(V); или, что то же самое: DawL'(V): aeL(V) и D0eL(V): 0eL'(V)・ Множества допустимых цепочек символов для эквивалентных языков равны.
Два языка L(V) и L'(V) почти эквивалентны: L'(V)?L(V), если L'(V)u{X}= =L(V)u{X}. Множества допустимых цепочек символов почти эквивалентных языков могут различаться только на пустую цепочку символов.
Способы задания языков. Синтаксис и семантика языка
Итак, каждый язык — это множество цепочек символов над некоторым алфавитом. Но кроме алфавита язык предусматривает также правила построения допустимых цепочек, поскольку обычно далеко не все цепочки над заданным алфавитом принадлежат языку. Символы могут объединяться в слова или лексемы — элементарные конструкции языка, на их основе строятся предложения — более сложные конструкции. И те и другие в общем виде являются цепочками символов, но предусматривают некоторые правила построения. Таким образом, необходимо указать эти правила, или, строго говоря, задать язык.
В общем случае язык можно определить тремя способами:
перечислением всех допустимых цепочек языка;
указанием способа порождения цепочек языка (заданием грамматики языка);
определением метода распознавания цепочек языка.
Первый из методов является чисто формальным и на практике не применяется, так как большинство языков содержат бесконечное число допустимых цепочек и перечислить их просто невозможно. Трудно себе представить, чтобы появилась возможность перечислить, например, множество всех правильных текстов на русском языке или всех правильных программ на языке Pascal. Иногда для чисто формальных языков можно перечислить множество входящих в них цепочек, прибегнув к математическим определениям множеств. Однако этот подход уже стоит ближе ко второму способу.
Например, запись L({0,l}) = {0nln, n > 0} задает язык над алфавитом V = {0,1}, содержащий все последовательности с чередующимися символами 0 и lf начинающиеся с 0 и заканчивающиеся 1. Видно, что пустая цепочка символов в этот язык не входит. Если изменить условие в этом определении с п > 0 на п > 0, то получим почти эквивалентный язык L'({0,l}), содержащий пустую цепочку.
Второй способ предусматривает некоторое описание правил, с помощью которых строятся цепочки языка. Тогда любая цепочка, построенная с помощью этих правил из символов алфавита языка, будет принадлежать заданному языку. Например, с правилами построения цепочек символов русского языка вы долго и упорко^ндксжижеь^ еред^рй школе.
Третий способ предусматривает построение некоторого логического устройства (распознавателя) — автомата, который на входе получает цепочку символов, а на выходе выдает ответ: принадлежит или нет эта цепочка заданному языку. Например, читая сейчас этот текст, вы в некотором роде выступаете в роли распознавателя (надеюсь, что ответ на вопрос о принадлежности текста русскому языку будет положительным).
Говоря о любом языке, можно выделить его синтаксис и семантику. Кроме того, трансляторы имеют дело также с лексическими конструкциями (лексемами), которые задаются лексикой языка. Ниже даны определения всех этих понятий.
Синтаксис языка — это набор правил, определяющий допустимые конструкции языка. Синтаксис определяет «форму языка» — задает набор цепочек символов, которые принадлежат языку. Чаще всего синтаксис языка можно задать в виде строгого набора правил, но полностью это утверждение справедливо только для чисто формальных языков. Даже для большинства языков программирования набор заданных синтаксических конструкций нуждается в дополнительных пояснениях, а синтаксис языков естественного общения вполне соответствует общепринятому мнению о том, что «исключения только подтверждают правило». Например, любой окончивший среднюю школу может сказать, что строка «3 + 2» является арифметическим выражением, а《3 2 +» — не является. Правда, не каждый задумается при этом, что он оперирует синтаксисом алгебры.
Семантика языка — это раздел языка, определяющий значение предложений языка. Семантика определяет «содержание языка» — задает смысл для всех допустимых цепочек языка. Семантика для большинства языков определяется неформальными методами (отношения между знаками и тем, что они обозначают, изучаются семиотикой). Чисто формальные языки лишены какого-либо смысла. Возвращаясь к примеру, приведенному выше, и используя семантику алгебры, мы можем сказать, что строка «3 + 2» есть сумма чисел 3 и 2, а также то, что 《3 + 2 = 5» — это истинное выражение. Однако изложить любому ученику синтаксис алгебры гораздо проще, чем ее семантику, хотя в случае алгебры семантику как раз можно определить формально.
Лексика — это совокупность слов (словарный запас) языка. Слово или лексическая единица (лексема) языка — это конструкция, которая состоит из элементов алфавита языка и не содержит в себе других конструкций. Иначе говоря, лексическая единица может содержать только элементарные символы и не может содержать других лексических единиц.
Лексическими единицами (лексемами) русского языка являются слова русского языка, а знаки препинания и пробелы представляют собой разделители, не образующие лексем. Лексическими единицами алгебры являются числа, знаки математических операций, обозначения функций и неизвестных величин. В языках программирования лексическими единицами являются ключевые слова, идентификаторы, константы, метки, знаки операций; в них также существуют и разделители (запятые, скобки, точки с запятой и т. д.).
Особенности языков программирования
Языки программирования занимают некоторое промежуточное положение между формальными и естественными языками. С формальными языками их объединяют строгие синтаксические правила, на основе которых строятся предложения языка. От языков естественного общения в языки программирования перешли лексические единицы, представляющие основные ключевые слова (чаще всего это слова английского языка, но существуют языки программирования, чьи ключевые слова заимствованы из русского и других языков). Кроме того, из алгебры языки программирования переняли основные обозначения математических операций, что также делает их более понятными человеку.
Для задания языка программирования необходимо решить три вопроса:
определить множество допустимых символов языка;
определить множество правильных программ языка;
задать смысл для каждой правильной программы.
Только первые два вопроса полностью или частично удается решить с помощью теории формальных языков. Для решения остальных вопросов приходится прибегать к другим, неформальным методам.
Первый вопрос решается легко. Определяя алфавит языка, мы автоматически определяем множество допустимых символов. Для языков программирования алфавит — это чаще всего тот набор символов, которые можно ввести с клавиатуры. Основу его составляет младшая половина таблицы международной кодировки символов (таблицы ASCII ), к которой добавляются символы национальных алфавитов.
Второй вопрос решается в теории формальных языков только частично. Для всех языков программирования существуют правила, определяющие синтаксис языка, но как уже было сказано, их недостаточно для того, чтобы строго определить все допустимые предложения языков программирования. Дополнительные ограничения накладываются семантикой языка. Эти ограничения оговариваются в неформальном виде для каждого отдельного языка программирования. К таким ограничениям можно отнести необходимость предварительного описания переменных и функций, необходимость соответствия типов переменных и констант в выражениях, формальных и фактических параметров в вызовах функций и др.
Отсюда следует, что практически все языки программирования, строго говоря, не являются формальными языками. И именно поэтому во всех трансляторах кроме синтаксического разбора и анализа предложений языка дополнительно предусмотрен семантический анализ.
Третий вопрос в принципе не относится к теории формальных языков, поскольку, как уже было сказано, такие языки лишены какого-либо смысла. Для ответа на него нужно использовать другие подходы.
В следующей главе, посвященной основным принципам построения трансляторов и компиляторов, будут более подробно указаны отличия языков программирования от формальных языков, которые нужно принимать во внимание при создании трансляторов и компиляторов для языков программирования.
Грамматики и распознаватели
Формальное определение грамматики. Форма Бэкуса—Наура
Грамматика — это описание способа построения предложений некоторого языка. Иными словами, грамматика — это математическая система, определяющая язык. Фактически, определив грамматику языка, мы указываем правила порождения цепочек символов, принадлежащих этому языку. Таким образом, грамматика — это генератор цепочек языка. Она относится ко второму способу определения языков — порождению цепочек символов.
Грамматику языка можно описать различными способами. Например, грамматика русского языка описывается довольно сложным набором правил, которые изучают в начальной школе. Для некоторых языков (в том числе для синтаксических конструкций языков программирования) можно использовать формальное описание грамматики, построенное на основе системы правил (или продукций).
Правило (или продукция) — это упорядоченная пара цепочек символов (а,р). В правилах важен порядок цепочек, поэтому их чаще записывают в виде а -> р (или а ::= Р). Такая запись читается как «а порождает 0» или «р по определению есть а». Грамматика языка программирования содержит правила двух типов: первые (определяющие синтаксические конструкции языка) довольно легко поддаются формальному описанию; вторые (определяющие семантические ограничения языка) обычно излагаются в неформальной форме. Поэтому любое описание (или стандарт) языка программирования обычно состоит из двух частей: вначале формально излагаются правила построения синтаксических конструкций, а потом на естественном языке дается описание семантических правил.
ВНИМАНИЕ
Далее, говоря о грамматиках языков программирования, будем иметь в виду только правила построения синтаксических конструкций языка. Однако следует помнить, что грамматика любого языка программирования в общем случае не ограничивается только этими правилами.
Язык, заданный грамматикой G, обозначается как L(G).
Две грамматики G и G' называются эквивалентными, если они определяют один и тот же язык: L(G) = L(G'). Две грамматики G и G' называются почти эквивалентными, если заданные ими языки различаются не более чем на пустую цепочку символов: L(G)u{X} = L(G')u{X}.
Формально грамматика G определяется как четверка G(VT,VN,P,S), где:
VT — множество терминальных символов или алфавит терминальных символов;
VN — множество нетерминальных символов или алфавит нетерминальных символов;
Р — множество правил (продукций) грамматики, вида а—>р, где ae(VNuVT)+, Pg(VNuVT)*;
S — целевой (начальный) символ грамматики SgVN.
Алфавиты терминальных и нетерминальных символов грамматики не пересекаются: VNnVT н 0. Это значит, что каждый символ в грамматике может быть либо терминальным, либо нетерминальным, но не может быть терминальным и нетерминальным одновременно. Целевой символ грамматики — это всегда нетерминальный символ. Множество V * VNuVT называют полным алфавитом грамматики G.
Далее будут даны строгие формальные описания того, как связаны различные элементы грамматики и порождаемый ею язык. А пока предварительно опишем смысл множеств VN и VT. Множество терминальных символов VT содержит символы, которые входят в алфавит языка, порождаемого грамматикой. Как правило, символы из множества VT встречаются только в цепочках правых частей правил. Множество нетерминальных символов VN содержит символы, которые определяют слова, понятия, конструкции языка. Каждый символ этого множества может встречаться в цепочках как левой, так и правой частей правил грамматики, но он обязан хотя бы один раз быть в левой части хотя бы одного правила. Правила грамматики обычно строятся так, чтобы в левой части каждого правила был хотя бы один нетерминальный символ.
Во множестве правил грамматики может быть несколько правил, имеющих одинаковые левые части, вида: а -> рь а -> р2, ... а -> рп. Тогда эти правила объединяют вместе и записывают в виде: а -> 0】| 021…I Рп- Одной строке в такой записи соответствует сразу п правил.i
Такую форму записи правил грамматики называют формой Бэкуса—Наура. Форма Бэкуса—Наура предусматривает, как правило, также, что нетерминальные символы берутся в угловые скобки: < >. Иногда знак -> в правилах грамматики заменяют на знак ■ = (что характерно для старых монографий), но это всего лишь незначительные модификации формы записи, не влияющие на ее суть.
Ниже приведен пример грамматики, которая определяет язык целых десятичных чисел со знаком:
G({0,1.2.3,4.5.6,7.8.9.-1+}.{<число>,<чс>.<цифра>},Р,<число>)
Р:
«число> -> <чс> | +<чс> | -<чс> «чс> -> <цифра> | <чс><цифра> «цифра> ->0|1|2|3|4|5|6|7|8|9
Рассмотрим составляющие элементы грамматики G:
множество терминальных символов VT содержит двенадцать элементов: десять десятичных цифр и два знака;
множество нетерминальных символов VN содержит три элемента: символы <число>, <чс> и <цифра>;
множество правил содержит 15 правил, которые записаны в три строки (то есть имеется только три различных правых части правил);
целевым символом грамматики является символ <число>.
Следует отметить, что символ <чс> — это бессмысленное сочетание букв русского языка, но это обычный нетерминальный символ грамматики, такой же, как
и два других. Названия нетерминальных символов не обязаны быть осмысленными, это сделано просто для удобства понимания правил грамматики человеком. В принципе, в любой грамматике можно полностью изменить имена всех нетерминальных символов, не меняя при этом языка, заданного грамматикой,— точно так же, например, в программе на языке Pascal можно изменить имена идентификаторов, и при этом не изменится смысл программы.
Для терминальных символов это неверно. Набор терминальных символов всегда строго соответствует алфавиту языка, определяемого грамматикой.
Вот, например, та же самая грамматика для языка целых десятичных чисел со знаком, в которой нетерминальные символы обозначены большими латинскими буквами (далее это будет часто применяться в примерах): -
G'({0.1(2.3.4,5.6,7.8,9.-,+}.{S.T.F}.P.S)
S т Т | +Т | -Т
Т т F | TF
F-^0|l|2|3|4|5|6|7|8|9
Здесь изменилось только множество нетерминальных символов. Теперь VN 父{S.T.F}. Язык, заданный грамматикой, не изменился — можно сказать, что грамматики G и G1 эквивалентны.
Принцип рекурсии в правилах грамматики
Особенность рассмотренных выше формальных грамматик в том, что они позволяют определить бесконечное множество цепочек языка с помощью конечного набора правил (конечно, множество цепочек языка тоже может быть конечным, но даже для простых реальных языков это условие обычно не выполняется). Приведенная выше в примере грамматика для целых десятичных чисел со знаком определяет бесконечное множество целых чисел с помощью 15 правил.
В такой форме записи грамматики возможность пользоваться конечным набором правил достигается за счет рекурсивных правил. Рекурсия в правилах грамматики выражается в том, что один из нетерминальных символов определяется сам через себя. Рекурсия может быть непосредственной (явной) — тогда символ определяется сам через себя в одном правиле, либо косвенной (неявной) — тогда то же самое происходит через цепочку правил.
В рассмотренной выше грамматике G непосредственная рекурсия присутствует в правиле: <чс> т <чс><цифра>, а в эквивалентной ей грамматике G' — в правиле: TtTF.
Чтобы рекурсия не была бесконечной, для участвующего в ней нетерминального символа грамматики должны существовать также и другие правила, которые определяют его, минуя его самого, и позволяют избежать бесконечного рекурсивного определения (в противном случае этот символ в грамматике был бы просто не нужен). Такими правилами являются <чс> г <цифра> 一 в грамматике G н Т — F — в грамматике G'.
В теории формальных языков более ничего сказать о рекурсии нельзя. Но чтобы полнее понять смысл рекурсии, можно прибегнуть к семантике языка — в рассмотренном выше примере это язык целых десятичных чисел со знаком. Рассмотрим его смысл.
Если попытаться дать определение тому, что же является числом, то начать можно с того, что любая цифра сама по себе есть число. Далее можно заметить, что любые две цифры — это тоже число, затем — три цифры и т. д. Если строить определение числа таким методом, то оно никогда не будет закончено (в математике разрядность числа ничем не ограничена). Однако можно заметить, что каждый раз, порождая новое число, мы просто дописываем цифру справа (поскольку привыкли писать слева направо) к уже написанному ряду цифр. А этот ряд цифр, начиная от одной цифры, тоже в свою очередь является числом. Тогда определение для понятия «число» можно построить таким образом: «число — это любая цифра либо другое число, к которому справа дописана любая цифра». Именно это и составляет основу правил грамматик G и G' и отражено в правилах <чс> -> <цифра> I <чс><цифра> и Т т F | TF (вторая строка правил). Другие правила в этих грамматиках позволяют добавить к числу знак (первая строка правил) и дают определение понятию «цифра» (третья строка правил). Они элементарны и не требуют пояснений.
Принцип рекурсии (иногда его называют «принцип итерации», что не меняет сути) — важное понятие в представлении о формальных грамматиках. Так или иначе, явно или неявно рекурсия всегда присутствует в грамматиках любых реальных языков программирования. Именно она позволяет строить бесконечное множество цепочек языка, и говорить об их порождении невозможно без понимания принципа рекурсии. Как правило, в грамматике реального языка программирования содержится не одно, а целое множество правил, построенных с помощью рекурсии.
Другие способы задания грамматик
Форма Бэкуса—Наура — удобный с формальной точки зрения, но не всегда доступный для понимание способ записи формальных грамматик. Рекурсивные определения хороши для формального анализа цепочек языка, но не удобны с точки зрения человека. Например, то, что правила <чс> f <цифра> | <чс><цифра> отражают возможность для построения числа дописывать справа любое число цифр, начиная от одной, неочевидно и требует дополнительного пояснения.
Но при создании языка программирования важно, чтобы его грамматику понимали не только те, кому предстоит создавать компиляторы для этого языка, но и пользователи языка — будущие разработчики программ. Поэтому существуют другие способы описания правил формальных грамматик, которые ориентированы на большую понятность для человека.
Далее рассмотрим два наиболее распространенных из этих способов: запись правил грамматик с использованием метасимволов и запись правил грамматик в графическом виде.
Запись правил грамматик с использованием метасимволов
Запись правил грамматик с использованием метасимволов предполагает, что в строке правила грамматики могут встречаться специальные символы — метасимволы, —которые имеют особый смысл и трактуются специальным образом. В качестве таких метасимволов чаще всего используются следующие символы: ()(круглые скобки), [ ] (квадратные скобки), { } (фигурные скобки), и ” (кавычки) и . (запятая).
Эти метасимволы имеют следующий смысл:
круглые скобки означают, что из всех перечисленных внутри них цепочек символов в данном месте правила грамматики может стоять только одна цепочка;
квадратные скобки означают, что указанная в них цепочка может встречаться, а может и не встречаться в данном месте правила грамматики (то есть может быть в нем один раз или ни одного раза);
фигурные скобки означают, что указанная внутри них цепочка может не встречаться в данном месте правила грамматики ни одного раза, встречаться один раз или сколь угодно много раз;
запятая служит для того, чтобы разделять цепочки символов внутри круглых скобок;
кавычки используются в тех случаях, когда один из метасимволов нужно включить в цепочку обычным образом — то есть когда одна из скобок или запятая должны присутствовать в цепочке символов языка (если саму кавычку нужно включить в цепочку символов, то ее надо повторить дважды — этот принцип знаком разработчикам программ).
Вот как должны выглядеть правила рассмотренной выше грамматики G, если их записать с использованием метасимволов:
<число> — [(+,-)]<цифра>{<цифра>}
<цифра> ^0|1|2|3|4|5|6|7|8|9
Вторая строка правил не нуждается в комментариях, а первое правило читается так:《число есть цепочка символов, которая может начинаться с символов + или -, должна содержать дальше одну цифру, за которой может следовать любое количество цифр». В отличие от формы Бэкуса—Наура, в форме записи с помощью метасимволов, как видно, во-первых, убран из грамматики малопонятный нетерминальный символ <чс>, а во-вторых — удалось полностью исключить рекурсию. Грамматика в итоге стала более понятной.
Форма записи правил с использованием метасимволов — это удобный и понятный способ представления правил грамматик. Она во многих случаях позволяет полностью избавиться от рекурсии, заменив ее символом итерации { } (фигурные скобки). Как будет понятно из дальнейшего материала, эта форма наиболее употребительна для одного из типов грамматик — регулярных грамматик.
Кроме указанных выше метасимволов в целях удобства записи в описаниях грамматик иногда используют и другие метасимволы, при этом предварительно
дается разъяснение их смысла. Принцип записи от этого не меняется. Также иногда дополняют смысл уже существующих метасимволов. Например, для метасимвола { } (фигурные скобки) существует удобная форма записи, позволяющая ограничить число повторений цепочки символов, заключенной внутри них: { }п, где nwN и п > 0. Такая запись означает, что цепочка символов, стоящая в фигурных скобках, может быть повторена от 0 до п раз (не более п раз). Это очень удобный метод наложения ограничений на длину цепочки.
Для рассмотренной выше грамматики G таким способом можно, например, записать правила, если предположить, что она должна порождать целые десятичные числа, содержащие не более 15 цифр:
«число> — [(+.-)]<цифра>{<цифра>}14
<цифра> О I 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9
Для записи того же самого ограничения в форме Бэкуса—Наура или в форме с метасимволами потребовалось бы 15 правил.
Запись правил грамматик в графическом виде
При записи правил в графическом виде вся грамматика представляется в форме набора специальным образом построенных диаграмм. Эта форма была предложена при описании грамматики языка Pascal, а затем она получила широкое распространение в литературе. Она доступна не для всех типов грамматик, а только для тех типов, где в левой части правил присутствует не более одного символа, но этого достаточно, чтобы ее можно было использовать для описания грамматик известных языков программирования.
В такой форме записи каждому нетерминальному символу грамматики соответствует диаграмма, построенная в виде направленного графа. Граф имеет следующие типы вершин:
точка входа (на диаграмме никак не обозначена, из нее просто начинается входная дуга графа);
нетерминальный символ (на диаграмме обозначается прямоугольником, в который вписано обозначение символа);
цепочка терминальных символов (на диаграмме обозначается овалом, кругом или прямоугольником с закругленными краями, внутрь которого вписана цепочка);
узловая точка (на диаграмме обозначается жирной точкой или закрашенным кружком);
точка выхода (никак не обозначена, в нее просто входит выходная дуга графа). Каждая диаграмма имеет только одну точку входа и одну точку выхода, но сколько угодно вершин других трех типов. Вершины соединяются между собой направленными дугами графа (линиями со стрелками). Из входной точки дуги могут только выходить, а во входную точку — только входить. В остальные вершины дуги могут как входить, так и выходить (в правильно построенной грам-
матике каждая вершина должна иметь как минимум один вход и как минимум один выход).
Чтобы построить цепочку символов, соответствующую какому-либо нетерминальному символу грамматики, надо рассмотреть диаграмму для этого символа. Тогда, начав движение от точки входа, надо двигаться по дугам графа диаграммы через любые вершины вплоть до точки выхода. При этом, проходя через вершину, обозначенную нетерминальным символом, этот символ следует поместить в результирующую цепочку. При прохождении через вершину, обозначенную цепочкой терминальных символов, эти символы также следует поместить в результирующую цепочку. При прохождении через узловые точки диаграммы над результирующей цепочкой никаких ае访ствнй выполнять не надо. Через любую вершину графа диаграммы, в зависимости от возможного пути движения, можно пройти один раз, ни разу или сколь угодно много раз. Как только мы попадем в точку выхода диаграммы, построение результирующей цепочки будет закончено.
Результирующая цепочка, в свою очередь, может содержать нетерминальные символы. Чтобы заменить их на цепочки терминальных символов, нужно, опять же, рассматривать соответствующие им диаграммы. И так до тех пор, пока в цепочке не останутся только терминальные символы. Очевидно, что для того, чтобы построить цепочку символов заданного языка1 надо начать рассмотрение с диаграммы целевого символа грамматики.
Это удобный способ описания правил грамматик, оперирующий образами, а потому ориентированный исключительно на людей. Даже простое изложение его основных принципов здесь оказалось довольно громоздким, в то время как суть способа довольно проста. Это можно легко заметить, если посмотреть на описание понятия «число» из грамматики G с помощью диаграмм на рис. 1,1.
Как уже было сказано выше, данный способ в основном применяется в литературе при изложении грамматик языков программирования. Для пользователей — разработчиков программ — он удобен, но практического применения в компиляторах пока не имеет.
Существуют и другие способы описания грамматик, но поскольку они не так часто встречаются в литературе, как два описанных выше способа, в данном учебном пособии они не рассматриваются.
Распознаватели. Общая схема распознавателя
Распознаватель (收^ разборщик) 一 это специальный автомат, который позволяет определить принадлежность цепочки символов некоторому языку. Задача распознавателя заключается в том, чтобы на основании исходной цепочки дать ответ на вопрос, принадлежит ли она заданному языку или нет. Распознаватели, как было сказано выше, представляют собой один из способов определения языка.
В общем виде распознаватель можно отобразить в виде условной схемы, представленной на рис. 1.2.
Следует подчеркнуть, что представленный рисунок — всего лишь условная схема, -гображающая работу алгоритма распознавателя. Ни в коем случае не стоит искать
подобное устройство в составе компьютера. Распознаватель, являющийся частью компилятора, представляет собой часть программного обеспечения компьютера.
Как видно из рисунка, распознаватель состоит из следующих основных компонентов:
ленты, содержащей входную цепочку символов, и считывающей головки, обозревающей очередной символ в этой цепочке;
устройства управления (УУ), которое координирует работу распознавателя, имеет некоторый набор состояний и конечную память (для хранения своего состояния и некоторой промежуточной информации);
внешней (рабочей) памяти, которая может хранить некоторую информацию в процессе работы распознавателя и, в отличие от памяти УУ, имеет неограниченный объем.
Распознаватель работает с символами своего алфавита — алфавита распознавателя. Алфавит распознавателя конечен. Он включает в себя все допустимые символы входных цепочек, а также некоторый дополнительный алфавит символов, которые могут обрабатываться УУ и храниться в рабочей памяти распознавателя. В процессе своей работы распознаватель может выполнять некоторые элементарные операции:
чтение очередного символа из входной цепочки;
сдвиг входной цепочки на заданное количество символов (вправо или влево);
доступ к рабочей памяти для чтения или записи информации;
преобразование информации в памяти УУ, изменение состояния УУ.
То, какие конкретно операции должны выполняться в процессе работы распознавателя, определяется в УУ.
Распознаватель работает по шагам, или тактам. В начале такта, как правило, считывается очередной символ из входной цепочки, и в зависимости от этого символа УУ определяет, какие действия необходимо выполнить. Вся работа распознавателя состоит из последовательности тактов. В начале каждого такта состояние распознавателя определяется его конфигурацией. В процессе работы конфигурация распознавателя меняется.
Конфигурация распознавателя определяется следующими параметрами:
содержимым входной цепочки символов и положением считывающей головки в ней;
состоянием УУ;
содержимым внешней памяти.
Для распознавателя всегда задается определенная конфигурация, которая считается начальной конфигурацией. В начальной конфигурации считывающая головка обозревает первый символ входной цепочки, УУ находится в заданном начальном состоянии, а внешняя память либо пуста, либо содержит строго определенную информацию.
Кроме начального состояния для распознавателя задается одна или несколько конечных конфигураций. В конечной конфигурации считывающая головка, как правило, находится за концом исходной цепочки (часто для распознавателей вводят специальный символ, обозначающий конец входной цепочки).
Распознаватель допускает входную цепочку символов а, если, находясь в начальной конфигурации и получив на вход эту цепочку, он может проделать последовательность шагов, заканчивающуюся одной из его конечных конфигураций.
Формулировка «может проделать последовательность шагов》более точна, чем прямое указание «проделает последовательность шагов», так как для многих распознавателей при одной и той же входной цепочке символов из начальной конфигурации мо^ут быть допустимы различные последовательности шагов, не все из которых ведут к конечной конфигурации.
Язык, определяемый распознавателем, — это множество всех цепочек, которые допускает распознаватель.
Далее в этой книге рассмотрены конкретные типы распознавателей для различных языков. Но все, что было сказано здесь, относится ко всем без исключения типам распознавателей для всех типов языков.
Виды распознавателей
Распознаватели можно классифицировать в зависимости от вида составляющих их компонентов: считывающего устройства, устройства управления (УУ) и внешней памяти.
По видам считывающего устройства распознаватели могут быть двусторонние и односторонние.
Односторонние распознаватели допускают перемещение считывающей головки по ленте входных символов только в одном направлении. Это значит, что на каждом шаге работы распознавателя считывающая головка может либо переместиться по ленте символов на некоторое число позиций в заданном направлении, либо остаться на месте. Поскольку все языки программирования подразумевают нотацию чтения исходной программы «слева направо», то так же работают и все распознаватели. Поэтому когда говорят об односторонних распознавателях, то прежде всего имеют в виду левосторонние, которые читают входную цепочку слева направо и не возвращаются назад к уже прочитанной части цепочки.
Двусторонние распознаватели допускают, что считывающая головка может перемещаться относительно ленты входных символов в обоих направлениях: как вперед, от начала ленты к концу, так и назад, возвращаясь к уже прочитанным символам.
По видам устройства управления распознаватели бывают детерминированные и недетерминированные.
Распознаватель называется детерминированным в том случае, если для каждой допустимой конфигурации распознавателя, которая возникла на некотором шаге его работы, существует единственно возможная конфигурация, в которую распознаватель перейдет на следующем шаге работы.
В противном случае распознаватель называется недетерминированным. Недетерминированный распознаватель может иметь такую допустимую конфигурацию, для которой существует некоторое конечное множество конфигураций,
возможных на следующем шаге работы. Достаточно иметь хотя бы одну такую конфигурацию, чтобы распознаватель был недетерминированным.
По видам внешней памяти распознаватели бывают следующих типов:
распознаватели без внешней памяти;
распознаватели с ограниченной внешней памятью;
распознаватели с неограниченной внешней памятью.
У распознавателей без внешней памяти внешняя память полностью отсутствует. В процессе их работы используется только конечная память УУ.
У распознавателей с ограниченной внешней памятью размер внешней памяти ограничен в зависимости от длины входной цепочки символов. Эти ограничения могут налагаться некоторой зависимостью объема памяти от длины цепочки — линейной, полиномиальной, экспоненциальной и т. д. Кроме того, для таких распознавателей может быть указан способ организации внешней памяти — стек, очередь, список и т. п.
Распознаватели с неограниченной внешней памятью предполагают, что для их работы может потребоваться внешняя память неограниченного объема (вне зависимости от длины входной цепочки). У таких распознавателей предполагается память с произвольным методом доступа.
Вместе эти три составляющих позволяют организовать общую классификацию распознавателей. Например, в этой классификации возможен такой тип: «двусторонний недетерминированный распознаватель с линейно ограниченной стековой памятью».
Тип распознавателя в классификации определяет сложность создания такого распознавателя, а следовательно, сложность разработки соответствующего программного обеспечения для компилятора. Чем выше в классификации стоит распознаватель, тем сложнее создавать алгоритм, обеспечивающий его работу. Разрабатывать двусторонние распознаватели сложнее, чем односторонние. Можно заметить, что недетерминированные распознаватели по сложности выше детерминированных. Зависимость затрат на создание алгоритма от типа внешней памяти также очевидна.
Задача разбора
Для каждого языка программирования важно не только уметь построить текст программы на этом языке, но и определить принадлежность имеющегося текста к данному языку. Именно эту задачу решают компиляторы в числе прочих задач (компилятор должен не только распознать исходную программу, но и построить эквивалентную ей результирующую программу). В отношении исходной программы компилятор выступает как распознаватель, а человек, создавший программу на некотором языке программирования, выступает в роли генератора цепочек этого языка.
Грамматики и распознаватели — два независимых метода, которые реально гут быть использованы для определения какого-либо языка. Однако при созда-
нии компилятора для некоторого языка программирования возникает задача, которая требует связать между собой эти методы задания языков.
Разработчики компилятора всегда имеют дело с уже определенным языком программирования. Грамматика для синтаксических конструкций этого языка известна. Она, как правило, четко описана в стандарте языка. Задача разработчиков заключается в том, чтобы построить распознаватель для заданного языка, который затем будет основой синтаксического анализатора в компиляторен Таким образом, задача разбора в общем виде заключается в следующем: на основе имеющейся грамматики некоторого языка построить распознаватель для этого языка. Заданная грамматика и распознаватель должны быть эквивалентны, то есть определять один и тот же язык (часто допускается, чтобы они были почти эквивалентны, поскольку пустая цепочка во внимание обычно не принимается). Задача разбора в общем виде может быть решена не для всех языков. Разработчиков компиляторов интересуют прежде всего синтаксические конструкции языков программирования. Для этих конструкций доказано, что задача разбора для них разрешима. Более того, для них найдены формальные методы ее решения. Описанию и обоснованию именно методов решения задачи разбора будет посвящена большая часть материала последующих глав данной книги.
Поскольку языки программирования не являются чисто формальными языками и несут в себе некоторый смысл (семантику), то задача разбора для создания реальных компиляторов понимается несколько шире, чем она формулируется для чисто формальных языков. Компилятор должен не просто установить принадлежность входной цепочки символов заданному языку, но и определить ее смысловую нагрузку. Для этого необходимо выявить те правила грамматики, на основании которых цепочка была построена.
Если же входная цепочка символов не принадлежит заданному языку — исходная программа содержит ошибку, — разработчику программы не интересно просто узнать сам факт наличия ошибки. В данном случае задача разбора также расширяется: распознаватель в составе компилятора должен не только установить факт присутствия ошибки во входной программе, но и по возможности определить тип ошибки и то место во входной цепочке символов, где она встречается.
Классификация языков и грамматик
Выше уже упоминались различные типы грамматик, но не было указано, как и по какому принципу они подразделяются на типы. Для человека языки бывают простые и сложные, но это сугубо субъективное мнение, которое зачастую зависит от личности человека.
Для компиляторов языки также можно разделить на простые и сложные, но в данном случае существуют жесткие критерии для такого подразделения. Как будет показано далее, от того, к какому типу относится тот или иной язык программирования, зависит сложность компилятора для этого языка. Чем сложнее язык, тем выше вычислительные затраты компилятора на анализ цепочек исходной
программы, написанной на этом языке, а следовательно, сложнее сам компилятор и его структура. Для некоторых типов языков в принципе невозможно построить компилятор, который бы анализировал исходные тексты на этих языках за приемлемое время на основе ограниченных вычислительных ресурсов (именно поэтому до сих пор невозможно создавать программы на естественных языках, например на русском или английском).
Классификация грамматик. Четыре типа грамматик по Хомскому
Согласно классификации, предложенной американским лингвистом Ноамом Хомским, профессором Массачусетского технологического института, формальные грамматики классифицируются по структуре их правил. Если все без исключения правила грамматики удовлетворяют некоторой заданной структуре, то такую грамматику относят к определенному типу. Достаточно иметь в грамматике одно правило, не удовлетворяющее требованиям структуры правил, и она уже не попадает в заданный тип.
По классификации Хомского выделяют четыре типа грамматик.
Тип О: грамматики с фразовой структурой
На структуру их правил не накладывается никаких ограничений: для грамматики вида G(VT,VN,P,S), V = VNuVT правила имеют вид: а -> р, где aeV\ peV*.
Это самый общий тип грамматик. В него подпадают все без исключения формальные грамматики, но часть из них, к общей радости, может быть также отнесена и к другим классификационным типам. Дело в том, что грамматики, которые относятся только к типу 0 и не могут быть отнесены к другим типам, являются самыми сложными по структуре.
Практического применения грамматики, относящиеся только к типу 0, не имеют.
Тип 1: контекстно-зависимые (КЗ) и неукорачивающие грамматики
В этот тип входят два основных класса грамматик:
Контекстно-зависимые грамматики G(VT,VN,P,S), V = VNuVT имеют правила вида: ct[Aa2 -> ai₽a2> гДе cti，ct2eV*, AeVN, peV+.
Неукорачивающие грамматики G(VT,VN,P,S), V = VNu VT имеют правила вида: a -> р, где a,peV+, |р| > |a|.
Структура правил КЗ-грамматик такова, что при построении предложений заданного ими языка один и тот же нетерминальный символ может быть заменен на ту или иную цепочку символов в зависимости от того контекста, в котором он встречается. Именно поэтому эти грамматики называют «контекстно-зависимыми». Цепочки а】и а2 в правилах грамматики обозначают контекст (at — левый контекст, а а2 — правый контекст), в общем случае любая из них (или даже обе)
может быть пустой. Говоря иными словами, значение одного и того же символа может быть различным в зависимости от того, в каком контексте он встречается.
Неукорачивающие грамматики имеют такую структуру правил, что при построении предложений языка, заданного грамматикой, любая цепочка символов может быть заменена на цепочку символов не меньшей длины. Отсюда и название «неукорачивающие».
Доказано, что эти два класса грамматик эквивалентны. Это значит, что для любого языка, заданного контекстно-зависимой грамматикой, можно построить неукорачивающую грамматику, которая будет задавать эквивалентный язык, и наоборот: для любого языка, заданного неукорачивающей грамматикой, можно построить контекстно-зависимую грамматику, которая будет задавать эквивалентный язык.
При построении компиляторов такие грамматики не применяются, поскольку синтаксические конструкции языков программирования, рассматриваемые компиляторами, имеют более простую структуру и могут быть построены с помощью грамматик других типов. Что касается семантических ограничений языков программирования, то с точки зрения затрат вычислительных ресурсов их выгоднее проверять другими методами, а не с помощью контекстно-зависимых грамматик.
Тип 2: контекстно-свободные (КС) грамматики
Контекстно-свободные (КС) грамматики G(VT,VN,P(S), V = VNuVT имеют правила вида: А -» р, где AeVN, peV+. Такие грамматики также иногда называют неукорачивающими контекстно-свободными (НКС) грамматиками (видно, что в правой части правила у них должен всегда стоять как минимум один символ).
Существует также почти эквивалентный им класс грамматик — укорачивающие контекстно-свободные (УКС) грамматики G(VT,VN,P,S), V = VNuVT, правила которых могут иметь вид: А 0, где AeVN, peV*.
Разница между этими двумя классами грамматик заключается лишь в том, что в У КС-грамматиках в правой части правил может присутствовать пустая цепочка (X), а в НКС-грамматиках — нет. Отсюда ясно, что язык, заданный НКС- грамматикой, не может содержать пустой цепочки. Доказано, что эти два класса грамматик почти эквивалентны. В дальнейшем, когда речь будет идти о КС-грамматиках, уже не будет уточняться, какой класс грамматики (УКС или НКС) имеется в виду, если возможность наличия в языке пустой цепочки не имеет принципиального значения.
КС-грамматики широко используются при описании синтаксических конструкций языков программирования. Синтаксис большинства известных языков программирования основан именно на КС-грамматиках, поэтому в данном учебнике им уделяется большое внимание.
Внутри типа КС-грамматик кроме классов НКС и УКС выделяют еще целое множество различных классов грамматик, и все они относятся к типу 2. Далее, когда КС-грамматики будут рассматриваться более подробно, на некоторые из этих классов грамматик и их характерные особенности будет обращено особое внимание.
Тип 3: регулярные грамматики
К типу регулярных относятся два эквивалентных класса грамматик: леволинейные и праволинейные.
Леволинейные грамматики G(VTfVN,P,S), V = VNuVT могут иметь правила двух видов: А By или А -> у, где A,BsVN, yeVT*.
В свою очередь, праволинейные грамматики G(VT,VN,P,S), V = VNuVT могут иметь правила тоже двух видов: А -» уВ или А -> у, где A,BeVN, yeVT*.
Эти два класса грамматик эквивалентны и относятся к типу регулярных грамматик.
Регулярные грамматики используются при описании простейших конструкций языков программирования: идентификаторов, констант, строк, комментариев и т. д. Эти грамматики исключительно просты и удобны в использовании, поэтому в компиляторах на их основе строятся функции лексического анализа входного языка (принципы их построения будут рассмотрены далее).
Соотношения между типами грамматик
Типы грамматик соотносятся между собой особым образом. Из определения типов 2 и 3 видно, что любая регулярная грамматика является КС-грамматикой, но не наоборот. Также очевидно, что любая грамматика может быть отнесена к типу О, поскольку он не накладывает никаких ограничений на правила. В то же время существуют укорачивающие КС-грамматики (тип 2), которые не являются ни контекстно-зависимыми, ни неукорачивающими (тип 1), поскольку могут содержать правила вида 《А -> 入》,недопустимые в типе 1.
Одна и та же грамматика в общем случае может быть отнесена к нескольким классификационным типам (например, как уже было сказано, все без исключения грамматики могут быть отнесены к типу 0). Для классификации грамматики всегда выбирают максимально возможный тип, к которому она может быть отнесена. Сложность грамматики обратно пропорциональна номеру типа, к которому относится грамматика. Грамматики, которые относятся только к типу 0, являются самыми сложными, а грамматики, которые можно отнести к типу 3, — самыми простыми.
Классификация языков
Языки классифицируются в соответствии с типами грамматик, с помощью которых они заданы. Причем поскольку один и тот же язык в общем случае может быть задан сколь угодно большим количеством грамматик, которые могут относиться к различным классификационным типам, то для классификации самого языка среди всех его грамматик выбирается грамматика с максимально возможным классификационным типом. Например, если язык L может быть задан грамматиками G] и G2, относящимися к типу 1 (контекстно-зависимые), грамматикой G3, относящейся к типу 2 (контекстно-свободные) и грамматикой G4, относящейся к типу 3 (регулярные), то сам язык должен быть отнесён к типу 3 и является регулярным языком.
От классификационного типа языка зависит не только то, с помощью какой грамматики можно построить предложения этого языка, но также и то, насколько сложно распознать эти предложения. Распознать предложения — значит построить распознаватель для языка (третий способ задания языка). Классификация распознавателей рассмотрена далее, здесь же можно указать, что сложность распознавателя языка напрямую зависит от классификационного типа, к которому относится язык.
Сложность языка убывает с возрастанием номера классификационного типа языка. Самыми сложными являются языки типа 0, самыми простыми — языки типа 3. Согласно классификации грамматик, также существует четыре типа языков.
Тип О: языки с фразовой структурой
Это самые сложные языки, которые могут быть заданы только грамматикой, относящейся к типу 0. Для распознавания цепочек таких языков требуются вычислители, равномощные машине Тьюринга. Поэтому можно сказать, что если язык относится к типу 0, то для него невозможно построить компилятор, который гарантированно выполнял бы разбор предложений языка за ограниченное время на основе ограниченных вычислительных ресурсов.
К сожалению, практически все естественные языки общения между людьми, строго говоря, относятся именно к этому типу языков. Дело в том, что структура и значение фразы естественного языка может зависеть не только от контекста данной фразы, но и от содержания того текста, где эта фраза встречается. Одно и то же слово в естественном языке может не только иметь разный смысл в зависимости от контекста, но и играть различные роли в предложении. Именно поэтому столь велики сложности в автоматизации перевода текстов, написанных на естественных языках, а также отсутствуют (и, видимо, никогда не появятся) компиляторы, которые бы воспринимали программы на основе таких языков.
Далее языки с фразовой структурой рассматриваться не будут.
Тип 1: контекстно-зависимые (КЗ) языки
Тип 1 — второй по сложности тип языков. В общем случае время на распознавание предложений языка, относящегося к типу 1, экспоненциально зависит от длины исходной цепочки символов.
Языки и грамматики, относящиеся к типу 1, применяются в анализе и переводе текстов на естественных языках. Распознаватели, построенные на их основе, позволяют анализировать тексты с учетом контекстной зависимости в предложениях входного языка (но они не учитывают содержание текста, поэтому в общем случае для точного перевода с естественного языка требуется вмешательство человека). На основе таких грамматик может выполняться автоматизированный перевод с одного естественного языка на другой, ими могут пользоваться сервисные функции проверки орфографии и правописания в языковых процессорах. В компиляторах КЗ-языки не используются, поскольку языки программирования имеют более простую структуру, поэтому здесь они подробно не рассматриваются.
Тип 2: контекстно-свободные (КС) языки
КС-языки лежат в основе синтаксических конструкций большинства современных языков программирования, на их основе функционируют некоторые довольно сложные командные процессоры, допускающие управляющие команды цикла и условия.
В общем случае время на распознавание предложений языка, относящегося к типу 1, полиномиально зависит от длины входной цепочки символов (в зависимости от класса языка это либо кубическая, либо квадратичная зависимость). Однако среди КС-языков существует много классов языков, для которых эта зависимость линейна. Практически все языки программирования можно отнести к одному из таких классов.
КС-языки подробно рассматриваются в главе 4 «Синтаксические анализаторы» данного учебника.
Тип 3: регулярные языки
Регулярные языки — самый простой тип языков. Поэтому они являются самым широко используемым типом языков в области вычислительных систем. Время на распознавание предложений регулярного языка линейно зависит от длины входной цепочки символов.
Как уже было сказано выше, регулярные языки лежат в основе простейших конструкций языков программирования (идентификаторов, констант и т. п.), кроме того, на их основе строятся многие мнемокоды машинных команд (языки ассемблеров), а также командные процессоры, символьные управляющие команды и другие подобные структуры.
Регулярные языки — очень удобное средство. Для работы с ними можно использовать регулярные множества и выражения, конечные автоматы. Регулярные языки подробно рассматриваются в главе 3 «Лексические анализаторы».
Классификация распознавателей
Как было показано ранее, классификация распознавателей определяет сложность алгоритма работы распознавателя. Но сложность распознавателя также напрямую связана с типом языка, входные цепочки которого может принимать (допускать) распознаватель.
Выше были определены четыре основных типа языков. Доказано, что для каждого из этих типов языков существует свой тип распознавателя с определенным составом компонентов и, следовательно, с заданной сложностью алгоритма работы. Для языков с фразовой структурой (тип 0) необходим распознаватель, равномощный машине Тьюринга — недетерминированный двусторонний автомат, имеющий неограниченную внешнюю память. Поэтому для языков данного типа нельзя гарантировать, что за ограниченное время на ограниченных вычислительных ресурсах распознаватель завершит работу и примет решение о том, принадлежит или не принадлежит входная цепочка заданному языку. Отсюда можно заключить, что практического применения языки с фразовой структурой не имеют.
Для контекстно -зависимых языков (тип 1) распознавателями являются двусторонние недетерминированные автоматы с линейно ограниченной внешней памятью. Алгоритм работы такого автомата в общем случае имеет экспоненциальную сложность — количество шагов (тактов), необходимых автомату для распознавания входной цепочки, экспоненциально зависит от длины этой цепочки. Следовательно, и время, необходимое на разбор входной цепочки по заданному алгоритму, экспоненциально зависит от длины входной цепочки символов.
Такой алгоритм распознавателя уже может быть реализован в программном обеспечении компьютера — зная длину входной цепочки, всегда можно сказать, за какое максимально возможное время будет принято решение о принадлежности цепочки данному языку и какие вычислительные ресурсы для этого потребуются. Однако экспоненциальная зависимость времени разбора от длины цепочки существенно ограничивает применение распознавателей для контекстно-зависимых языков. Как правило, такие распознаватели применяются для автоматизированного Перевода и анализа текстов на естественных языках, когда временные ограничения на разбор текста несущественны (следует также напомнить, что поскольку естественные языки более сложны, чем контекстно-зависимый тип, то после такой обработки часто требуется вмешательство человека).
В рамках этого учебника контекстно-зависимые языки не рассматриваются.
Для контекстно-свободных языков (тип 2) распознавателями являются односторонние недетерминированные автоматы с магазинной (стековой) внешней памятью — МП-автоматы. При простейшей реализации алгоритма работы такого автомата он имеет экспоненциальную сложность, однако путем некоторых усовершенствований алгоритма можно добиться полиномиальной (кубической) зависимости времени, необходимого на разбор входной цепочки, от длины этой цепочки. Следовательно, можно говорить о полиномиальной сложности распознавателя для КС-языков.
Среди всех КС-языков можно выделить класс детерминированных КС-языков, распознавателями для которых являются детерминированные автоматы с магазинной (стековой) внешней памятью — ДМП-автоматы. Для таких языков существует алгоритм работы распознавателя с квадратичной сложностью.
Среди всех детерминированных КС-языков существуют такие классы языков, для которых возможно построить линейный распознаватель — распознаватель, у которого время принятия решения о принадлежности цепочки языку имеет линейную зависимость от длины цепочки. Именно эти языки представляют интерес при построении компиляторов. Синтаксические конструкции практически всех существующих языков программирования могут быть отнесены к одному из таких классов языков. Поэтому в главе, посвященной синтаксическим анализаторам, в первую очередь будет уделено внимание именно этим классам языков. Тем не менее следует помнить, что только синтаксические конструкции языков программирования допускают разбор с помощью распознавателей КС-языков. Сами языки программирования, как уже было сказано, не могут быть полностью отнесены к типу КС-языков, поскольку предполагают контекстную зависимость в тексте исходной программы (например такую как необходимость предвари-
тельного описания переменных). Поэтому кроме синтаксического разбора все компиляторы предполагают дополнительный семантический анализ текста исходной программы. Этого можно было бы избежать, если построить компилятор на основе контекстно-зависимого распознавателя, но скорость работы такого компилятора была бы недопустимо низка, поскольку время разбора в таком варианте будет экспоненциально зависеть от длины исходной программы. Комбинация из распознавателя КС-языка и дополнительного семантического анализатора является более эффективной с точки зрения скорости разбора исходной программы. Для регулярных языков (тип 3) распознавателями являются односторонние недетерминированные автоматы без внешней памяти — конечные автоматы (КА). Это очень простой тип распознавателя, который предполагает линейную зависимость времени разбора входной цепочки от ее длины. Кроме того, конечные автоматы имеют важную особенность: любой недетерминированный КА всегда может быть преобразован в детерминированный. Это обстоятельство существенно упрощает разработку программного обеспечения, обеспечивающего функционирование распознавателя.
Простота и высокая скорость работы распознавателей определяют широкую область применения регулярных языков.
В компиляторах распознаватели на основе регулярных языков используются для лексического анализа текста исходной программы — выделения в нем простейших конструкций языка (лексем), таких как идентификаторы, строки, константы и т. п. Это позволяет существенно сократить объем исходной информации и упрощает синтаксический разбор программы. Более подробно взаимодействие лексического и синтаксического анализаторов текста программы рассмотрено дальше, в главе, посвященной лексическим анализаторам.
Кроме компиляторов регулярные языки находят применение еще во многих областях, связанных с разработкой программного обеспечения. На их основе функционируют многие командные процессоры как в системном, так и в прикладном программном обеспечении. Для регулярных языков существуют развитые математически обоснованные методы, которые позволяют облегчить создание распознавателей. Они положены в основу существующих программных средств, которые позволяют автоматизировать этот процесс.
Регулярные языки и связанные с ними математические методы рассматриваются в главе «Лексические анализаторы» данного учебника.
Примеры классификации языков и грамматик
Классификация языков идет от простого к сложному. Если мы имеем дело с регулярным языком, то можно утверждать, что он также является и контекстно-свободным, и контекстно-зависимым и даже языком с фразовой структурой. В то же время известно, что существуют КС-языки, которые не являются регулярными, и существуют КЗ-языки, которые не являются ни регулярными, ни контекстносвободными.
Далее приводятся примеры некоторых языков указанных типов.
Рассмотрим в качестве первого примера ту же грамматику для целых десятичных чисел со знаком Gl{0.1,2,3.4.5,6,7.8,9,-,+}.{S.T,F},Pl,S)：'
Pl：
Т т F I TF
F->0|l|2|3|4|5|6|7|8|9
По структуре своих правил данная грамматика G1 относится к контекстно-свободным грамматикам (тип 2). Конечно, ее можно отнести и к типу 0, и к типу 1, но максимально возможным является именно тип 2, поскольку к типу 3 эту грамматику отнести никак нельзя: строка Т -» F | TF содержит правило Т — TF, которое недопустимо для типа 3, и хотя все остальные правила этому типу соответствуют, одного несоответствия достаточно.
Для того же самого языка (целых десятичных чисел со знаком) можно построить и другую грамматику Gl' ({0.1,2,3,4.5.6.7.8.9,-.+} .{S.T} ,РГ ,S):
Pl' •
S т Т I +Т 丨-Т
Т - 0 丨 丨 2 丨 3 I 4 I 5 I 6 I 7 丨 8 I 9 I ОТ I IT 12Tl ЗТ 14Tl 5T 16Tl 7T I 8T I 9T
По структуре своих правил эта грамматика G1' является праволинейной и может быть отнесена к регулярным грамматикам (тип 3).
Для этого же языка можно построить эквивалентную леволинейную грамматику (тип 3) G1, '((0.1,2,3.4.5,6.7,8,9.-.+}.[5 5},Р1".5):
Pl".・
T…
S ТО I T1 I Т2 I ТЗ I I Т5 I Тб I Т7 I Т8 I T9 I SO I SI I S2 I S3 I S4 I
S5 I S6 I S7 i S8 I S9
Следовательно, язык LI целых десятичных чисел со знаком, заданный грамматиками Gl, G1' и G1'', относится к регулярным языкам (тип 3).
В качестве второго примера возьмем грамматику G2({0,l},{A.S},P2,S) с правилами Р2:
S т 0А1 ОА т 00А1 A —入
Эта грамматика относится к типу 0. Она определяет язык, множество предложений которого можно было бы записать так: L(G2) = {Onln | n > 0}.
Для этого же языка можно построить также контекстно-зависимую грамматику G2'({0,l},{A,S},P2'.S) с правилами Р2':
S -> 0А1 I 01
ОА т 00А1 I 001
Однако для того же самого языка можно использовать и контекстно-свободную грамматику G2'' ({0,1}, {S} .Р2'' ,S) с правилами Р2":
S -> 0S1 I 01
Следовательно, язык L2 = {Onln | п > 0} является контекстно-свободным (тип 2).
В третьем примере рассмотрим грамматику G3({a,b.c}, {B.C.D.S} .P3.S) с правилами РЗ:
S -> BD
В -> аВЬС I ab
СЬ т ЬС
CD т De
bDc -> bcc%
abD -> abc
Эта грамматика относится к типу 1. Очевидно, что она является неукорачивающей. Она определяет язык, множество предложений которого можно было бы записать так: L(G3) = {anbnen | n > 0}. Известно, что этот язык не является КС-языком, поэтому для него нельзя построить грамматики типов 2 или 3.
Но для того же самого языка можно построить КЗ-грамматику G3'({d,b.c}.{B, C.D.E.F.S} ,РЗ', S) с правилами РЗ':
Е ^——— с с с Е с с с ffcccEEC Е с SAЕ ^——— с с с Е с с с ffcccEEC Е с SA
Е ^
——— с с с Е с с с ffcccEEC Е с SA
Е ^
——— с с с Е с с с ffcccEEC Е с SA
Язык L3 - {dnbncn I п > 0} является контекстно-зависимым (тип 1).
Конечно, для произвольного языка, заданного некоторой грамматикой, в общем случае довольно сложно определить его тип. Не всегда можно так просто построить грамматику максимально возможного типа для произвольного языка. К тому же при строгом определении типа требуется еще доказать, что две грамматики (первоначально имеющаяся и вновь построенная) эквивалентны, а также то, что для того же языка не существует грамматики с большим по номеру типом. Это нетривиальная задача, которую не так легко решить.
Для многих языков и, в частности, для КС-языков и регулярных языков, существуют специальным образом сформулированные утверждения, которые позволяют проверить принадлежность языка к указанному типу. Такие утверждения (леммы) можно найти в [4, т. 1, 15, 28]. Тогда для произвольного языка достаточно лишь доказать нужную лемму и после этого можно утверждать,
что данный язык относится к тому или иному типу. Преобразование грамматик в этом случае не требуется.
Тем не менее иногда возникает задача построения для имеющегося языка грамматики более простого типа, чем данная. И даже в том случае, когда тип языка уже известен, эта задача в общем случае не имеет формального решения (проблема преобразования грамматик рассматривается далее).
Цепочки вывода.
Сентенциальная форма
Вывод. Цепочки вывода
Выводом называется процесс порождения предложения языка на основе правил определяющей язык грамматики. Чтобы дать формальное определение процессу вывода, необходимо ввести еще несколько дополнительных понятий.
Цепочка 0 = 8^82 называется непосредственно выводимой из цепочки а = 81(о82 в грамматике 4(Ct,VN,P,S), V = VTuVN, 8b % 32 g V\ со g V+, если в грамматике G существует правило: со -> у g Р. Непосредственная выводимость цепочки 0 из цепочки а обозначается так: а п 0. Согласно определению, при выводе а п 0 выполняется подстановка подцепочки у вместо подцепочки со. Иными словами, цепочка 0 выводима из цепочки а в том случае, если можно взять несколько символов в цепочке а, заменить их на другие символы согласно некоторому правилу грамматики и получить цепочку р.
В формальном определении непосредственной выводимости любая из цепочек В[ или 32 (а равно и обе эти цепочки) может быть пустой. В предельном случае вся цепочка а может быть заменена на цепочку р, тогда в грамматике G должно существовать правило: а -> 0еР.
Цепочка 0 называется выводимой из цепочки а (обозначается а п* 0) в том случае, если выполняется одно из двух условий:
0 непосредственно выводима из а (а 0);
三 у такая, что у выводима из а и р непосредственно выводима из у (а п* у и у п 0).
Это рекурсивное определение выводимости цепочки. Суть его заключается в том, что цепочка 0 выводима из цепочки а, если а п 0 или же если можно построить последовательность непосредственно выводимых цепочек от а к р следующего вида: а n Yi =>...=> % п…n yn => р, n > 1. В этой последовательности каждая последующая цепочка % непосредственно выводима из предыдущей цепочки %一卜 Такая последовательность непосредственно выводимых цепочек называется выводом, или цепочкой вывода, Каждый переход от одной непосредственно выводимой цепочки к следующей в цепочке вывода называется шагом вывода. Очевидно, что шагов вывода в цепочке вывода всегда на один больше, чем промежуточных цепочек. Если цепочка р непосредственно выводима из цепочки а: а => р, то имеется всего один шаг вывода.
Если цепочка вывода из а к Р содержит одну или более промежуточных цепочек (два или более шагов вывода), то она имеет специальное обозначение а =>+ 0 (говорят, что цепочка 0 нетривиально выводима из цепочки а). Если количество шагов вывода известно, то его можно указать непосредственно у знака выводимости цепочек. Например, запись а =>4 р означает, что цепочка р выводится из цепочки а за 4 шага вывода1.
Возьмем в качестве примера ту же грамматику для целых десятичных чисел со 3HaKOMG({0.1,2,3,4,5,6,7.8.9,-,+}.{S,T.F}.P.S)：
Р:
S -> Т I +Т I
Т - F I TF
F->0|l|2|3|4|5|6|7|8|9
Построим в ней несколько произвольных цепочек вывода (для понимания каждого шага вывода подцепочка, для которой выполняется подстановка, выделена жирным шрифтом):
S n -Т n -TF n -TFF n -FFF n -4FF n -47F п -479-
S => Т => TF => Т8 => F8 => 18
Т => TF => ТО => TF0 п ТБО n F50 п 350
TFT n TFFT n TFFF n FFFF n 1FFF n 1FF4 n 10F4 п 1004
F = 5
Получим следующие выводы:
S =>* -47 9 или S =>+ -47 9 или S =>7 -47 9
S =>* 18 или S =>+ 18 или S =>5 18
Т =>* 350 или Т п+ 350 или Т =>6 350
TFT =>* 1004 или TFT =>+ 1004 или TFT =>7 1004
F =>* 5 или F => 1 5 (утверждение F =>+ 5 неверно!)一
Все эти выводы построены на основе грамматики G. В принципе, в этой грамматике (как практически и в любой другой грамматике реального языка) можно построить сколь угодно много цепочек вывода.
Возьмем в качестве второго примера грамматику G3({a,b,c},{B.C.D,S},P3,S) с правилами РЗ, которая уже рассматривалась выше:
S ВО
В -> аВЬС I ab
СЬ -> ЬС
CD т Ос
ЬОс т Ьсс
abD -> abe
В литературе встречается также обозначение: а п° р, которое означает, что цепочка а выводима из цепочки р за 0 шагов — иными словами, в таком случае этл цепочки равны: а = р. Подразумевается, что обозначение вывода а=>* р допускает и такое толкование — включает в себя вариант а =>° р.
Как было сказано ранее, она задает язык L(G3) = {anbncn | n > 0}. Рассмотрим пример вывода предложения aaaabbbbcccc языка L(G3) на основе грамматики G3:
S => BD => aBbCD => aaBbCbCD => aasBbCbCbCD n saaabbCbCbCD n aaaabbbCCbCD n aaaabbbCbCCD n aaaabbbbCCCD n aaasbbbbCCDc = aaaabbbbCDcc о aaaabbbbDccc n aaaabbbbcccc
Тогда для грамматики G3 получаем вывод: S n* aaaabbbbcccc.
Иногда, чтобы пояснить ход вывода, над стрелкой, обозначающей каждый шаг вывода, пишут обозначение того правила грамматики, на основе которого сделан этот шаг (для этой цели правила грамматики проще всего просто пронумеровать в порядке их следования). Грамматика, рассмотренная в приведенных здесь примерах, содержит всего 15 правил, и на каждом шаге в цепочках вывода можно понять, на основании какого правила сделан этот шаг (читатели могут легко сделать это самостоятельно), но в более сложных случаях пояснения к шагам вывода с указанием номеров правил грамматики могут быть весьма полезными.
Сентенциальная форма грамматики. Язык, заданный грамматикой
Вывод называется законченным, если на основе цепочки 0, полученной в результате вывода, нельзя больше сделать ни одного шага вывода. Иначе говоря, вывод называется законченным, если цепочка Р，полученная в результате вывода, пустая или содержит только терминальные символы грамматики G(VT,VN,P,S): PeVT*. Цепочка 0, полученная в результате законченного вывода, называется конечной цепочкой вывода.
В рассмотренном выше примере все построенные выводы являются законченными, а, например, вывод S n* -4FF (из первой цепочки в примере) будет незаконченным.
Цепочка символов awV* называется сентенциальной формой грамматики G(VT, VN, P,S), V = VTuVN, если она выводима из целевого символа грамматики S: S п* а. Если цепочка awVT* получена в результате законченного вывода, то она называется конечной сентенциальной формой.
Из рассмотренного выше примера можно заключить, что цепочки символов -479 и 18 являются конечными сентенциальными формами грамматики целых десятичных чисел со знаком, так как существуют выводы S =>* -479 и S =>* 18 (выводы 1 и 2). Цепочка F8 из вывода 2, например, тоже является сентенциальной формой, поскольку справедливо S n* F8, но она не является конечной цепочкой вывода. В то же время, в выводах 3, 4 и 5 примера явно не присутствуют сентенциальные формы. На самом деле, цепочки 350, 1004 и 5 тоже являются конечными сентенциальными формами. Чтобы доказать это, необходимо просто построить другие цепочки вывода (например, для цепочки 5 строим: S=>T=>F=>5h получаем S =>* 5). А вот цепочка TFT (вывод 4) не выводима из целевого символа грамматики S, а потому сентенциальной формой не является.
Язык L, заданный грамматикой G(VT,VN,P,S), — это множество всех конечных сентенциальных форм грамматики G. Язык L, заданный грамматикой G, обозна-
чается как L(G). Очевидно, что алфавитом такого языка L(G) будет множество терминальных символов грамматики VT, поскольку все конечные сентенциальные формы грамматики — это цепочки над алфавитом VT.
Следует помнить, что две грамматики G(VT,VN,P,S) и G'(VT,VN',P',S') называются эквивалентными, если эквивалентны заданные ими языки: L(G) = L(G'). Очевидно, что эквивалентные грамматики должны иметь, по крайней мере, пересекающиеся множества терминальных символов VTnVT' н 0 (как правило, эти множества даже совпадают: VT = VT) а вот множества нетерминальных символов, правила грамматики и целевой символ у них могут кардинально отличаться.
Левосторонний и правосторонний выводы
Вывод называется левосторонним, если в нем на каждом шаге вывода правило грамматики применяется всегда к крайнему левому нетерминальному символу в цепочке. Другими словами, вывод называется левосторонним, если на каждом шаге вывода происходит подстановка цепочки символов на основании правила грамматики вместо крайнего левого нетерминального символа в исходной цепочке. Аналогично, вывод называется правосторонним, если в нем на каждом шаге вывода правило грамматики применяется всегда к крайнему правому нетерминальному символу в цепочке.
Если рассмотреть цепочки вывода из того же примера, то в нем выводы 1 и 5 являются левосторонними, выводы 2, 3 и 5 — правосторонними (вывод 5 одновременно является и лево- и правосторонним), а вот вывод 4 не является ни левосторонним, ни правосторонним.
Для грамматик типов 2 и 3 (КС-грамматик и регулярных грамматик) для любой сентенциальной формы всегда можно построить левосторонний или правосторонний выводы. Для грамматик других типов это не всегда возможно, так как по структуре их правил не всегда можно выполнить замену крайнего левого или крайнего правого нетерминального символа в цепочке.
А вот рассмотренный выше вывод S => * aaaabbbbcccc для грамматики G3, задающей язык L(G3) = {Onln I n > 0}, не является ни левосторонним, ни правосторонним. Грамматика относится к типу 1, и в данном случае для нее нельзя построить такой вывод, на каждом шаге которого только один нетерминальный символ заменялся бы на цепочку символов.
Дерево вывода. Методы построения дерева вывода
Деревом вывода грамматики G(VT,VN,P,S) называется дерево (граф), которое соответствует некоторой цепочке вывода и удовлетворяет следующим условиям: □ каждая вершина дерева обозначается символом грамматики Ae(VTuVN);
корнем дерева является вершина, обозначенная целевым символом грамматики 一S;
листьями дерева (концевыми веришнами) являются вершины, обозначенные терминальными символами грамматики или символом пустой цепочки X;
если некоторый узел дерева обозначен нетерминальным символом AeVN, а связанные с ним узлы — символами bib?...!^； п > 0, Vn > i > 0: Ъ.е(VTuVNu{X}), то в грамматике G(VT,VNfP,S) существует правило A—>b1b2...bn w Р.
Из определения видно, что по структуре правил дерево вывода в указанном виде всегда можно построить только для грамматик типов 2 и 3 (контекстно-свободных и регулярных). Для грамматик других типов дерево вывода в таком виде можно построить не всегда (либо же оно будет иметь несколько иной вид).
На основе рассмотренного выше примера построим деревья вывода для цепочек вывода 1 и 2. Эти деревья приведены на рис. 1.3.
Рис. 1.3. Примеры деревьев вывода для грамматики целых десятичных чисел со знаком
Для того чтобы построить дерево вывода, достаточно иметь только цепочку вывода. Дерево вывода можно построить двумя способами: сверху вниз и снизу вверх. Для строго формализованного построения дерева вывода всегда удобнее пользоваться строго определенным выводом: либо левосторонним, либо правосторонним.
При построении дерева вывода сверху вниз построение начинается с целевого символа грамматики, который помещается в корень дерева. Затем в грамматике выбирается необходимое правило, и на первом шаге вывода корневой символ раскрывается на несколько символов первого уровня. На втором шаге среди всех концевых вершин дерева выбирается крайняя (крайняя левая — для левостороннего вывода, крайняя правая — для правостороннего) вершина, обозначенная нетерминальным символом, для этой вершины выбирается нужное правило грамматики, и она раскрывается на несколько вершин следующего уровня. Построение дерева заканчивается, когда все концевые вершины обозначены терминальными символами, в противном случае надо вернуться ко второму шагу и продолжить построение.
Построение дерева вывода снизу вверх начинается с листьев дерева. В качестве листьев выбираются терминальные символы конечной цепочки вывода, которые на первом шаге построения образуют последний уровень (слой) дерева. Построение дерева идет по слоям. На втором шаге построения в грамматике выбирается правило, правая часть которого соответствует крайним символам в слое дерева (крайним правым символам при правостороннем выводе и крайним левым — при левостороннем). Выбранные вершины слоя соединяются с новой вершиной, которая выбирается из левой части правила. Новая вершина попадает в слой дерева вместо выбранных вершин. Построение дерева закончено, если достигнута корневая вершина (обозначенная целевым символом), а иначе надо вернуться ко второму шагу и повторить его относительно полученного слоя дерева. Поскольку все известные языки программирования имеют нотацию записи «слева направо», компилятор также всегда читает входную программу слева направо (и сверху вниз, если программа разбита на несколько строк). Поэтому для построения дерева вывода методом «сверху вниз», как правило, используется левосторонний вывод, а для построения «снизу вверх» — правосторонний вывод. На эту особенность компиляторов стоит обратить внимание. Нотация чтения программ «слева направо» влияет не только на порядок разбора программы компилятором (для пользователя это, как правило, не имеет значения), но и на порядок выполнения операций — при отсутствии скобок большинство равноправных операций выполняются в порядке слева направо, а это уже имеет существенное значение.
Проблемы однозначности и эквивалентности грамматик
Однозначные и неоднозначные грамматики
Рассмотрим некоторую грамматику G({+,-.*./,(,),a,b},{S},P,S):
Р
S -> S+S I S-S | S*S I S/S I (S) I a I b
Видно, что представленная грамматика определяет язык арифметических выражений с четырьмя основными операциями (сложение, вычитание, умножение и деление) и скобками над операндами а и Ь. Примерами предложений этого языка могут служить: d*b+a, a*(a+b), а*Ь+а*а и т. д.
Возьмем цепочку а*Ь+а и построим для нее левосторонний вывод. Получится два варианта:
S n S+S о S*S+S n d*S+S n a*b+S = a*b+a
S => S*5n d*S n a*S+S n a*b+S n a*b+a
Каждому из этих вариантов будет соответствовать свое дерево вывода. Два варианта дерева вывода для цепочки а*Ь+а приведены на рис. 1.4.
Рис. 1.4. Два варианта дерева цепочки а*Ь+а вывода для неоднозначной грамматики арифметических выражений
С точки зрения формального языка, заданного грамматикой, не имеет значения, какая цепочка вывода и какое дерево вывода из возможных вариантов будут построены. Однако в реальных языках структура предложения и его значение (смысл) взаимосвязаны. Это справедливо как для естественных языков, так и для языков программирования. Дерево вывода (или цепочка вывода) является формой представления структуры предложения языка. Поэтому для языков программирования, которые несут смысловую нагрузку, имеет принципиальное значение то, какая цепочка вывода будет построена для того или иного предложения языка.
Например, если принять во внимание, что рассмотренная здесь грамматика определяет язык арифметических выражений, то с точки зрения семантики арифметических выражений порядок построения дерева вывода соответствует порядку выполнения арифметических действий. В арифметике, как известно, при отсутствии скобок умножение всегда выполняется раньше сложения (умножение имеет более высокий приоритет), но в рассмотренной выше грамматике это ниоткуда не следует — в ней все операции равноправны. Поэтому с точки зрения арифметических операций приведенная грамматика имеет неверную семантику — в ней нет приоритета операций, а кроме того, для равноправных операций не определен порядок выполнения (в арифметике принят порядок выполнения действий слева направо), хотя синтаксическая структура построенных с ее помощью выражений будет правильной.
Такая ситуация называется неоднозначностью в грамматике. Естественно, для построения компиляторов и языков программирования нельзя использовать грамматики, допускающие неоднозначности. Дадим более точное определение неоднозначной грамматики.
Грамматика называется однозначной, если для каждой цепочки символов языка, заданного этой грамматикой, можно построить единственный левосторонний (и единственный правосторонний) вывод. Или, что то же самое: грамматика называется однозначной, если для каждой цепочки символов языка, заданного этой грамматикой, существует единственное дерево вывода. В противном случае грамматика называется неоднозначной.
Рассмотренная в примере грамматика арифметических выражений, очевидно, является неоднозначной.
Проверка однозначности и эквивалентности грамматик
Поскольку грамматика языка программирования, по сути, всегда должна быть однозначной, то возникают два вопроса, которые необходимо в любом случае решить: □ как проверить, является ли данная грамматика однозначной?
□ если заданная грамматика является неоднозначной, то как преобразовать ее к однозначному виду?
Однозначность — это свойство грамматики, а не языка. Для некоторых языков, заданных неоднозначными грамматиками, иногда удается построить эквивалентную однозначную грамматику (однозначную грамматику, задающую тот же язык). Чтобы убедиться в том, что некоторая грамматика не является однозначной (является неоднозначной), согласно определению, достаточно найти в заданном ею языке хотя бы одну цепочку, которая бы допускала более чем один левосторонний или правосторонний вывод (как это было в рассмотренном примере). Однако не всегда удается легко обнаружить такую цепочку символов. Кроме того, если такая цепочка не найдена, мы не можем утверждать, что данная грамматика является однозначной, поскольку перебрать все цепочки языка невозможно — как правило, их бесконечное количество. Следовательно, нужны другие способы проверки однозначности грамматики.
.Если грамматика все же является неоднозначной, то необходимо попытаться преобразовать ее в однозначный вид. Например, для рассмотренной выше неоднозначной грамматики арифметических выражений над операндами а и Ь существует эквивалентная ей однозначная грамматика вида G' ({+,-,*,/.(,). a.b}.{S,TtE}.P'.S):
Р，
S -> S+T I S-Т I т Т -> Т*Е I Т/Е I Е Е -> ⑸ | а ! b
В этой грамматике для рассмотренной выше цепочки символов языка а*Ь+а возможен только один левосторонний вывод:
S n S+T n Т+Т n Т*Е+Т n Е*Е+Т n а*Е+Т n a*b+T n a*b+E n s*b+a
Этому выводу соответствует единственно возможное дерево вывода. Оно приведено на рис. 1.5. Видно, что хотя цепочка вывода несколько удлинилась, но приоритет операций в данном случае единственно возможный и соответствует их порядку в арифметике.
В таком случае необходимо решить две проблемы: во-первых, доказать что две имеющиеся грамматики эквивалентны (задают один и тот же язык); во-вторых, иметь возможность проверить, что вновь построенная грамматика является однозначной. Проблема эквивалентности грамматик в общем виде формулируется следующим образом: имеются две грамматики G и G', необходимо построить алгоритм, который бы позволял проверить, являются ли эти две грамматики эквивалентными. То есть надо проверить утверждение L(G) = L(G').
Рис. 1.5. Дерево вывода для однозначной грамматики арифметических выражений
К сожалению, доказано, что проблема эквивалентности грамматик в общем случае алгоритмически неразрешима. Это значит, что не только до сих пор не существует алгоритма, который бы позволял проверить, являются ли две заданные грамматики эквивалентными, но и доказано, что такой алгоритм в принципе не существует, а значит, он никогда не будет создан.
Точно так же неразрешима в общем виде и проблема однозначности грамматик. Это значит, что не существует (и никогда не будет существовать) алгоритм, который бы позволял для произвольной заданной грамматики G проверить, является ли она однозначной или нет. Аналогично, не существует алгоритма, который бы позволял преобразовать заведомо неоднозначную грамматику G в эквивалентную ей однозначную грамматику G'.
В общем случае вопрос об алгоритмической неразрешимости проблем однозначности и эквивалентности грамматик сводится к вопросу об алгоритмической неразрешимости проблемы, известной как «проблема соответствий Поста» [4, т. 1].
Неразрешимость проблем эквивалентности и однозначности грамматик в общем случае совсем не означает, что они не разрешимы вообще. Для многих частных случаев — например, для определенных типов и классов грамматик (в частности, для регулярных грамматик) — эти проблемы решены. Например, приведенная выше грамматика G' для арифметических выражений над операндами а и b относится к классу грамматик операторного предшествования из типа КС-грамматик, который будет рассмотрен далее. На основе этой грамматики возможно построить распознаватель в виде детерминированного расширенного МП-автомата, а потому можно утверждать, что она является однозначной (см. раздел «Восходящие распознаватели КС-языков без возвратов» главы 4).
Правила, задающие неоднозначность в грамматиках
В общем виде невозможно проверить, является ли заданная грамматика однозначной или нет. Однако для КС-грамматик существуют определенного вида правила, по наличию которых во всем множестве правил грамматики G(VT,VN,P,S) можно утверждать, что она является неоднозначной. Эти правила имеют следующий вид:
А-> АА | а
А -> АаА I Р
A f аА I 丨 у
А -> аА I аДрА | у
здесь AeVN; a,p,ye(VNuVT)*.
Если в заданной грамматике встречается хотя бы одно правило подобного вида (любого из приведенных вариантов), то доказано, что такая грамматика точно будет неоднозначной. Однако если подобных правил во всем множестве правил грамматики нет, это совсем не означает, что грамматика является однозначной. Такая грамматика может быть однозначной, а может и не быть. То есть отсутствие правил указанного вида (всех вариантов) — это необходимое, но не достаточное условие однозначности грамматики.
С другой стороны, установлены условия, при удовлетворении которым грамматика заведомо является однозначной. Они справедливы для всех регулярных и многих классов контекстно-свободных грамматик. Однако известно, что эти условия, напротив, являются достаточными, но не необходимыми для однозначности грамматик.
Например, в рассмотренном выше примере грамматики арифметических выражений с операндами аиЬ — G( {+,-.*,/,(,),a, b},{S},P,S) — во множестве правил Р, S -> S+S I S-S I S*S I S/S I (S) I a I b встречаются правила 2 типа (например, два правила: S —> S+S и S —> а). Поэтому данная грамматика являемся неоднозначной, что и было показано выше.
Контрольные вопросы и задачи
Вопросы
Дайте определение цепочки, языка. Какие операции можно выполнять над цепочками символов? Что такое синтаксис и семантика языка?
Какие из перечисленных ниже тождеств являются истинными для двух произвольных цепочек символов а и р, а какие нет:
|сф| = |а| + IPI = |ра|
ар = ра
№1 = |а|
(a2p2)R = (PRaR)2
(桟伏尸 (0R)2(aR)2
Какие существуют методы задания языков? Почему метод перечисления всех допустимых цепочек языка не находит практического применения?
Какие дополнительные вопросы необходимо решить при задании языка программирования? Почему любой язык программирования не является чисто формальным языком?
Кто (или что) для любого языка программирования выступает в роли генератора цепочек языка? Кто (или что) выступает в роли распознавателя цепочек?
Как формулируется задача разбора? Всегда ли она разрешима и как она решается?
Что такое грамматика языка? Дайте определение грамматики.
Как выглядит описание грамматики в форме Бэкуса—Наура? Какие еще формы описания грамматик существуют?
Почему в форме Бэкуса—Наура практически невозможно построить грамматику для реального языка так, чтобы она не содержала рекурсивных правил?
Что такое распознаватель? Какие виды распознавателей существуют?
И. Как классифицируются распознаватели? Как их классификация соотносится с классификацией языков и грамматик?
Какие типы грамматик выделяют по классификации Хомского? Как они между собой соотносятся?
Какие типы языков выделяют по классификации Хомского? Как классификация языков соотносится с классификацией грамматик?
Дайте определения выводимости цепочки, непосредственной выводимости, нетривиальной выводимости, длины вывода.
Что такое сентенциальная форма грамматики? Если язык, заданный грамматикой, представляет собой множество ее конечных сентенциальных форм, то что представляет собой множество всех сентенциальных форм грамматики?
Что такое левосторонний и правосторонний выводы? Можно ли построить еще какие-нибудь варианты цепочек вывода?
Задачи
Ниже даны различные варианты грамматик, определяющие язык десятичйых чисел с фиксированной точкой. Укажите, к какому типу относится каждая из этих грамматик. К какому типу относится сам язык десятичных чисел с фиксированной точкой?
GK.0,1,2,3.4,5,6,7.8,9}.{<число>,<цел>,<дроб>,<цифра>,<осн>,
<знак>}.Р1,<число>)
Р1.
<число> -> <знак><осн>
<знак> -> X I -
<осн> -> <цел> <дроб> I <цел >
<цел> -> <цифра> | <цифра><цифра>
<дроб> -> 入 I <цел>
<цифра><цифра> -> <цифра><цифра><цифра>
<цифра> ->0|1|2|3|4|5|6|7|8|9
G2({" ".+(-(0,1,2(3,4,5,6,7(8,9},{<число>-<чзсть>.<цифра>(<осн>},Р2 (<число>)
Р2
<ЧИСЛО> -> +<ОСН> I -<ОСН> I <осн>
<осн> — <часть> <часть> | <часть>. | <часть>
<часть> -> <цифра> | <цифра><цифра>
<цифра><цифра> -> <цифра><цифра><цифра>
<иифра> -0|1丨2丨3|4|5|6|7|8|9
G3({".",+,',0,1,2,3,4,5.6,7,8,9},{<число>,<часть>,<осн>},РЗ,<число>)
РЗ-
<ЧИСЛО> -> +<ОСН> I -<ОСН> I <осн>
<осн> — <часть> I <часть> | <осн>0 ) <осн>1 | <осн>2 | <осн>3 | <осн>4 |
<осн>5 I <осн>6 I <осн>7 | <осн>8 | <осн>9
<часть> ->0|1|2|3|4|5|6|7|8|9| <часть>0 | <часть>1 | <часть>2 I <часть>3 | <часть>4 | <часть>5 | <часть>6 | <часть>7 | <часть>8 | <часть>9
G4({".0,1,2,3,4.5,6.7,8,9},{<знак>,<число>,<часть>.<осн>},Р4,<число>)
Р4:
<число> -> <часть> | <часть>. | <число>0 | <число>1 | <число>2 | <число>3 | <число>4 I <число>5 | <число>6 | <число>7 | <число>8 | <число>9
<часть> -> <знак>。 | <знак>1 | <знак>2 | <знак>3 | <знак>4 | <знак>5 | <знак>6 |
<знак>7 I <знак>8 | <знак>9 | <часть>0 | <часть>1 | <часть>2 | <часть>3 |
<часть>4 I <часть>5 | <часть>6 | <часть>7 | <часть>8 | <часть>9
<знак> ->х| + |-
С5({".",+1-,0.1,2,3.4.5,6,7,8.9}.{<знак>,<число>.<часть>,<осн>}.Р5.<число>)
Р5:
<число> т <часть> | <осн>0 | <осн>1 | <осн>2 | <осн>3 | <осн>4 | <осн>5 | <осн>6 I <осн>7 I <осн>8 | <осн>9 | <часть>0 | <часть>1 | <часть>2 | <часть>3 | <часть>4 I <часть>5 | <часть>6 | <часть>7 | <часть>8 | <часть>9
<осн> -> <часть>. I <осн>0 | <осн>1 | <осн>2 | <осн>3 | <осн>4 | <осн>5 |
<осн>6 I <осн>7 I <осн>8 | <осн>9
<часть> -^0|1|2|3|4|5|6|7|8|9| <знак>0 | <знак>1 | <знак>2 | <знак>3 I <знак>4 I <знак>5 | <знак>6 | <знак>7 | <знак>8 | <знак>9 | <часть>0 | <часть>1 I <часть>2 | <часть>3 | <часть>4 | <часть>5 | <часть>6 | <часть>7 | <часть>8 I <часть>9
<знак> т + I -
Докажите, что если для некоторой цепочки языка, заданного грамматикой, существует единственный левосторонний вывод, то для нее существует и единственное дерево вывода.
Язык десятичных чисел с фиксированной точкой, рассмотренный в задаче № 1, содержит цепочки -83, 239, 10.4. Постройте цепочки вывода для каждой из этих трех цепочек символов на основе предложенных в задаче № 1 грамматик. Какие из предложенных пяти грамматик являются неоднозначными?
Язык десятичных чисел с фиксированной точкой, рассмотренный выше в задаче № 1, не содержит цепочек вида 29 или 104. Перестройте любую из предложенных в задаче № 1 пяти грамматик так, чтобы заданный ею новый язык допускал такого рода цепочки,
Поездом называется произвольная последовательность локомотивов и вагонов, начинающаяся с локомотива. Постройте грамматику для понятия <поезд> в форме Бэкуса—Наура, считая что понятия <локомотив> и <вагон> являются терминальными символами. Модернизируйте грамматику для любого из следующих условий:
Q все локомотивы должны быть сосредоточены в начале поезда;
Q поезд начинается с локомотива и заканчивается локомотивом (попробуйте построить регулярную грамматику);
О поезд не должен содержать два локомотива либо два вагона подряд.
Насколько сложно построить в форме Бэкуса—Наура определение поезда (согласно задаче № 5), содержащего не более 60 вагонов? Постройте такое определение в форме грамматики с метасимволами. Распространите его на одно из предложенных в задаче № 5 дополнительных условий.
Постройте вывод для цепочки aaaabbbbcccc в грамматике G({a.b,c}.{B(C.D,S},P,S) с правилами Р:
S abc I АЕ
А —> dABC I аВС
СВС т CDC
CDC - BDC
BDC — ВСС
ССЕ — CFE
CFE - CFc
CFc - CEc
bB — bb bCE - bCc
Дана грамматика условных выражений G({" " ,i ,f ,t,h,e,n,l ,s,b,a}. {E} .P.E) с правилами:
P
E — if b then E else E, | if b then E, | a
He строя цепочек вывода, покажите, что эта грамматика является неоднозначной. Проверьте это, построив некоторую цепочку вывода. Попробуйте построить эквивалентную ей однозначную грамматику.
Глава 2 Основные принципы построения трансляторов
Выше были рассмотрены теоретические вопросы, связанные с теорией формальных языков и грамматик. В этой главе пойдет речь о том, как эти теоретические аспекты применяются на практике при построении трансляторов.
Трансляторы, компиляторы и интерпретаторы — общая схема работы
Определения транслятора, компилятора, интерпретатора
Для начала дадим несколько определений — что же все-таки такое есть уже многократно упоминавшиеся трансляторы и компиляторы.
Формальное определение транслятора
Транслятор — это программа, которая переводит программу на исходном (входном) языке в эквивалентную ей программу на результирующем (выходном) языке. В этом определении слово «программа» встречается три раза, и это не ошибка и не тавтология. В работе транслятора действительно участвуют три программы. Во-первых, сам транслятор является программой1. То есть транслятор — это часть программного обеспечения (ПО), он представляет собой набор машинных
Teopei ически возможна реализация транслятора с помощью аппаратных средств. Автору встречались такого рода разработки, однако широкое практическое применение их не известно В таком случае н все составные части транслятора могут быть реализованы в виде аппаратных средств и их фрагментов — вот тогда схема распознавателя, который является составной частью транслятора, может получить вполне практическое воплощение!
команд и данных и выполняется компьютером, как и все прочие программы в рамках операционной системы (ОС). Все составные части транслятора представляют собой динамически загружаемые библиотеки или модули этой программы со своими входными и выходными данными.
Во-вторых, исходными данными для работы транслятора служит программа на исходном языке программирования — некоторая последовательность предложений входного языка. Эта программа называется входной, или исходной, программой. Обычно это символьный файл, но этот файл должен содержать текст программы, удовлетворяющий синтаксическим и семантическим требованиям входного языка. Кроме того, этот файл несет в себе некоторый смысл, определяемый семантикой входного языка. Часто файл, содержащий текст исходной программы, называют исходным файлом.
В-третьих, выходными данными транслятора является программа на результирующем языке. Эта программа называется результирующей программой. Результирующая программа строится по синтаксическим правилам выходного языка транслятора, а ее смысл определяется семантикой выходного языка.
Важным пунктом в определении транслятора является эквивалентность исходной и результирующей программ. Эквивалентность этих двух программ означает совпадение их смысла с точки зрения семантики входного языка (для исходной программы) и семантики выходного языка (для результирующей программы). Без выполнения этого требования сам транслятор теряет всякий практический смысл. Итак, чтобы создать транслятор, необходимо, прежде всего, выбрать входной и выходной языки. С точки зрения преобразования предложений входного языка в эквивалентные им предложения выходного языка транслятор выступает как переводчик. Например, трансляция программы с языка С в язык ассемблера по сути ничем не отличается от перевода, скажем, с русского языка на английский, с той лишь разницей, что сложность языков несколько иная (о том, почему не существует трансляторов с естественных языков, сказано в разделе «Классификация языков и грамматик» в предыдущей главе). Поэтому и само слово «транслятор» (англ.: translator) означает «переводчик».
Результатом работы транслятора будет результирующая программа, но только в том случае, если текст исходной программы является правильным — не содержит ошибок с точки зрения синтаксиса и семантики входного языка. Если исходная программа неправильная (содержит хотя бы одну ошибку), то результатом работы транслятора будет сообщение об ошибке (как правило, с дополнительными пояснениями и указанием места ошибки в исходной программе). В этом смысле транслятор сродни переводчику, например, с английского, которому подсунули неверный текст.
Определение компилятора. Отличие компилятора от транслятора
Кроме понятия «транслятор» широко употребляется также близкое ему по смыслу понятие «компилятор».
Компилятор — это транслятор, который осуществляет перевод исходной программы в эквивалентную ей результирующую программу на языке машинных команд или на языке ассемблера.
Таким образом, компилятор отличается от транслятора лишь тем, что его результирующая программа всегда должна быть написана на языке машинных кодов или на языке ассемблера. Результирующая программа транслятора, в общем случае, может быть написана на любом языке — возможен, например, транслятор программ с языка Pascal на язык С.
ВНИМАНИЕ ■
Всякий компилятор является транслятором, но не наоборот — не всякий транслятор будет компилятором. Например, упомянутый выше транслятор с языка Pascal на С компилятором не является1.
Результирующая программа компилятора называется объектной программой, или объектным кодом, а исходную программу в этом случае часто называют исходным кодом. Файл, в который записана объектная программа, обычно называется объектным файлом. Даже в том случае, когда результирующая программа порождается на языке машинных команд, между объектной программой (объектным файлом) и исполняемой программой (исполняемым файлом) есть существенная разница. Порожденная компилятором программа не может непосредственно выполняться на компьютере (более подробно об этом рассказано в главе «Современные системы программирования»).
Само слово «компилятор» происходит от английского термина《compiler» («составитель», «компоновщик»). Термин обязан своему происхождению способности компиляторов составлять объектную программу из фрагментов машинных кодов, соответствующих синтаксическим конструкциям исходной программы (то, как это происходит, описано в главе «Генерация и оптимизация кода»). Поскольку первоначально компиляторы ничего другого делать не умели, то этот термин и закрепился за ними.
Результирующая программа, созданная компилятором, строится на языке машинных кодов или ассемблера, то есть на языках, которые обязательно ориентированы на определенную вычислительную систему. Следовательно, такая результирующая программа всегда предназначена для выполнения на вычислительной системе с определенной архитектурой.
ПРИМЕЧАНИЕ
Следует упомянуть, что в современных системах программирования существуют компиляторы, в которых результирующая программа создается не на языке машинных команд и не на языке ассемблера, а на некотором промежуточном языке. Сам по себе этот промежуточный язык не может непосредственно исполняться на компьютере, а требует специального промежуточного интерпретатора для выполнения написанных на нем программ. Хотя в данном случае термин «транслятор» был бы, наверное, более правильным, в литературе употребляется понятие «компилятор», поскольку промежуточный язык является языком очень низкого уровня, будучи родственным машинным командам и языкам ассемблера.
В некоторых литературных источниках эти два понятия не разделяют между собой, хотя разница между ними все-таки существует.
Вычислительная система, на которой выполняется результирующая (объектная) программа, созданная компилятором, называется целевой вычислительной системой, В понятие целевой вычислительной системы входит не только архитектура аппаратных средств компьютера, но и операционная система, а зачастую также и набор динамически подключаемых библиотек, которые необходимы для выполнения объектной программы. При этом следует помнить, что объектная программа ориентирована на целевую вычислительную систему, но не может быть непосредственно выполнена на ней без дополнительной обработки.
Целевая вычислительная система не всегда является той же вычислительной системой, на которой работает сам компилятор. Часто они совпадают, но бывает так, что компилятор работает под управлением вычислительной системы одного типа, а строит объектные программы, предназначенные для выполнения на вычислительных системах совсем другого типа.
ПРИМЕЧАНИЕ
Здесь есть один «подводный камень», связанный с терминологической путаницей. Термины «объектный код» и «объектный файл» возникли достаточно давно. Однако сейчас появилось понятие «объектно-ориентированное программирование», где под термином «объект» подразумевается совершенно иное, нежели в «объектном коде». Следует помнить, что «объектный код» никакого отношения к «объекту» с точки зрения объектно-ориентированного программирования не имеет! И хотя в результате компиляции программ, написанных на объектно-ориентированных языках, тоже получаются объектный код и объектные файлы, это никак не связывает между собой совершенно различные по смыслу термины.
Компиляторы, безусловно, самый распространенный вид трансляторов (многие считают их вообще единственным видом трансляторов, хотя это и не так). Они имеют самое широкое практическое применение, которым обязаны широкому распространению всевозможных языков программирования. Далее всегда будем говорить о компиляторах, подразумевая, что результирующая программа порождается на языке машинных кодов или языке ассемблера (если это не так, то это будет специально указываться отдельно).
Естественно, трансляторы и компиляторы, как и все прочие программы, разрабатывают люди — обычно это группа разработчиков. В принципе, они могли бы создавать его непосредственно на языке машинных команд, однако объем кода и данных современных компиляторов таков, что их создание на языке машинных команд практически невозможно в разумные сроки при разумных трудозатратах. Поэтому практически все современные компиляторы также создаются с помощью компиляторов (чаще всего в этой роли выступают предыдущие версии компиляторов той же фирмы-производителя). И в этом качестве компилятор является результирующей программой для другого компилятора, которая ничем не отличается от всех прочих порождаемых результирующих программ1.
Здесь возникает извечный вопрос《о курице и яйце». Конечно, в первом поколении самые первые компиляторы писались непосредственно на машинных командах, но потом, с появлением компиляторов, от этой практики отошли. Даже самые ответственные части компиляторов создаются, как минимум, с применением языка ассемблера — а он тоже обрабатывается компилятором.
Определение интерпретатора. Разница между интерпретаторами и трансляторами
Кроме схожих между собой понятий «транслятор» и «компилятор» существует принципиально отличное от них понятие интерпретатора.
Интерпретатор — это программа, которая воспринимает исходную программу на входном (исходном) языке и выполняет ее.
Интерпретатор, так же как и транслятор, анализирует текст исходной программы. Однако он не порождает результирующую программу, а сразу же выполняет исходную в соответствии с ее смыслом, заданным семантикой входного языка. Таким образом, результатом работы интерпретатора будет результат, определенный смыслом исходной программы, в том случае, если эта программа синтаксически и семантически правильная с точки зрения входного языка программирования, или сообщение об ошибке в противном случае.
ВНИМАНИЕ
В отличие от трансляторов, интерпретаторы не порождают результирующую программу —в этом принципиальная разница между ними.
Чтобы исполнить исходную программу, интерпретатор так или иначе должен преобразовать ее в язык машинных кодов, поскольку иначе выполнение программ на компьютере невозможно. Он, конечно же, делает это, однако полученные машинные коды не являются доступными — их не видит пользователь интерпретатора. Эти машинные коды порождаются интерпретатором, исполняются и уничтожаются по мере надобности — так, как того требует конкретная реализация интерпретатора. Пользователь же видит результат выполнения этих кодов — то есть результат выполнения исходной программы (требование об эквивалентности исходной программы к порожденных машинных кодов и в этом случае, безусловно, должно выполняться).
Более подробно вопросы, связанные с реализацией интерпретаторов и их отличием от компиляторов, рассмотрены далее в соответствующем разделе.
Этапы трансляции. Общая схема работы транслятора
На рис. 2.1 представлена общая схема работы компилятора. Из нее видно, что в целом процесс компиляции состоит из двух основных этапов — анализа и синтеза. На этапе анализа выполняется распознавание текста исходной программы, создание и заполнение таблиц идентификаторов. Результатом его работы служит некое внутреннее представление программы, понятное компилятору.
На этапе синтеза на основании внутреннего представления программы и информации, содержащейся в таблице идентификаторов, порождается текст результирующей программы. Результатом этого этапа является объектный код.
Кроме того, в составе компилятора присутствует часть, ответственная за анализ и исправление ошибок, которая при наличии ошибки в тексте исходной про-
граммы должна максимально полно информировать пользователя о типе ошибки и месте ее возникновения. В лучшем случае компилятор может предложить пользователю вариант исправления ошибки.
Эти этапы, в свою очередь, состоят из более мелких этапов, называемых фазами компиляции. Состав фаз компиляции на рис. 2.1 приведен в самом общем виде, их конкретная реализация и процесс взаимодействия могут, конечно, различаться в зависимости от версии компилятора. Однако в том или ином виде все представленные фазы практически всегда присутствуют в каждом конкретном компиляторе [15, 19, 31].
Рис. 2.1. Общая схема работы компилятораРис. 2.1. Общая схема работы компилятораАнализ и локализация обнаруженных ошибокАнализ и локализация обнаруженных ошибокffloaos^s-^stss 3hsu9Elffloaos^s-^stss 3hsu9El
Рис. 2.1. Общая схема работы компилятора
Рис. 2.1. Общая схема работы компилятора
Анализ и локализация обнаруженных ошибок
Анализ и локализация обнаруженных ошибок
ffloaos^s-^stss 3hsu9El
ffloaos^s-^stss 3hsu9El
Компилятор в целом с точки зрения теории формальных языков выступает в «двух ипостасях», выполняет две основные функции.
Во-первых, он является распознавателем для языка исходной программы. То есть он должен получить на вход цепочку символов входного языка, проверить ее принадлежность языку и, более того, выявить правила, по которым эта цепочка была построена (поскольку на вопрос о принадлежности сам ответ «да» или «нет» представляет мало интереса). Интересно, что генератором цепочек входного языка выступает пользователь — автор исходной программы.
Во-вторых, компилятор является генератором для языка результирующей программы. Он должен построить на выходе цепочку выходного языка по опреде-
ленным правилам, предполагаемым языком машинных команд или языком ассемблера. В случае машинных команд распознавателем этой цепочки будет выступать целевая вычислительная система, под которую создается результирующая программа.
Далее дается перечень основных фаз (частей) компиляции и краткое описание их функций. Более подробная информация дана в главах данной книги, соответствующих этим фазам. _
Лексический анализ (сканер) — это часть компилятора, которая читает литеры программы на исходном языке и строит из них слова (лексемы) исходного языка. На вход лексического анализатора поступает текст исходной программы, а выходная информация передается для дальнейшей обработки компилятором на этапе синтаксического разбора. С теоретической точки зрения лексический анализатор не является обязательной, необходимой частью компилятора. Однако существуют причины, которые определяют его присутствие практически во всех компиляторах (более подробно они описаны в главе 3 «Лексические анализаторы»). Синтаксический разбор — это основная часть компилятора на этапе анализа. Она выполняет выделение синтаксических конструкций в тексте исходной программы, обработанном лексическим анализатором. На этой же фазе компиляции проверяется синтаксическая правильность программы. Синтаксический разбор играет главную роль 一 роль распознавателя текста входного языка программирования (этот процесс описан в главе 4 «Синтаксические анализаторы»).
Семантический анализ — это часть компилятора, проверяющая правильность текста исходной программы с точки зрения семантики входного языка. Кроме непосредственно проверки семантический анализ должен выполнять преобразования текста, требуемые семантикой входного языка (например, такие, как добавление функций неявного преобразования типов). В различных реализациях компиляторов семантический анализ может частично входить в фазу синтаксического разбора, частично — в фазу подготовки к генерации кода (в данной книге семантический анализ более подробно рассмотрен в главе 5 «Генерация и оптимизация кода»).
Подготовка к генерации кода — это фаза, на которой компилятором выполняются предварительные действия, непосредственно связанные с синтезом текста результирующей программы, но еще не ведущие к порождению текста на выходном языке. Обычно в эту фазу входят действия, связанные с идентификацией элементов языка, распределением памяти и т. п. (они рассмотрены в главе 5 «Генерация н оптимизация кода»).
Генерация кода — это фаза, непосредственно связанная с порождением команд, составляющих предложения выходного языка и в целом текст результирующей программы. Это основная фаза на этапе синтеза результирующей программы. Кроме непосредственного порождения текста результирующей программы генерация обычно включает в себя также оптимизацию — процесс, связанный с обработкой уже порожденного текста. Иногда оптимизацию выделяют в отдельную фазу компиляции, так как она оказывает существенное влияние на качество и эффективность результирующей программы (подробности вы найдете в главе 5 «Генерация и оптимизация кода»).
Таблицы идентификаторов (иногда — «таблицы символов») — это специальным образом организованные наборы данных, служащие для хранения информации об элементах исходной программы, которые затем используются для порождения текста результирующей программы. В конкретной реализации компилятора может быть как одна, так и несколько таблиц идентификаторов. Элементами исходной программы, информацию о которых необходимо хранить в процессе компиляции, являются переменные, константы, функции и т. п. — конкретный состав набора элементов зависит от используемого входного языка программирования. Понятие «таблицы» вовсе не предполагает, что это хранилище данных должно быть организовано именно в виде таблиц или других массивов информации — возможные методы их организации подробно рассмотрены далее, в разделе «Таблицы идентификаторов. Организация таблиц идентификаторов».
Представленное на рис. 2.1 деление процесса компиляции на фазы служит скорее методическим целям и на практике может не соблюдаться столь строго. Далее в главах и разделах этого учебного пособия рассматриваются различные варианты технической организации представленных фаз компиляции. При этом указано, как они могут быть связаны между собой. Здесь рассмотрим только общие аспекты такого рода взаимосвязи.
Во-первых, на фазе лексического анализа лексемы выделяются из текста входной программы постольку, поскольку они необходимы для следующей фазы синтаксического разбора. Во-вторых, как будет показано ниже, синтаксический разбор и генерация кода могут выполняться одновременно. Таким образом, эти три фазы компиляции могут работать комбинированно, а вместе с ними может выполняться и подготовка к генерации кода. Далее рассмотрены технические вопросы реализации основных фаз компиляции, которые тесно связаны с понятием прохода.
Понятие прохода. Многопроходные и однопроходные компиляторы
Как уже было сказано, процесс компиляции программ состоит из нескольких фаз. В реальных компиляторах состав этих фаз может несколько отличаться от рассмотренного выше — некоторые из них могут быть разбиты на составляющие, другие, напротив, объединены в одну фазу. Порядок выполнения фаз компиляции также может меняться в разных вариантах компиляторов. В одном случае компилятор просматривает текст исходной программы, сразу выполняет все фазы компиляции и получает результат — объектный код. В другом варианте он выполняет над исходным текстом только некоторые из фаз компиляции и получает не конечный результат, а набор некоторых промежуточных данных. Эти данные затем снова подвергаются обработке, причем этот процесс может повторяться несколько раз.
Реальные компиляторы, как правило, выполняют трансляцию текста исходной программы за несколько проходов.
Проход — это процесс последовательного чтения компилятором данных из внешней памяти, их обработки и помещения результата работы во внешнюю память. Чаще всего один проход включает в себя выполнение одной или нескольких фаз
компиляции. Результатом промежуточных проходов является внутреннее представление исходной программы, результатом последнего прохода — объектная программа.
В качестве внешней памяти могут выступать любые носители информации — оперативная память компьютера, накопители на магнитных дисках, магнитных лентах и т. п. Современные компиляторы, как правило, стремятся максимально использовать для хранения данных оперативную память компьютера, и только при недостатке объема доступной памяти используются накопители на жестких магнитных дисках. Другие носители информации в современных компиляторах не используются из-за невысокой скорости обмена данными.
При выполнении каждого прохода компилятору доступна информация, полученная в результате всех предыдущих проходов. Как правило, он стремится использовать в первую очередь только информацию, полученную на проходе, непосредственно предшествовавшем текущему, но, в принципе, может обращаться и к данным от более ранних проходов вплоть до исходного текста программы. Информация, получаемая компилятором при выполнении проходов, недоступна пользователю. Она либо хранится в оперативной памяти, которая освобождается компилятором после завершения процесса трансляции, либо оформляется в виде временных файлов на диске, которые также уничтожаются после завершения работы компилятора. Поэтому человек, работающий с компилятором, может даже не знать, сколько проходов выполняет компилятор — он всегда видит только текст исходной программы и результирующую объектную программу. Но количество выполняемых проходов — это важная техническая характеристика компилятора, солидные фирмы-разработчики компиляторов обычно указывают ее в описании своего продукта.
Понятно, что разработчики стремятся максимально сократить количество проходов, выполняемых компиляторами. При этом увеличивается скорость работы компилятора, сокращается объем необходимой ему памяти* Однопроходный компилятор, получающий на вход исходную программу и сразу же порождающий результирующую объектную программу, — это идеальный вариант.
Однако сократить число проходов не всегда удается. Количество необходимых проходов определяется прежде всего грамматикой и семантическими правилами исходного языка. Чем сложнее грамматика языка и чем больше вариантов предполагают семантические правила — тем больше проходов будет выполнять компилятор (конечно, играет свою роль и квалификация разработчиков компилятора). Например, именно поэтому обычно компиляторы с языка Pascal работают быстрее, чем компиляторы с языка С — грамматика Pascal более проста, а семантические правила более жесткие.
Однопроходные компиляторы — редкость, они возможны только для очень простых языков. Реальные компиляторы выполняют, как правило, от двух до пяти проходов. Таким образом, реальные компиляторы являются многопроходными. Наиболее распространены двух- и трехпроходные компиляторы, например: первый проход — лексический анализ, второй — синтаксический разбор и семанти- чески11 анализ, третий — генерация и оптимизация кода (варианты исполнения, конечно, зависят от разработчика). В современных системах программирования
нередко первый проход компилятора (лексический анализ кода) выполняется параллельно с редактированием кода исходной программы (такой вариант построения компиляторов рассмотрен далее в главе 6 «Современные системы программирования»).
Современные компиляторы и интерпретаторы
Компиляторы с языков высокого уровня
История развития компиляторов
Первые программы, которые создавались еще для ЭВМ первого поколения, писались непосредственно на языке машинных кодов. Это была поистине адская работа. Сразу стало ясно, что человек не должен и не может говорить на языке машинных команд, даже если он специалист по вычислительной технике. Однако все попытки научить компьютер говорить на языках людей успехом не увенчались и вряд ли когда-либо увенчаются (на что есть определенные объективные причины, рассмотренные в первой главе данной книги).
С тех пор все развитие программного обеспечения компьютеров неразрывно связано с возникновением и развитием компиляторов.
Первыми компиляторами были компиляторы с языков ассемблера, или, как они назывались, мнемокодов. Мнемокоды превратили «филькину грамоту» языка машинных команд в более-менее доступный пониманию специалиста язык мнемонических (преимущественно англоязычных) обозначений этих команд. Создавать программы уже стало значительно проще, но исполнять сам мнемокод (язык ассемблера) ни один компьютер не способен, соответственно возникла необходимость в создании компиляторов. Эти компиляторы элементарно просты, но они продолжают играть существенную роль в системах программирования по сей день. Более подробно о языке ассемблера и компиляторах с него рассказано далее в соответствующем разделе.
Следующим этапом стало создание языков программирования высокого уровня. Языки высокого уровня (к ним относится большинство языков программирования) представляют собой некоторое промежуточное звено между чисто формальными языками и языками естественного общения людей. От первых им досталась строгая формализация синтаксических структур предложений языка, от вторых — значительная часть словарного запаса, семантика основных конструкций и выражений (с элементами математических операций, пришедшими из алгебры).
Появление языков высокого уровня существенно упростило процесс программирования, хотя и не свело его до «уровня домохозяйки», как самонадеянно полагали некоторые авторы на заре рождения языков программирования. Сначала таких языков были единицы, затем десятки, сейчас, наверное, их насчитывается более сотни. Процессу этому не видно конца. Тем не менее по-прежнему -реобладают компьютеры традиционной, «неймановской» архитектуры, которые
умеют понимать только машинные команды, поэтому вопрос о создании компиляторов продолжает быть актуальным.
Как только возникла массовая потребность в создании компиляторов, стала развиваться и специализированная теория. Со временем она нашла практическое приложение во множестве созданных компиляторов. Компиляторы создавались и продолжают создаваться не только для новых, но и для давно известных языков. Многие производители, от известных, солидных фирм (таких, как Microsoft или Borland/Inprise) до мало кому знакомых коллективов авторов, выпускают на рынок все новые и новые образцы компиляторов. Это обусловлено рядом причин, которые будут рассмотрены далее.
Особенности построения и функционирования компиляторов
Как уже было сказано ранее, для задания языка программирования необходимо решить три задачи:
определить множество допустимых символов языка;
определить множество правильных программ языка;
задать смысл для каждой правильной программы.
Главную проблему при этом представляет третья задача, поскольку она, в принципе, не относится к теории формальных языков. Чисто формальные языки лишены всякого смысла, а потому для решения этой задачи нужно использовать другие подходы.
В качестве таких подходов можно указать следующие:
изложить смысл программы, написанной на языке программирования, на другом языке, который может воспринимать пользователь программы или компьютер;
использовать для проверки смысла некоторую «идеальную машину», которая предназначена для выполнения программ, написанных на данном языке.
Все, кто писал программы, так или иначе обязательно использовали первый подход. Например, комментарии в хорошо написанной программе — это и есть изложение ее смысла. Построение блок-схемы, а равно любое другое описание алгоритма исходной программы — это тоже способ изложить смысл программы на другом языке (например, языке графических символов блок-схем алгоритмов, смысл которого, в свою очередь, изложен в соответствующем ГОСТе). Но все эти способы ориентированы на человека, которому они, конечно же, более понятны. Однако не существует пока универсального способа проверить, насколько описание соответствует программе.
Компьютер умеет воспринимать только машинные команды. С точки зрения человека можно сказать, что компьютер понимает только язык машинных команд. Поэтому изложить для компьютера смысл исходной программы, написанной на любом языке программирования, значит перевести эту программу на язык машинных команд. Для человека выполнение этой операции — слишком трудоемкая задача. Именно таким переводом занимаются компиляторы для языков программирования.
Следовательно, первый подход, а именно изложение смысла исходной программы на языке машинных команд, составляет основу функционирования компиляторов. Далее в этом учебнике будут рассмотрены принципы, на основе которых компиляторы выполняют перевод исходной программы с языка программирования на язык машинных команд. Здесь можно только отметить, что главная проблема такого перевода заключается в том, что в отличие от человека ни один компилятор не способен понять смысл всей исходной программы в целом. Отсюда проистекают многие проблемы, связанные с созданием программ на любом языке программирования и работой компиляторов. Эти проблемы остаются нерешенными по сей день и, по всей видимости, никогда не будут решены, поскольку нет и не будет теоретической основы для их решения. Главная проблема заключается в том, что компилятор способен обнаруживать только самые простейшие семантические (смысловые) ошибки в исходной программе, а большую часть такого рода ошибок должен обнаруживать человек (разработчик программы или ее пользователь).
Второй подход используется при отладке программы. В качестве «идеальной машины» может выступать интерпретатор, который непосредственно воспринимает и выполняет исходную программу. Однако чаще такой «идеальной машиной» является компьютер, на котором выполняется откомпилированная программа. При этом предполагается, что компилятор переводит программу с языка программирования на язык машинных команд без изменения ее смысла (исключаются из рассмотрения ошибки компиляции), а также не рассматриваются ошибки и сбои функционирования целевой вычислительной системы. Но оценку результатов выполнения программы при отладке выполняет человек. Любые попытки поручить это дело машине лишены смысла вне контекста решаемой задачи.
Например, предложение в программе на языке Pascal вида: i :=0; while i=0 do i =0, может быть легко оценено любой машиной как бессмысленное. Но если в задачу входит обеспечение взаимодействия с другой параллельно выполняемой программой или, например, просто проверка надежности и долговечности процессора или какой-то ячейки памяти, то это же предложение покажется уже не лишенным смысла.
Но многие современные компиляторы позволяют выявить сомнительные с точки зрения смысла места в исходной программе. Такими подозрительными на наличие семантической (смысловой) ошибки местами являются недостижимые операторы, неиспользуемые переменные, неопределенные результаты функций и т. п. Обычно компилятор указывает такие места в виде дополнительных предупреждений, которые разработчик может принимать или не принимать во внимание. Для достижения этой цели компилятор должен иметь представление о том, как программа будет выполняться, и во время компиляции отследить пути выполнения отдельных фрагментов исходной программы — там, где это возможно. То есть компилятор использует второй подход для поиска потенциальных мест возможных семантических ошибок.
Но в обоих случаях осмысление исходной программы закладывает в компилятор его создатель (или коллектив создателей) — то есть человек, который руководствуется неформальными методами (чаще всего, описанием входного языка). В теории формальных языков вопрос о смысле программ не решается.
На основании изложенных положений можно сказать, что возможности компиляторов по проверке осмысленности предложений входного языка сильно ограничены. Именно поэтому большинство из них в лучшем случае ограничиваются рекомендациями разработчикам по тем местам исходного текста программ, которые вызывают сомнения с точки зрения смысла. Поэтому большинство компиляторов обнаруживают только незначительный процент от общего числа смысловых («семантических») ошибок, а следовательно, подавляющее число такого рода ошибок всегда, к большому сожалению, остаются на совести автора программы. Некоторые успехи в процессе проверки осмысленности программ достигнуты в рамках систем автоматизации разработки программного обеспечения (CASE- системы). Их подход основан на проектировании сверху вниз — от описания задачи на языке, понятном человеку, до перевода ее в операторы языка программирования. Но такой подход выходит за рамки возможностей трансляторов, поэтому здесь рассматриваться не будет.
Компиляторы в составе систем программирования
С тех пор как большинство теоретических аспектов в области компиляторов получили свою практическую реализацию (а это, надо сказать, произошло довольно быстро, в конце 60-х годов), развитие компиляторов пошло по пути повышения их дружественности человеку — пользователю, разработчику программ на языках высокого уровня.
Логичным завершением этого процесса стало создание систем программирования —программных комплексов, объединяющих в себе кроме непосредственно компиляторов множество связанных с ними компонентов программного обеспечения. Появившись, системы программирования быстро завоевали рынок и ныне в массе своей преобладают на нем. Фактически, в настоящее время обособленные компиляторы — это редкость среди современных программных средств. О том, что представляют собой и как организованы современные системы программирования см. в главе 6 «Современные системы программирования».
Ныне компиляторы являются неотъемлемой частью любой вычислительной системы. Без их существования программирование любой прикладной задачи было бы затруднено, а то и просто невозможно. Да и программирование специализированных системных задач, как правило, ведется если не на языке высокого уровня (в этой роли в настоящее время чаще всего применяется язык С), то на языке ассемблера, следовательно, применяется соответствующий компилятор. Программирование непосредственно на языках машинных кодов происходит исключительно редко и только для решения очень узких вопросов.
Первыми компиляторами были компиляторы с мнемокодов. Их потомки — современные компиляторы с языков ассемблера — существуют практически для всех известных вычислительных систем. Они предельно жестко ориентированы на архитектуру. Затем появились компиляторы с таких языков, как FORTRAN, ALGOL-68, PL/1. Они были ориентированы на большие ЭВМ с пакетной обработкой задач. Из вышеперечисленных только FORTRAN, пожалуй, продолжает
использоваться по сей день, поскольку имеет огромное количество библиотек различного назначения [5]. Многие языки, родившись, так и не получили широкого распространения — ADA, Modula, Simula известны лишь узкому кругу специалистов. В то же время на рынке программных систем доминируют системы программирования и компиляторы для языков, которым не прочили светлого будущего. В первую очередь, сейчас это С и C++. Первый из них родился вместе с операционными системами типа UNIX, вместе с ними завоевал свое «место под солнцем», а затем перешел под ОС других типов. Второй удачно воплотил в себе пример реализации идей объектно-ориентированного программирования на хорошо зарекомендовавшей себя практической базе1. Ещё можно упомянуть довольно распространенный Pascal, который неожиданно для многих вышел за рамки чисто учебного языка для университетской среды.
Об истории языков программирования и современном состоянии рынка компиляторов можно говорить долго и много. Автор считает возможным ограничиться уже сказанным, поскольку это не является целью данного учебника. Желающие могут обратиться к литературе [5, 12, 15, 17, 35, 42, 45].
Интерпретаторы. Особенности построения интерпретаторов
Интерпретатор — это программа, которая воспринимает исходную программу на входном (исходном) языке и выполняет ее. Как уже было сказано выше, основное отличие интерпретаторов от трансляторов и компиляторов заключается в том, что интерпретатор не порождает результирующую программу, а просто выполняет исходную программу.
Термин «интерпретатор» (interpreter), как и «транслятор», означает «переводчик». С точки зрения терминологии эти понятия схожи, но с точки зрения теории формальных языков и компиляции между ними существует принципиальная разница. Если понятия «транслятор» и «компилятор» почти неразличимы, то с понятием «интерпретатор» их путать никак нельзя.
Простейшим способом реализации интерпретатора можно было бы считать вариант, когда исходная программа сначала полностью транслируется в машинные команды, а затем сразу же выполняется. В такой реализации интерпретатор, по сути, мало чем отличается от компилятора с той лишь разницей, что результирующая программа в нем недоступна пользователю. Недостатком такого интерпретатора является то, что пользователь должен ждать компиляции всей исходной программы прежде, чем начнется ее выполнение. По сути, в таком интерпретаторе не было бы никакого особого смысла — он не давал бы никаких преимуществ по сравнению с аналогичным компилятором2.
Назвать реализацию «удачной» можно, если судить по достигнутым результатам, а не по качеству заложенных в C++ идей объектно-ориентированного подхода. Последний вопрос способен вызвать споры, которые выходят за рамки данного учебного пособия.
Иногда такая схема используется в современных системах программирования при отладке программ — подробности см. в главе 6 «Современные системы программирования».
Поэтому подавляющее большинство интерпретаторов действуют так, что исполняют исходную программу последовательно, по мере ее поступления на вход интерпретатора. Тогда пользователю не надо ждать завершения компиляции всей исходной программы. Более того, он может последовательно вводить исходную программу и тут же наблюдать результат ее выполнения по мере поступления [15, 17, 52, 54].
При таком порядке работы интерпретатора проявляется существенная особенность, которая отличает его от компилятора, — если интерпретатор исполняет команды по мере их поступления, то он не может выполнять оптимизацию исходной программы. Следовательно, фаза оптимизации в общей структуре интерпретатора будет отсутствовать. В остальном же структура интерпретатора будет мало отличаться от структуры аналогичного компилятора. Следует только учесть, что на последнем этапе — генерации кода — машинные команды не записываются в объектный файл, а выполняются по мере их порождения.
Отсутствие шага оптимизации определяет еще одну особенность, характерную для многих интерпретаторов: в качестве внутреннего представления программы в них очень часто используется обратная польская запись (см. главу 5 «Генерация и оптимизация кода»). Эта удобная форма представления операций обладает только одним существенным недостатком — она плохо поддается оптимизации. Но в интерпретаторах это как раз и не требуется.
Далеко не все языки программирования допускают построение интерпретаторов, которые могли бы выполнять исходную программу по мере поступления команд. Для этого язык должен допускать возможность существования компилятора, выполняющего разбор исходной программы за один проход. Кроме того, язык не может интерпретироваться по мере поступления команд, если он допускает появление обращений к функциям и структурам данных раньше их непосредственного описания. Поэтому таким методом не могут интерпретироваться такие языки, как С и Pascal.
Отсутствие шага оптимизации ведет к тому, что выполнение программы с помощью интерпретатора является менее эффективным, чем с помощью аналогичного компилятора. Кроме того, при интерпретации исходная программа должна заново разбираться всякий раз при ее выполнении, в то время как при компиляции она разбирается только один раз, а после этого всегда используется объектный файл. Также очевидно, что объектный код будет исполняться всегда быстрее, чем происходит интерпретация аналогичной исходной программы. Таким образом, интерпретаторы всегда проигрывают компиляторам в производительности.
Преимуществом интерпретатора является независимость выполнения программы от архитектуры целевой вычислительной системы. В результате компиляции получается объектный код, который всегда ориентирован на определенную целевую вычислительную систему. Для перехода на другую целевую вычислительную систему исходную программу требуется откомпилировать заново. А для интерпретации программы необходимо иметь только ее исходный текст и интерпретатор с соответствующего языка. ,
Интерпретаторы долгое время значительно уступали в распространенности компиляторам. Как правило, интерпретаторы существовали для ограниченного круга относительно простых языков программирования (таких, например, как Basic). Высокопроизводительные профессиональные средства разработки программного обеспечения строились на основе компиляторов.
Новый импульс развитию интерпретаторов придало распространение глобальных вычислительных сетей. Такие сети могут включать в свой состав компьютеры различной архитектуры, и тогда требование единообразного выполнения на каждом из них текста исходной программы становится определяющим. Поэтому с развитием глобальных сетей и распространением всемирной сети Интернет появилось много новых систем, интерпретирующих текст исходной программы. Многие языки программирования, применяемые во всемирной сети, предполагают именно интерпретацию текста исходной программы без порождения объектного кода.
В современных системах программирования существуют реализации программного обеспечения, сочетающие в себе и функции компилятора, и функции интерпретатора —в зависимости от требований пользователя исходная программа либо компилируется, либо исполняется (интерпретируется). Кроме того, некоторые современные языки программирования предполагают две стадии разработки: сначала исходная программа компилируется в промежуточный код (некоторый язык низкого уровня), а затем этот результат компиляции выполняется с помощью интерпретатора данного промежуточного языка. Более подробно варианты таких систем рассмотрены в главе 6 «Современные системы программирования».
История интерпретаторов пока не столь богата, как история компиляторов. Как уже было сказано, изначально им не придавали большого значения, поскольку почти по всем параметрам они уступают компиляторам. Из известных языков, предполагавших интерпретацию, можно упомянуть разве что Basic, хотя большинству сейчас известна его компилируемая реализация Visual Basic, сделанная фирмой Microsoft [15, 26, 43]. Тем не менее сейчас ситуация несколько изменилась, поскольку вопрос о переносимости программ и их аппаратно-платформенной независимости приобретает все большую актуальность с развитием сети Интернет (более подробно о принципах переносимости программного обеспечения и о программировании для глобальных сетей рассказано далее в главе 6 «Современные системы программирования»).
Широко распространенным примером интерпретируемого языка может служить HTML (Hypertext Markup Language) — язык описания гипертекста. На его основе в настоящее время функционирует практически вся структура сети Интернет. Другой пример — языки Java и JavaScript сочетают в себе функции компиляции и интерпретации (текст исходной программы компилируется в некоторый промежуточный код, не зависящий от архитектуры целевой вычислительной системы, этот код распространяется по сети и интерпретируется на принимающей стороне).
Трансляторы с языка ассемблера («ассемблеры»)
Определение языка ассемблера
Язык ассемблера — это язык низкого уровня. Структура и взаимосвязь цепочек 'этого языка близки к машинным командам целевой вычислительной системы, где должна выполняться результирующая программа. Применение языка ассемблера позволяет разработчику управлять ресурсами (процессором, оперативной памятью, внешними устройствами и т. п.) целевой вычислительной системы на уровне машинных команд. Каждая команда исходной программы на языке ассемблера в результате компиляции преобразуется в одну машинную команду.
Компилятор с языка ассемблера зачастую просто называют «ассемблер» или «программа ассемблера».
Язык ассемблера, как правило, содержит мнемонические коды машинных команд. Чаще всего используется англоязычная мнемоника команд, но существуют и другие варианты языков ассемблера (в том числе существуют и русскоязычные варианты). Именно поэтому язык ассемблера раньше носил название «язык мнемокодов» (сейчас это название уже практически не употребляется). Все возможные команды в каждом языке ассемблера можно разбить на две группы: в первую группу входят обычные команды языка, которые в процессе трансляции преобразуются в машинные команды; вторую группу составляют специальные команды языка, которые в машинные команды не преобразуются, но используются компилятором для выполнения задач компиляции (таких, например, как задача распределения памяти).
Синтаксис языка ассемблера чрезвычайно прост. Команды исходной программы записываются обычно таким образом, чтобы на одной строке программы располагалась одна команда. Каждая команда языка ассемблера, как правило, может быть разделена на три составляющих, расположенных последовательно одна за другой: поле метки, код операции и поле операндов. Компилятор с языка ассемблера обычно предусматривает возможность наличия во входной программе комментариев, которые отделяются от Команд заданным разделителем [53, 58].
Поле метки содержит идентификатор, представляющий собой метку, либо является пустым. Каждый идентификатор метки может встречаться в программе на языке ассемблера только один раз. Метка считается описанной там, где она непосредственно встретилась в программе (предварительное описание меток не требуется). Метка может быть использована для передачи управления на помеченную ею команду. Нередко метка отделяется от остальной части команды специальным разделителем (чаще всего — двоеточием《：》).
Код операции всегда представляет собой строго определенную мнемонику одной из возможных команд процессора или также строго определенную команду самого компилятора. Код операции записывается алфавитными символами входного языка. Чаще всего его длина составляет 3-4, реже — 5 или 6 символов.
Поле операндов либо является пустым, либо представляет собой список из одного, двух, реже — трех операндов. Количество операндов строго определено и за-
висит от кода операции — каждая операция языка ассемблера предусматривает строго заданное число своих операндов. Соответственно, каждому из этих вариантов соответствуют безадресные, одноадресные, двухадресные или трехадресные команды (большее число операндов практически не используется, поскольку в современных компьютерах даже трехадресные команды встречаются редко). В качестве операндов могут выступать идентификаторы или константы.
Реализация компиляторов с языка ассемблера
Компилятор с языка ассемблера по своей структуре и назначению ничем не отличается от всех прочих компиляторов. Однако язык ассемблера имеет ряд особенностей, которые упрощают реализацию компилятора для этого языка по сравнению с любым компилятором для языка высокого уровня./
Первой особенностью языка ассемблера является то, что ряд идентификаторов в нем выделяется специально для обозначения регистров процессора. Такие идентификаторы, с одной стороны, не требуют предварительного описания, но, с другой, они не могут быть использованы пользователем для иных целей. Набор этих идентификаторов предопределен для каждого языка ассемблера.
Иногда язык ассемблера допускает использование в качестве операндов определенных ограниченных сочетаний обозначений регистров, идентификаторов и констант, которые объединены некоторыми знаками операций. Такие сочетания чаще всего используются для обозначения типов адресации, допустимых в машинных командах целевой вычислительной системы.
Например, следующая последовательность команд:
datas db loops： mov dec 川zdatas db loops： mov dec 川z16 dup(O) datas[bx+4],cx bx
datas db loops： mov dec 川z
datas db loops： mov dec 川z
представляет собой пример последовательности команд языка ассемблера процессоров семейства Intel 86x86. Здесь присутствуют команда описания набора данных (db), метка (loops), коды операций (mov, dec и jnz). Операндами являются идентификатор набора данных (datas), обозначения регистров процессора (Ьх и сх), метка (loops) и константа (4). Составной операнд datas[bx+4] отображает косвенную адресацию набора данных datas по базовому регистру Ьх со смещением 4. Подобный синтаксис языка без труда может быть описан с помощью регулярной грамматики. Поэтому построение распознавателя для языка ассемблера не представляет труда. По этой же причине в компиляторах с языка ассемблера лексический и синтаксический разборы, как правило, совмещены в один распознаватель.*
Семантика языка ассемблера целиком и полностью определяется целевой вычислительной системой, на которую ориентирован данный язык. Семантика языка ассемблера определяет, какая машинная команда соответствует каждой команде языка ассемблера, а также то, какие операнды и в каком количестве допустимы для того или иного кода операции.
Поэтому семантический анализ в компиляторе с языка ассемблера также прост, как и синтаксический. Основной его задачей является проверка допустимости операндов для каждого кода операции, а также проверка того, что все идентификаторы и метки, встречающиеся во входной программе, описаны и обозначающие их идентификаторы не совпадают с предопределенными идентификаторами, используемыми для обозначения кодов операции и регистров процессора.
Схемы синтаксического и семантического анализа в компиляторе с языка ассемблера могут быть, таким образом, реализованы на основе обычного конечного автомата. Именно эта особенность определила тот факт, что компиляторы с языка ассемблера исторически явились первыми компиляторами, созданными для ЭВМ. Существует также ряд других особенностей, которые присущи именно языкам ассемблера и упрощают построение компиляторов для них.
Во-первых, в компиляторах с языка ассемблера не выполняется дополнительная идентификация переменных — все переменные языка сохраняют имена, присвоенные им пользователем. За уникальность имен в исходной программе отвечает ее разработчик, семантика языка никаких дополнительных требований на этот процесс не накладывает.
Во-вторых, в компиляторах с языка ассемблера предельно упрощено распределение памяти. Компилятор с языка ассемблера работает только со статической памятью. Если используется динамическая память, то для работы с нею нужно использовать соответствующую библиотеку или функции ОС, а за распределение памяти отвечает разработчик исходной программы. За передачу параметров и организацию дисплея памяти процедур и функций также отвечает разработчик исходной программы. Он же должен позаботиться и об отделении данных от кода программы — компилятор с языка ассемблера, в отличие от компиляторов с языков высокого уровня, автоматически такого разделения не выполняет.
В-третьих, на этапе генерации кода в компиляторе с языка ассемблера не производится оптимизация, поскольку разработчик исходной программы сам отвечает за организацию вычислений, последовательность машинных команд и распределение регистров процессора.
Компиляторы с языка ассемблера реализуются чаще всего по двухпроходной схеме. На первом проходе компилятор выполняет разбор исходной программы, ее преобразование в машинные коды и одновременно заполняет таблицу идентификаторов. Но на первом проходе в машинных командах остаются незаполненными адреса тех операндов, которые размещаются в оперативной памяти. На втором проходе компилятор заполняет эти адреса и одновременно обнаруживает неописанные идентификаторы. Это связано с тем, что операнд может быть описан в программе после того, как он первый раз был использован. Тогда его адрес еще не известен на момент построения машинной команды, а поэтому требуется второй проход. Типичным примером такого операнда является метка, предусматривающая переход вперед по ходу последовательности команд.
Для облегчения труда разработчика исходных программ на языке ассемблера используются макрокоманды. Практически все современные компиляторы с язы-
ков ассемблера предусматривают в своем составе развитый препроцессор, выполняющий макроподстановки по тексту исходной программы. Развитая система макрокоманд позволяет существенно расширить возможности компиляторов с языка ассемблера, но при этом следует всегда помнить, что макрокоманды представляют собой обработку текста исходной программы, а не функции, помещаемые в результирующую программу.
Макроязыки и макрогенерация
Определения макрокоманд и макрогенерации
Разработка программ на языке ассемблера — достаточно трудоемкий процесс, требующий зачастую простого повторения одних и тех же многократно встречающихся операций. Примером может служить последовательность команд, выполняемых каждый раз для организации стекового дисплея памяти при входе в процедуру или функцию.
Для облегчения труда разработчика были созданы так называемые макрокоманды. Макрокоманда представляет собой текстовую подстановку, в ходе выполнения которой каждый идентификатор определенного вида заменяется на цепочку символов из некоторого хранилища данных. Процесс выполнения макрокоманды называется макрогенерацией, а цепочка символов, получаемая в результате выполнения макрокоманды, — макрорасширением.
Процесс выполнения макрокоманд заключается в последовательном просмотре текста исходной программы, обнаружении в нем определенных идентификаторов и замене их на соответствующие строки символов. Причем выполняется именно текстовая замена одной цепочки символов (идентификатора) на другую цепочку символов (строку). Такая замена называется макроподстановкой [45, 53, 58]. .
Для того чтобы указать, какие идентификаторы на какие строки необходимо заменять, служат макроопределения. Макроопределения присутствуют непосредственно в тексте исходной программы. Они выделяются специальными ключевыми словами либо разделителями, которые не могут встречаться нигде больше в тексте программы. В процессе обработки все макроопределения полностью исключаются из текста входной программы, а содержащаяся в них информация запоминается в хранилище данных для обработки в процессе выполнения макрокоманд.
Макроопределение может содержать параметры. Тогда каждая соответствующая ему макрокоманда должна при вызове содержать строку символов вместо каждого параметра. Эта строка подставляется при выполнении макрокоманды везде, где в макроопределении встречается соответствующий параметр. В качестве параметра макрокоманды может оказаться другая макрокоманда, тогда она будет рекурсивно вызвана всякий раз, когда необходимо выполнить подстановку параметра. В принципе, макрокоманды могут образовывать последовательность рекурсивных вызовов, аналогичную последовательности рекурсивных вызовов
процедур и функций, но только вместо вычислений и передачи параметров они выполняют лишь текстовые подстановки1.
Макрокоманды и макроопределения обрабатываются специальным модулем, называемым макропроцессором, или макрогенератором. Макрогенератор получает на вход текст исходной программы, содержащий макроопределения и макрокоманды, а на выходе его появляется текст макрорасширения исходной программы, не содержащий макроопределений и макрокоманд. Оба текста являются только текстами исходной программы на входном языке, никакая другая обработка не выполняется.
Примеры макрокоманд
Синтаксис макрокоманд и макроопределений зависит от реализации макропроцессора. Но сам принцип выполнения макроподстановок в тексте программы неизменен и не зависит от их синтаксиса.
Например, следующий текст макроопределения определяет макрокоманду push__0 в языке ассемблера процессора типа Intel 8086:
push_O macro xor ax.ax push ax endm
Семантика этой макрокоманды заключается в записи числа «0» в стек через регистр процессора ах. Тогда везде в тексте программы, где встретится макрокоманда
push_O'
она будет заменена в результате макроподстановки на последовательность ко-
хогах,ах‘
push ах
Это самый простой вариант макроопределения. Существует возможность создавать более сложные макроопределения с параметрами. Одно из таких макроопределений описано ниже:
add_abx macro xl.x2
add ax.xl
add bx.xl
add cx,x2
push ax
endm
Глубина такой рекурсии, как правило, сильно ограничена. На последовательность рекурсивных вызовов макрокоманд налагаются обычно существенно более жесткие ограничения, чем на последовательность рекурсивных вызовов процедур и функций, которая при стековой организации дисплея памяти ограничена только размером стека передачи параметров. /
Тогда в тексте программы макрокоманда также должна быть указана с соответствующим числом параметров. В данном примере макрокоманда
三 ddfbx 4,8
будет в результате макроподстановки заменена на последовательность команд:
add ах.4 add bx,4 add сх,8 Diish ах
Во многих макропроцессорах возможны более сложные конструкции, которые могут содержать локальные переменные и метки. Примером такой конструкции может служить макроопределение:
ioop__axmacroxl,x2.yl,
localloopax
movax.xl
xorbx.bx
loopax：addbx.yl
subax,x2
jgeloopax
endm
Здесь метка loopax является локальной, определенной только внутри данного макроопределения. В этом случае уже не может быть выполнена простая текстовая подстановка макрокоманды в текст программы, поскольку если данную макрокоманду выполнить дважды, то это приведет к появлению в тексте программы двух одинаковых меток 1 оорах. В таком варианте макрогенератор должен использовать более сложные методы текстовых подстановок, аналогичные тем, что используются в компиляторах при идентификации лексических элементов входной программы, чтобы дать всем возможным локальным переменным и меткам макрокоманд уникальные имена в пределах всей программы.
Макроязыки и препроцессоры
Макроопределения и макрокоманды нашли применение не только в языках ассемблера, но и во многих языках высокого уровня. Там их обрабатывает специальный модуль, называемый препроцессором языка (например, широко известен препроцессор языка С). Принцип обработки остается тем же самым, что и для программ на языке ассемблера — препроцессор выполняет текстовые подстановки непосредственно над строками самой исходной программы.
В языках высокого уровня макроопределения должны быть отделены от текста самой исходной программы, чтобы препроцессор не мог спутать их с синтаксическими конструкциями входного языка. Для этого используются либо специальные символы и команды (команды препроцессора), которые никогда не могут встречаться в тексте исходной программы, либо макроопределения встречаются внутри незначащей части исходной программы — входят в состав комментариев
(такая реализация существует, например, в компиляторе с языка Pascal, созданном фирмой Borland). Макрокоманды, напротив, могут встречаться в произвольном месте исходного текста программы, и синтаксически их вызов может не отличаться от вызова функций во входном языке.
В совокупности все макроопределения и макрокоманды в тексте исходной программы являются предложениями некоторого входного языка, который называется макроязыком. Макроязык является чисто формальным языком, поскольку он лишен какого-либо смысла. Семантика макроязыка полностью определяется макрорасширением текста исходной программы, которое получается после обработки всех предложений макроязыка, а сами по себе предложения макроязыка не несут никакой семантики.
Препроцессор макроязыка (макрогенератор) в общем случае представляет собой транслятор, на вход которого поступает исходная программа, содержащая макроопределения и макрокоманды, а результирующей программой является макрорасширение программы на исходном языке. Общая схема работы макропроцессора соответствует схеме работы транслятора — он содержит лексический и синтаксический анализаторы для выделения предложений макроязыка в тексте исходной программы, таблицы идентификаторов для хранения макроопределений, генератор предложений исходного языка для выполнения макроподстановок. Отличием является отсутствие семантической обработки входного макроязыка и фазы подготовки к генерации кода.
В простейшем варианте реализации макрокоманд, когда выполняются только макроподстановки без параметров и внутренних переменных, препроцессор макроязыка может быть построен на основе регулярной грамматики и реализован в виде конечного автомата. Более сложные препроцессоры предусматривают синтаксический анализ входных конструкций макроязыка, сопоставимый по сложности с анализом предложений входного языка. Их реализация выполняется на тех же принципах, что и реализация синтаксических анализаторов в компиляторах для языков программирования.
Макрогенератор или препроцессор чаще всего не существует в виде отдельного программного модуля, а входит в состав компилятора. Именно макрорасширение исходной программы поступает на вход компилятора и является для него исходной программой. Макрорасширение исходной программы обычно недоступно ее разработчику. Более того, макроподстановки могут выполняться последовательно при разборе исходного текста на первом проходе компилятора вместе с разбором всего текста программы, и тогда макрорасширение исходной программы в целом может и вовсе не существовать как таковое.
Следует помнить, что несмотря на схожесть синтаксиса вызова макрокоманды принципиально отличаются от процедур и функций, поскольку не порождают результирующего кода, а представляют собой текстовую подстановку, выполняемую прямо в тексте исходной программы. Результаты вызова функции и макрокоманды могут из-за этого серьезно отличаться.
Рассмотрим пример на языке С.
Если описана функция
mt fKint а) { return а + а； }
и аналогичная ей макрокоманда
^define f2(a) ((a) + (а))
то результаты их вызова не всегда будут одинаковы.
Действительно, вызовы j=fl(i) и j^f2(i) (где 】и j — некоторые целочисленные переменные) приведут к одному и тому же результату. Но вызовы j=fl(++i) и j=f2(++i) дадут разные значения переменной J. Дело в том, что поскольку f2 — это макроопределение, то во втором случае будет выполнена текстовая подстановка, которая приведет к последовательности операторов j=( (++1) + (++i)). Видно, что в этой последовательности операция ++】будет выполнена дважды, в отличие от вызова функции fl(++i), где она выполняется только один раз.
Таблицы идентификаторов.
Организация таблиц идентификаторов
Назначение и особенности построения таблиц идентификаторов
Проверка правильности семантики и генерация кода требуют знания характеристик переменных, констант, функций и других элементов, встречающихся в программе на исходном языке. Все эти элементы в исходной программе, как правило, обозначаются идентификаторами. Выделение идентификаторов и других элементов исходной программы происходит на фазе лексического анализа. Их характеристики определяются на фазах синтаксического разбора, семантического анализа и подготовки к генерации кода. Состав возможных характеристик и методы их определения зависят от семантики входного языка.
В любом случае компилятор должен иметь возможность хранить все найденные идентификаторы и связанные с ними характеристики в течение всего процесса компиляции, чтобы иметь возможность использовать их на различных фазах компиляции. Для этой цели, как было сказано выше,' в компиляторах используются специальные хранилища данных, называемые таблицами символов, или таблицами идентификаторов.
Любая таблица идентификаторов состоит из набора полей, количество которых равно числу различных идентификаторов, найденных в исходной программе. Каждое поле содержит в себе полную информацию о данном элементе таблицы. Компилятор может работать с одной или несколькими таблицам идентифика-
торов — их количество зависит от реализации компилятора. Например, можно организовывать различные таблицы идентификаторов для различных модулей исходной программы или для различных типов элементов входного языка.
Состав информации, хранимой в таблице идентификаторов для каждого элемента исходной программы, зависит от семантики входного языка и типа элемента. Например, в таблицах идентификаторов может храниться следующая информация: □ для переменных:
О имя переменной;
О тип данных переменной;
О область памяти, связанная с переменной;
для констант:
О название константы (если оно имеется); ‘
О значение константы;
О тип данных константы (если требуется);
для функций:
О имя функции;
О количество и типы формальных аргументов функции;
О тип возвращаемого результата;
О адрес кода функции.
Приведенный выше состав хранимой информации, конечно же, является только примерным. Другие примеры такой информации указаны в [17, 32, 50]. Конкретное наполнение таблиц идентификаторов зависит от реализации компилятора. Кроме того, не вся информация, хранимая в таблице идентификаторов, заполняется компилятором сразу — он может несколько раз выполнять обращение к данным в таблице идентификаторов на различных фазах компиляции. Например, имена переменных могут быть выделены на фазе лексического анализа, типы данных для переменных — на фазе синтаксического разбора, а область памяти связывается с переменной только на фазе подготовки к генерации кода.
Вне зависимости от реализации компилятора принцип его работы с таблицей идентификаторов остается одним и тем же — на различных фазах компиляции компилятор вынужден многократно обращаться к таблице для поиска информации и записи новых данных.
ВНИМАНИЕ
Компилятору приходится выполнять поиск необходимого элемента в таблице идентификаторов по имени чаще, чем помещать новый элемент в таблицу, потому что каждый идентификатор может быть описан только один раз, а использован — несколько раз.
Отсюда можно сделать вывод, что таблицы идентификаторов должны быть организованы таким образом, чтобы компилятор имел возможность максимально быстрого поиска нужного ему элемента [23].
Простейшие методы построения таблиц идентификаторов
Простейший способ организации таблицы состоит в том, чтобы добавлять элементы в порядке их поступления. Тогда таблица идентификаторов будет представлять собой неупорядоченный массив информации, каждая ячейка которого будет содержать данные о соответствующем элементе таблицы.
Поиск нужного элемента в таблице будет в этом случае заключаться в последовательном сравнении искомого элемента с каждым элементом таблицы, пока не будет найден подходящий. Тогда, если за единицу времени принять время, затрачиваемое компилятором на сравнение двух элементов (как правило, это сравнение двух строк), то для таблицы, содержащей N элементов, в среднем будет выполнено N/2 сравнений [12].
Заполнение такой таблицы будет происходить элементарно просто — добавлением нового элемента в ее конец, и время, требуемое на добавление элемента (Т3) не будет зависеть от числа элементов в таблице N. Но если N велико, то поиск потребует значительных затрат времени. Время поиска (Тп) в такой таблице можно оценить как Тп』O(N). Поскольку поиск в таблице идентификаторов является наиболее часто выполняемой компилятором операцией, а количество различных идентификаторов в реальной исходной программе достаточно велико (от нескольких сотен до нескольких тысяч элементов), то такой способ организации таблиц идентификаторов является неэффективным.
Поиск может быть выполнен более эффективно, если элементы таблицы упорядочены (отсортированы) согласно некоторому естественному порядку.
Поскольку поиск осуществляется по имени идентификатора, наиболее естественным решением будет расположить элементы таблицы в прямом или обратном алфавитном порядке. Эффективным методом поиска в упорядоченном списке из N элементов является бинарный, или логарифмический, поиск.
Алгоритм логарифмического поиска заключается в следующем: искомый символ сравнивается с элементом (N + 1)/2 в середине таблицы, если этот элемент не является искомым, то мы должны просмотреть только блок элементов, пронумерованных от 1 до (N + 1)/2-1, или блок элементов от (N + 1)/2 + 1 до N в зависимости от того, меньше или больше искомый элемент того, с которым его сравнили. Затем процесс повторяется над нужным блоком в два раза меньшего размера. Так продолжается до тех пор, пока либо искомый элемент будет найден, либо алгоритм дойдет до очередного блока, содержащего один или два элемента (с которыми можно выполнить прямое сравнение искомого элемента).
Так как на каждом шаге число элементов, которые могут содержать искомый элемент, сокращается в 2 раза, максимальное число сравнений равно 1 + log2(N). Тогда время поиска элемента в таблице идентификаторов можно оценить как Тп = O(log2 N). Для сравнения: при для N ^ 128 бинарный поиск потребует максимум 8 сравнений, а поиск в неупорядоченной таблице — в среднем 64 сравнения. Метод называют «бинарным поиском», поскольку на каждом шаге объем
рассматриваемой информации сокращается в 2 раза, а «логарифмическим» — поскольку время, затрачиваемое на поиск нужного элемента в массиве, имеет логарифмическую зависимость от общего количества элементов в нем.
Недостатком логарифмического поиска является требование упорядочивания таблицы идентификаторов. Так как массив информации, в котором выполняется поиск, должен быть упорядочен, то время его заполнения уже будет зависеть от числа элементов в массиве. Таблица идентификаторов зачастую просматривается компилятором еще до того, как она заполнена полностью, поэтому требуется, чтобы условие упорядоченности выполнялось на всех этапах обращения к ней. Следовательно, для построения такой таблицы можно пользоваться только алгоритмом прямого упорядоченного включения элементов.
При добавлении каждого нового элемента в таблицу сначала надо определить место, куда поместить новый элемент, а потом выполнить перенос части информации в таблице, если элемент добавляется не в ее конец. Если пользоваться стандартными алгоритмами, применяемыми для организации упорядоченных массивов данных [12], а поиск места включения осуществлять с помощью алгоритма бинарного поиска, то среднее время, необходимое на помещение всех элементов в таблицу, можно оценить следующим образом:
Т3 - O(N*log2 N) + k*O(№)
Здесь к — некоторый коэффициент, отражающий соотношение между временем, затрачиваемым компьютером на выполнение операции сравнения и операции переноса данных.
В итоге при организации логарифмического поиска в таблице идентификаторов мы добиваемся существенного сокращения времени поиска нужного элемента за счет увеличения времени на помещение нового элемента в таблицу. Поскольку добавление новых элементов в таблицу идентификаторов происходит существенно реже1, чем обращение к ним, этот метод следует признать более эффективным, чем метод организации неупорядоченной таблицы.
Построение таблиц идентификаторов по методу бинарного дерева
Можно сократить время поиска искомого элемента в таблице идентификаторов, не увеличивая значительно время, необходимое на ее заполнение. Для этого надо отказаться от организации таблицы в виде непрерывного массива данных. Существует метод построения таблиц, при котором таблица имеет форму бинарного дерева. Каждый узел дерева представляет собой элемент таблицы, причем корневой узел является первым элементом, встреченным при заполнении таблицы.
Как минимум, при добавлении нового идентификатора в таблицу компилятор должен проверить, существует ли там такой идентификатор, так как в большинстве языков программирования ни один идентификатор не может быть описан более одного раза. Следовательно, каждая операция добавления нового элемента влечет, как правило, не менее одной операции поиска.
Дерево называется бинарным, так как каждая вершина в нем может иметь не более двух ветвей. Для определенности будем называть ветви «правая» и «левая».
Рассмотрим алгоритм заполнения бинарного дерева. Будем считать, что алгоритм работает с потоком входных данных, содержащим идентификаторы (в компиляторе этот поток данных порождается в процессе разбора текста исходной программы). Первый идентификатор, как уже было сказано, помещается в вершину дерева. Все дальнейшие идентификаторы попадают в дерево по следующему алгоритму:
Шаг 7, Выбрать очередной идентификатор из входного потока данных. Если очередного идентификатора нет, то построение дерева закончено.
Шаг 2. Сделать текущим узлом дерева корневую вершину.
Шаг 3. Сравнить очередной идентификатор с идентификатором, содержащимся в текущем узле дерева.
Шаг 4. Если очередной идентификатор меньше, то перейти к шагу 5, если равен —сообщить об ошибке и прекратить выполнение алгоритма (двух одинаковых идентификаторов быть не должно!), иначе — перейти к шагу 7.
Шаг 5. Если у текущего узла существует левая вершина, то сделать ее текущим узлом и вернуться к шагу 3, иначе перейти к шагу 6.
Шаг 6. Создать новую вершину, поместить в нее очередной идентификатор, сделать эту новую вершину левой вершиной текущего узла и вернуться к шагу 1.
Шаг 7. Если у текущего узла существует правая вершина, то сделать ее текущим узлом и вернуться к шагу 3, иначе перейти к шагу 8. ,
Шаг 8. Создать новую вершину, поместить в нее очередной идентификатор, сделать эту новую вершину правой вершиной текущего узла и вернуться к шагу 1.
Рассмотрим в качестве примера последовательность идентификаторов GA, DI, М22, Е, А12, ВС, F. На рис. 2.2 проиллюстрирован весь процесс построения бинарного дерева для этой последовательности идентификаторов.
Поиск нужного элемента в дереве выполняется по алгоритму, схожему с алгоритмом заполнения дерева:
Шаг 1. Сделать текущим узлом дерева корневую вершину.
Шаг 2. Сравнить искомый идентификатор с идентификатором, содержащимся в текущем узле дерева.
Шаг 3. Если идентификаторы совпадают, то искомый идентификатор найден, алгоритм завершается, иначе надо перейти к шагу 4.
Шаг 4. Если очередной идентификатор меньше, то перейти к шагу 5, иначе — перейти к шагу 6.
Шаг 5. Если у текущего узла существует левая вершина, то сделать ее текущим узлом и вернуться к шагу 2, иначе искомый идентификатор не найден, алгоритм завершается.'
Шаг 6. Если у текущего узла существует правая вершина, то сделать ее текущим узлом и вернуться к шагу 2, иначе искомый идентификатор не найден, алгоритм завершается.
Рис. 2.2. Заполнение бинарного дерева для последовательности идентификаторов GA, DI, М22, Е, А12, ВС, F
Например, произведем поиск в дереве, изображенном на рис. 2.2, идентификатора А12. Берем корневую вершину (она становится текущим узлом), сравниваем идентификаторы GA и А12. Искомый идентификатор меньше — текущим узлом становится левая вершина D1. Опять сравниваем идентификаторы. Искомый идентификатор меньше — текущим узлом становится левая вершина А12. При следующем сравнении искомый идентификатор найден.
Если искать отсутствующий идентификатор — например, All, — то поиск опять пойдет от корневой вершины. Сравниваем идентификаторы GA и АН. Искомый идентификатор меньше — текущим узлом становится левая вершина 01. Опять сравниваем идентификаторы. Искомый идентификатор меньше — текущим узлом становится левая вершина А12. Искомый идентификатор меньше, но левая вершина у узла А12 отсутствует, поэтому в данном случае искомый идентификатор не найден.
Для данного метода число требуемых сравнений и форма получившегося дерева зависят от того порядка, в котором поступают идентификаторы. Например, если
в рассмотренном выше примере вместо последовательности идентификаторов ЗА, DI, М22, Е, А12, ВС, F взять последовательность А12, GA, Dlt М22, Е, ВС, F, то полученное дерево будет иметь иной вид. А если в качестве примера взять последовательность идентификаторов А, В, С, D, Е, F, то дерево выродится в упорядоченный однонаправленный связный список. Эта особенность является недостатком данного метода организации таблиц идентификаторов. Другим недостатком является необходимость работы с динамическим выделением памяти при построении дерева. Если предположить, что последовательность идентификаторов в исходной программе является статистически неупорядоченной (что в целом соответствует действительности), то можно считать, что построенное бинарное дерево будет невырожденным. Тогда среднее время на заполнение дерева (Т3) и на поиск элемента в нем (Тп) можно оценить следующим образом [4, т.2]:
北=N*O(log2 N)
Т“ = O(log2 N)
В целом метод бинарного дерева является довольно удачным механизмом для организации таблиц идентификаторов. Он нашел свое применение в ряде компиляторов. Иногда компиляторы строят несколько различных деревьев для идентификаторов разных типов и разной длины [17, 50].
Хэш-функции и хэш-адресация
Принципы работы хэш-функций
Логарифмическая зависимость времени поиска и времени заполнения таблицы идентификаторов — это самый хороший результат, которого можно достичь за счет применения различных методов организации таблиц. Однако в реальных исходных программах количество идентификаторов столь велико, что даже логарифмическую зависимость времени поиска от их числа нельзя признать удовлетворительной. Необходимы более эффективные методы поиска информации в таблице идентификаторов.
Лучших результатов можно достичь, если применить методы, связанные с использованием хэш-функций и хэш-адресации.
Хэш-функцией F называется некоторое отображение множества входных элементов R на множество целых неотрицательных чисел Z: F(r) = n, reR, neZ. Сам термин «хэш-функция» происходит от английского термина «hash function» (hash — «мешать», «смешивать», «путать» ). Вместо термина «хэширование» иногда используются термины «рандомизация», «переупорядочивание».
Множество допустимых входных элементов R называется областью определения хэш-функции. Множеством значений хэш-^ункции F называется подмножество М из множества целых неотрицательных чисел Z: McZ, содержащее все возможные значения, возвращаемые функцией F: VreR: F(r)eM и VmeM: 3reR: F(r) = m. Процесс отображения области определения хэш-функции на множество значений называется «хэшированием».
При работе с таблицей идентификаторов хэш-функция должна выполнять отображение имен идентификаторов на множество целых неотрицательных чисел. Областью определения хэш-функции будет множество всех возможных имен идентификаторов.
Хэш-адресация заключается в использовании значения, возвращаемого хэш- функцией, в качестве адреса ячейки из некоторого массива данных. Тогда размер массива данных должен соответствовать области значений используемой хэш-функции. Следовательно, в реальном компиляторе область значений хэш- функции никак не должна превышать размер доступного адресного пространства компьютера.
Метод организации таблиц идентификаторов, основанный на использовании хэш-адресации, заключается в размещении каждого элемента таблицы в ячейке, адрес которой возвращает хэш-функция, вычисленная для этого элемента. Тогда в идеальном случае для размещения любого элемента в таблице идентификаторов достаточно только вычислить его хэш-функцию и обратиться к нужной ячейке массива данных. Для поиска элемента в таблице необходимо вычислить хэш-функцию для искомого элемента и проверить, не является ли заданная ею ячейка массива пустой (если она не пуста — элемент найден, если пуста — не найден). Первоначально таблица идентификаторов должна быть заполнена информацией, которая позволила бы говорить о том, что все ее ячейки являются пустыми.
На рис. 2.3 проиллюстрирован метод организации таблиц идентификаторов с использованием хэш-адресации. Трем различным идентификаторам Al, А2, АЗ соответствуют на рисунке три значения хэш-функции nl, п2, пЗ. В ячейки, адресуемые п1, п2, пЗ, помещается информация об идентификаторах Al, А2, АЗ. При поиске идентификатора АЗ вычисляется значение адреса п3 и выбираются данные из соответствующей ячейки таблицы.
Рис. 2.3. 0р「анизация таблицы идентификаторов с использованием хэш-адресации
Этот метод весьма эффективен, поскольку как время размещения элемента в таблице, так и время его поиска определяются только временем, затрачиваемым на вычисление хэш-функции, которое в общем случае несопоставимо меньше времени, необходимого для выполнения многократных сравнений элементов таблицы.
Метод имеет два очевидных недостатка. Первый из них — неэффективное использование объема памяти под таблицу идентификаторов: размер массива для ее хранения должен соответствовать области значений хэш-функции, в то время как реально хранимых в таблице идентификаторов может быть существенно меньше. Второй недостаток — необходимость соответствующего разумного выбора хэш- функции. Этому существенному вопросу посвящены следующие два подпункта.
Построение таблиц идентификаторов на основе хэш-функций
Существуют различные варианты хэш-функций. Получение результата хэш- функции —«хэширование» — обычно достигается за счет выполнения над цепочкой символов некоторых простых арифметических и логических операций. Самой простой хэш-функцией для символа является код внутреннего представления в компьютере литеры символа. Эту хэш-функцию можно использовать и для цепочки символов, выбирая первый символ в цепочке. Так, если двоичное ASCII-представление символа А есть двоичный код 001000012, то результатом хэширования идентификатора ATable буДет код 001000012.
Хэш-функция, предложенная выше, очевидно не удовлетворительна: при использовании такой хэш-функции возникнет проблема — двум различным идентификаторам, начинающимся с одной и той же буквы, будет соответствовать одно и то же значение хэш-функции. Тогда при хэш-адресации в одну ячейку таблицы идентификаторов по одному и тому же адресу должны быть помещены два различных идентификатора, что явно невозможно. Такая ситуация, когда двум или более идентификаторам соответствует одно и то же значение функции, называется коллизией.
Естественно, что хэш-функция, допускающая коллизии, не может быть напрямую использована для хэш-адресации в таблице идентификаторов. Причем достаточно получить хотя бы один случай коллизии на всем множестве идентификаторов, чтобы такой хэш-функцией нельзя было пользоваться непосредственно. Но в примере взята самая элементарная хэш-функция. А возможно ли построить хэш-функцию, которая бы полностью исключала возникновение коллизий?
Очевидно, что для полного исключения коллизий хэш-функция должна быть взаимно однозначной: каждому элементу из области определения хэш-функции должно соответствовать одно значение из ее множества значений, и каждому значению из множества значений этой функции должен соответствовать только один элемент из области ее определения. Тогда любым двум произвольным элементам из области определения хэш-функции будут всегда соответствовать два различных ее значения. Теоретически для идентификаторов такую хэш- функцию построить можно, так как и область определения хэш-функции (все возможные имена идентификаторов), и область ее значений (целые неотрица-
тельные числа) являются бесконечными счетными множествами. Теоретически можно организовать взаимно однозначное отображение одного счетного множества на другое, но практически это сделать исключительно сложно1.
Практически существует ограничение, делающее создание взаимно однозначной хэш-функции для идентификаторов невозможным. Дело в том, что в реальности область значений любой хэш-функции ограничена размером доступного адресного пространства в данной архитектуре компьютера. При организации хэш-адресации значение, используемое в качестве адреса таблицы идентификаторов, не может выходить за пределы, заданные разрядностью адреса компьютера2. Множество адресов любого компьютера с традиционной архитектурой может быть велико, но всегда конечно, то есть ограничено. Организовать взаимно однозначное отображение бесконечного множества на конечное даже теоретически невозможно. Можно учесть, что длина принимаемой во внимание части имени идентификатора в реальных компиляторах также практически ограничена — обычно она лежит в пределах от 32 до 128 символов (то есть и область определения хэш-функции конечна). Но и тогда количество элементов в конечном множестве, составляющем область определения функции, будет превышать их количество в конечном множестве области значений функции (количество всех возможных идентификаторов все равно больше количества допустимых адресов в современных компьютерах). Таким образом, создать взаимно однозначную хэш-функцию практически ни в каком варианте невозможно. Следовательно, невозможно избежать возникновения коллизий. Для решения проблемы коллизии можно использовать много способов. Одним из них является метод рехэширования (или расстановка). Согласно этому методу, если для элемента А адрес h(A), вычисленный с помощью хэш-функции h, указывает на уже занятую ячейку, то необходимо вычислить значение функции Hi = h[(A) и проверить занятость ячейки по адресу пь Если и она занята, то вычисляется значение h2(A) и так до тех пор, пока либо не будет найдена свободная ячейка, либо очередное значение h,(A) совпадет с h(A). В последнем случае считается, что таблица идентификаторов заполнена, и места в ней больше нет — выдается информация об ошибке размещения идентификатора в таблице.
Такую таблицу идентификаторов можно организовать по следующему алгоритму размещения элемента:
Шаг 1. Вычислить значение хэш-функции n = h(A) для нового элемента А.
Шаг 2. Если ячейка по адресу п пустая, то поместить в нее элемент А и завершить алгоритм, иначе i :== 1 и перейти к шагу 3.
Шаг 5. Вычислить п, = %(А). Если ячейка по адресу 用 пустая, то поместить в нее элемент А и завершить алгоритм, иначе перейти к шагу 4.
Элементарным примером такого отображения для строки символов является сопоставление ей двоичного числа, полученного путем конкатенации кодов символов, входящих в строку. Фактически, сама строка тогда будет выступать адресом при хэш-адресации. Практическая ценность такого отображения весьма сомнительна.
Можно, конечно, организовать адресацию с использованием внешних накопителей для организации виртуальной памяти, но накладные затраты для такой адресации будут весьма велики. И даже в таком варианте адресное пространство никогда не будет бесконечным.
Шаг 4. Если n = п„ то сообщить об ошибке и завершить алгоритм, иначе i :== i + 1 好 вернуться к шагу 3.
Тогда поиск элемента А в таблице идентификаторов, организованной таким образом, будет выполняться по следующему алгоритму:
Шаг 7. Вычислить значение хэш-функции n = h(A) для искомого элемента А.
Шаг 2. Если ячейка по адресу п пустая, то элемент не найден, алгоритм завершен, иначе сравнить имя элемента в ячейке п с именем искомого элемента А. Если они совпадают, то элемент найден и алгоритм завершен, иначе i :e 1 и перейти к шагу 3.
Шаг 3. Вычислить п, = %(А). Если ячейка по адресу 】пустая или п = пр то элемент не найден и алгоритм завершен, иначе сравнить имя элемента в ячейке п】 с именем искомого элемента А. Если они совпадают, то элемент найден и алгоритм завершен, иначе i := i + 1 и повторить шаг 3.
Алгоритмы размещения и поиска элемента схожи по выполняемым операциям. Поэтому они будут иметь одинаковые оценки времени, необходимого для их выполнения.
При такой организации таблиц идентификаторов в случае возникновения коллизии алгоритм размещает элементы в пустых ячейках таблицы, выбирая их определенным образом. При этом элементы могут попадать в ячейки с адресами, которые потом будут совпадать со значениями хэш-функции, что приведет к возникновению новых, дополнительных коллизий. Таким образом, количество операций, необходимых для поиска или размещения в таблице элемента, зависит от заполненности таблицы.
Для организации таблицы идентификаторов по методу рехэширования необходимо определить все хэш-функции h】для всех i. Чаще всего функции hi определяют как некоторые модификации хэш-функции h. Например, самым простым методом вычисления функции h】(A) является ее организация в виде h】(A) = (h(A) + Pi) mod Nm, где Pi — некоторое вычисляемое целое число, a Nn)— максимальное значение из области значений хэш-функции h. В свою очередь, самым простым подходом здесь будет положить Pi = i. Тогда получаем формулу h<A) = (h(A) + i) mod Nm. В этом случае при совпадении значений хэш-функции для каких-либо элементов поиск свободной ячейки в таблице начинается последовательно от текущей позиции, заданной хэш-функцией h(A),
Этот способ нельзя признать особенно удачным — при совпадении хэш-адресов элементы в таблице начинают группироваться вокруг них, что увеличивает число необходимых сравнений при поиске и размещении. Среднее время поиска элемента в такой таблице в зависимости от числа операций сравнения можно оценить следующим образом [17]:
Т「0((1 - Lf/2)/(l - Lf)).
Здесь Lf — (load factor) степень заполненности таблицы идентификаторов — отношение числа занятых ячеек N таблицы к максимально допустимому числу элементов в ней: Lf = N/Nm.
Рассмотрим в качестве примера ряд последовательных ячеек таблицы: nb n2, п3, п4, п5 и ряд идентификаторов, которые надо разместить в ней: Alf A2t A3, А4, А5 при условии, что h(A[) = h(A2) = h(A5) = nt; h(A3) = n2； h(A4) = n4. Последовательность размещения идентификаторов в таблице при использовании простейшего метода рехэширования показана на рис. 2.4. В итоге после размещения в таблице для поиска идентификатора At потребуется 1 сравнение, для А2 — 2 сравнения, для А3 — 2 сравнения, для А4 — 1 сравнение и для А5 — 5 сравнений.
%(А2) h2(A5) h3(A5) h4(A5)%(А2) h2(A5) h3(A5) h4(A5)Рис. 2.4. Заполнение таблицы идентификаторов при использовании простей山е「о рехэшированияРис. 2.4. Заполнение таблицы идентификаторов при использовании простей山е「о рехэширования
%(А2) h2(A5) h3(A5) h4(A5)
%(А2) h2(A5) h3(A5) h4(A5)
Рис. 2.4. Заполнение таблицы идентификаторов при использовании простей山е「о рехэширования
Рис. 2.4. Заполнение таблицы идентификаторов при использовании простей山е「о рехэширования
Даже такой примитивный метод рехэширования является достаточно эффективным средством организации таблиц идентификаторов при частном заполнении таблицы. Имея, например, заполненную на 90% таблицу для 1024 идентификаторов, в среднем необходимо выполнить 5.5 сравнений для поиска одного идентификатора, в то время как даже логарифмический поиск дает в среднем от 9 до 10 сравнений. Сравнительная эффективность метода будет еще выше при росте числа идентификаторов и снижении заполненности таблицы.
Среднее время на помещение одного элемента в таблицу и на поиск элемента в таблице можно снизить, если применить более совершенный метод рехэширования. Одним из таких методов является использование в качестве р〔 для функции hj(A) ^ (h(A) + Pi) mod Nm последовательности псевдослучайных целых чисел pi, р2)...» Рк- При хорошем выборе генератора псевдослучайных чисел длина последовательности к будет к = Nm. Тогда среднее время поиска одного элемента в таблице можно оценить следующим образом [17]:
Eu^O((l/Lf)*log2(l- Lf))-
Существуют и другие методы организации функций рехэширования h,(A), основанные на квадратичных вычислениях или, например, на вычислении по форму- 二е: h】(A) = (h(A)*i) mod Nm, если Nm — простое число. В целом рехэширование ^oзвoляeт добиться неплохих результатов для эффективного поиска элемента з таблице (лучших, чем бинарный поиск и бинарное дерево), но эффективность метода сильно зависит от заполненности таблицы идентификаторов и качества используемой хэш-функции — чем реже возникают коллизии, тем выше эффективность метода. Требование частичного заполнения таблицы ведет к неэффективному использованию объема доступной памяти.
Построение таблиц идентификаторов по методу цепочек
Частичное заполнение таблицы идентификаторов при применении хэш-функций ведет к неэффективному использованию всего объема памяти, доступного компилятору. Причем объем неиспользуемой памяти будет тем выше, чем больше шформации хранится для каждого идентификатора. Этого недостатка можно избежать, если дополнить таблицу идентификаторов некоторой промежуточной \эш-таблицей.
В ячейках хэш-таблицы может храниться либо пустое значение, либо значение указателя на некоторую область памяти из основной таблицы идентификаторов. Тогда хэш-функция вычисляет адрес, по которому происходит обращение сначала к хэш-таблице, а потом уже через нее по найденному адресу — к самой таблице идентификаторов. Если соответствующая ячейка таблицы идентификаторов пуста, то ячейка хэш-таблицы будет содержать пустое значение. Тогда вовсе не обязательно иметь в самой таблице идентификаторов ячейку для каждого возможного значения хэш-функции — таблицу можно сделать динамической так, чтобы ее объем рос по мере заполнения (первоначально таблица идентификаторов не содержит ни одной ячейки, а все ячейки хэш-таблицы имеют пустое значение). Такой подход позволяет добиться двух положительных результатов: во-первых, тет необходимости заполнять пустыми значениями таблицу идентификаторов — это можно сделать только для хэш-таблицы; во-вторых, каждому идентификатору будет соответствовать строго одна ячейка в таблице идентификаторов (в ней те будет пустых неиспользуемых ячеек). Пустые ячейки в таком случае будут только в хэш-таблице, и объем неиспользуемой памяти не будет зависеть от объема информации, хранимой для каждого идентификатора, — для каждого значе- ткя хэш-функции будет расходоваться только память, необходимая для хране- тня одного указателя на основную таблицу идентификаторов.
На основе этой схемы можно реализовать еще один способ организации таблиц идентификаторов с помощью хэш-функций, называемый «метод цепочек». Для метода цепочек в таблицу идентификаторов для каждого элемента добавляется еще одно поле, в котором может содержаться ссылка на любой элемент таблицы. Первоначально это поле всегда пустое (никуда не указывает). Также для этого метода необходимо иметь одну специальную переменную, которая всегда указывает на первую свободную ячейку основной таблицы идентификаторов (первоначально — указывает на начало таблицы).
Метод цепочек работает по следующему алгоритму:
Шаг 7. Во все ячейки хэш-таблицы поместить пустое значение, таблица идентификаторов пуста, переменная FreePtr (указатель первой свободной ячейки) указывает на начало таблицы идентификаторов; i := 1.
Шаг 2. Вычислить значение хэш-функции п, для нового элемента А「Если ячейка хэш-таблицы по адресу п】пустая, то поместить в нее значение переменной FreePtr и перейти к шагу 5; иначе перейти к шагу 3.
Шаг 3. Положить j :== 1, выбрать из хэш-таблицы адрес ячейки таблицы идентификаторов mj и перейти к шагу 4.
Шаг 4. Для ячейки таблицы идентификаторов по адресу т〕проверить значение поля ссылки. Если оно пустое, то записать в него адрес из переменной FreePtr и перейти к шагу 5; иначе j := j + 1, выбрать из поля ссылки адрес т〕и повторить шаг 4. Шаг 5. Добавить в таблицу идентификаторов новую ячейку, записать в нее информацию для элемента А】 (поле ссылки должно быть пустым), в переменную FreePtr поместить адрес за концом добавленной ячейки. Если больше нет идентификаторов, которые надо разместить в таблице, то выполнение алгоритма закончено, иначе i := i + 1 и перейти к шагу 2.
Поиск элемента в таблице идентификаторов, организованной таким образом, будет выполняться по следующему алгоритму:
Шаг 1. Вычислить значение хэш-функции п для искомого элемента А. Если ячейка хэш-таблицы по адресу п пустая, то элемент не найден и алгоритм завершен, иначе положить j :匸 1, выбрать из хэш-таблицы адрес ячейки таблицы идентификаторов т『
Шаг 2. Сравнить имя элемента в ячейке таблицы идентификаторов по адресу т〕 с именем искомого элемента А. Если они совпадают, то искомый элемент найден и алгоритм завершен, иначе перейти к шагу 3.
Шаг 3. Проверить значение поля ссылки в ячейке таблицы идентификаторов по адресу mr Если оно пустое, то искомый элемент не найден и алгоритм завершен; иначе j j + 1, выбрать из поля ссылки адрес т〕и перейти к шагу 2.
При такой организации таблиц идентификаторов в случае возникновения коллизии алгоритм размещает элементы в ячейках таблицы, связывая их друг с другом последовательно через поле ссылки. При этом элементы не могут попадать в ячейки с адресами, которые потом будут совпадать со значениями хэш-функции. Таким образом, дополнительные коллизии не возникают. В итоге в таблице возникают своеобразные цепочки связанных элементов, откуда происходит и название данного метода — «метод цепочек».
На рис. 2.5 проиллюстрировано заполнение хэш-таблицы и таблицы идентификаторов для примера, который ранее был рассмотрен на рис. 2.4 для метода простейшего рехзширования. После размещения в таблице для поиска идентификатора А1 потребуется 1 сравнение, для А2 — 2 сравнения, для АЗ — 1 сравнение, для А4 — 1 сравнение и для А5 — 3 сравнения (сравните с результатами простого рехэширования).
Метод цепочек является очень эффективным средством организации таблиц идентификаторов. Среднее время на размещение одного элемента и на поиск элемента в таблице для него зависит только от среднего числа коллизий, возни-
кающих при вычислении хеш-функции. Накладные расходы памяти, связанные с необходимостью иметь одно дополнительное поле указателя в таблице идентификаторов на каждый ее элемент, можно признать вполне оправданными. Этот метод позволяет более экономно использовать память, но требует организации работы с динамическими массивами данных.
Рис. 2.5. Заполнение хэш-таблицы и таблицы идентификаторов при использовании метода цепочек
Комбинированные способы построения таблиц идентификаторов
Выше в примере была рассмотрена весьма примитивная хэш-функция, которую 4 и как нельзя назвать удовлетворительной. Хорошая хэш-функция распределяет
поступающие на ее вход идентификаторы равномерно на все имеющиеся в распоряжении адреса, так что коллизии возникают не столь часто. Существует большое множество хэш-функций. Каждая из них стремится распределить адреса под идентификаторы по своему алгоритму, но, как было показано выше, идеального хэширования достичь невозможно.
В реальных компиляторах практически всегда так или иначе используется хэш- адресация. Алгоритм применяемой хэш-функции обычно составляет《ноу-хау» разработчиков компилятора. Обычно при разработке хэш-функции создатели компилятора стремятся свести к минимуму количество возникающих коллизий не на всем множестве возможных идентификаторов, а на тех их вариантах, которые наиболее часто встречаются во входных программах. Конечно, принять во внимание все допустимые исходные программы невозможно. Чаще всего выполняется статистическая обработка встречающихся имен идентификаторов на некотором множестве типичных исходных программ, а также принимаются во внимание соглашения о выборе имен идентификаторов, общепринятые для входного языка. Хорошая хэш-функция — это шаг к значительному ускорению работы компилятора, поскольку обращение к таблицам идентификаторов выполняются многократно на различных фазах компиляции.
То, какой конкретно метод применяется в компиляторе для организации таблиц идентификаторов, зависит от реализации компилятора. Один и тот же компилятор может иметь даже несколько разных таблиц идентификаторов, организованных на основе различных методов.
Как правило, применяются комбинированные методы. В этом случае, как и для метода цепочек, в таблице идентификаторов организуется специальное дополнительное поле ссылки. Но в отличие от метода цепочек оно имеет несколько иное значение. При отсутствии коллизий для выборки информации из таблицы используется хэш-функция, поле ссылки остается пустым. Если же возникает коллизия, то с помощью поля ссылки организуется поиск идентификаторов, для которых значения хэш-функции совпадают, по одному из рассмотренных выше методов: неупорядоченный список, упорядоченный список или же бинарное дерево. При хорошо построенной хэш-функции коллизии будут возникать редко, поэтому количество идентификаторов, для которых значения хэш-функции совпали, будет не столь велико. Тогда и время поиска одного среди них будет незначительным (в принципе, при высоком качестве хэш-функции подойдет даже перебор по неупорядоченному списку).
Такой подход имеет преимущество по сравнению с методом цепочек, поскольку не требует использования промежуточной хэш-таблицы. Недостатком метода является необходимость работы с динамически распределяемыми областями памяти. Эффективность такого метода, очевидно, в первую очередь зависит от качества применяемой хэш-функции, а во вторую — от метода организации дополнительных хранилищ данных.
Хэш-адресация — это метод, который применяется не только для организации таблиц идентификаторов в компиляторах. Данный метод нашел свое применение и в операционных системах, и в системах управления базами данных. Интересующиеся читатели могут обратиться к соответствующей литературе [4, т. 2, 17, 50].
Контрольные вопросы и задачи
Вопросы
Что такое трансляция, компиляция, транслятор, компилятор? Из каких процессов состоит компиляция? Расскажите об общей структуре компилятора.
Как решается вопрос о смысле исходной программы в современных компиляторах?
Какую роль выполняет лексический анализ в процессе компиляции? Как могут быть связаны между собой лексический и синтаксический анализы?
Компилятор можно построить, не используя лексический анализатор. Объясните, почему все-таки подавляющее большинство современных компиляторов используют фазу лексического анализа.
Постройте общую схему работы интерпретатора. В чем ее отличие от общей схемы работы компилятора, приведенной в этом пособии?
Постройте общую схему работы компилятора с языка ассемблера. Какие особенности присущи данному компилятору? Какие фазы компиляции в нем могут отсутствовать?
От чего зависит количество проходов, необходимых компилятору для построения результирующей объектной программы на основе исходной программы? Как влияют на необходимое количество проходов синтаксис исходного языка программирования, семантика этого языка, архитектура целевой вычислительной системы?
Почему в глобальной сети Интернет используются в основном языки программирования, предусматривающие интерпретацию исходного кода? Какие проблемы проистекают из этого факта?
Почему для языка ассемблера, который имеет простую (часто — регулярную) грамматику, чаще всего используется двухпроходный компилятор? Что мешает свести компиляцию исходного кода на языке ассемблера в один проход?
Зачем в описании макрокоманды #define f2(d) ((а) + (а)) параметр а взят в скобки, хотя операция этого не требует?
И. Что такое таблица идентификаторов и для чего она предназначена? Какая информация может храниться в таблице идентификаторов?
Какие цели преследуются при организации таблицы идентификаторов? Исходя из каких характеристик оценивается эффективность того или иного метода организации таблицы?
Какие существуют способы организации таблиц идентификаторов?
Что такое коллизия? Почему она происходит при использовании хэш-функ- ций для организации таблиц идентификаторов? В чем заключаются преимущества и недостатки метода цепочек?
Метод логарифмического поиска позволяет значительно сократить время поиска идентификатора в таблице. Однако он же значительно увеличивает время на помещение нового идентификатора в таблицу. Почему, тем не менее,
，можно го叫帆go 蹲典吟тествах ата^呻ода по сращс^нию с поиском методом прямо涛 перебора?
Пробл^ы создания хорошей хэш-функщш связаны с ограниченной разрядной сеткой ЭВМ и, следовательно, ограниченным размером доступного адресного пространетй. Но, как сказано в первой части данного учебника, размер адресного пространства можшУ увеличить, ксПбьзуя внешние накопители данных (прежде всего жесткие дюжи) и механизм виртуальной памяти. Почему эти возможности не используются компиляторами при организации хэш-функций?
Как могут быть скбь^шированы различные методы организации таблиц иданш^каторов?*~
Чем различаются табЛшй лексем и таблица идентификаторов? В какую из этих таблиц лекагшжйй анализатор не должен псыещать. ключевые слова, разделйтели и знаки операций?
Задачи
. В программе на языке С макрокоманда 1дс1(а,Ь) и функция Inc2(a,b), выполняющие действие а + 2*b, описаны сле^ющим образом：
#define lncUa..b) ((a>(&^(b)),-.
int Inc2(unt,a. Int b). {return a+t>+6；}.」
К юмим результатам приведут следующие вызо&ы для целочисленных пере- меннык!) jak:
k-IncKi.l); Н IncKI.jh k- Incl(iJ+l)； к- IncUiJ++):
xmcldk.inc2cM一—
k-Inc2(1,l): Z Inc2(l7j): к- Inc2(1,j+1)； h Inc2(1J++);
卜 Incad^JncKjJ));
В каких из перешк^ёянМ случаев будет получен логически неверный результат?)
Пзъшнится ли результат, полученный при выполнении макрокоманды Incl(a,b) из предыдущей задачи, если ее определение будет дано следующим образом: fdeflne Incl(^.b) ((a)+(2*(b)))
Приведет ли это к логически правильным результатам во всех вышеприведенных случаях?
Будет ли верным следукндее определение макрокок^Мды：
#define IncKa.b) ((a)+(2*b))
Если оно содержит ошибку, укажите, в каком случав выполнение данш)й макрокоманды даст неверный результат. 」
Напишите программу, реализующую мед логарифмического поиска в упорядоченном кшссиве строк. В качестве исходных данных для заполнения массива возьмите любой текстовый файл, считая, что все слова в нем являются идентификатсфами.
Напишите программу, реализующую метод построения бинарного дерева. Используйте динамические структуры данных для организации дерева. В качестве исходных данных для заполнения дерева возьмите любой текстовый файл» считая, чта все слова в нем являются идентификаторами. Проверьте эффективность метода на случайных текстовых файлах, а также попробуйте в качестве источника данных файл с упорядоченным текстом.
Напишите программу, создающую таблицу идентификаторов с помощью хэш- функций на основе метода простого рехэширования. В качестве исходных данных для заполнения дерева возьмите любой текстовый файл, считая, что все слова в нем являются идентификаторами. Организуйте программу таким образом, чтобы в ней можно было легко подменять используемую хэш-функ- - цию. Подсчитывая число коллизий и среднее количество сравнений для поиска идентификатора, сравните результаты для различных хэш-функций. В качестве исходных данных для хэш-функции можно предложить:
О коды первых двух букв идентификатора;
О коды последних двух букв идентификатора;
О код первой и код последней букв идентификатора;
О коды первой, последней и средней букв идентификатора.
Выполните действия, описанные в задаче № 5, для таблицы идентификаторов, организованной на основе метода цепочек. Сравните результаты.
Напишите программу, строящую таблицу идентификаторов по комбинированному способу: при возникновении коллизии новый идентификатор помещается в динамический неупорядоченный список через ссылку в поле основной таблицы идентификаторов. При поиске внутри списка используется простой перебор. Подсчитывая число коллизий и среднее количество сравнений для поиска идентификатора, сравните результаты для хэш-функций, предложенных в задаче № 5. Попробуйте предложить свой вариант хэш-функции и сравните полученные результаты.
Глава 3 Лексические анализаторы
Лексические анализаторы (сканеры). — Принципы построения сканеров
Назначение лексического анализатора
Прежде чем перейти к рассмотрению лексических анализаторов, необходимо дать четкое определение того, что же такое лексема.
Лексема (лексическая единица языка) — это структурная единица языка, которая состоит из элементарных символов языка и не содержит в своем составе других структурных единиц языка.
Лексемами языков естественного общения являются слова1. Лексемами языков программирования являются идентификаторы, константы, ключевые слова языка, знаки операций и т. п. Состав возможных лексем каждого конкретного языка программирования определяется синтаксисом этого языка.
Лексический анализатор (или сканер) — это часть компилятора, которая читает исходную программу и выделяет в ее тексте лексемы входного языка. На вход лексического анализатора поступает текст исходной программы, а выходная информация передается для дальнейшей обработки компилятором на этапе синтаксического анализа и разбора.
С теоретической точки зрения лексический анализатор не является обязательной частью компилятора. Все его функции могут выполняться на этапе синтаксического разбора, поскольку полностью регламентированы синтаксисом входного языка. Однако существует несколько причин, по которым в состав практически всех компиляторов включают лексический анализ:
В языках естественного общения лексикой называется словарный запас языка. Лексический состав языка изучается лексикологией и фразеологией, а значение лексем (слов языка) — семасиологией. В языках программирования словарный запас, конечно, не столь интересен и специальной наукой не изучается.
применение лексического анализатора упрощает работу с текстом исходной программы на этапе синтаксического разбора и сокращает объем обрабатываемой информации, так как лексический анализатор структурирует поступающий на вход исходный текст программы и отбрасывает всю незначащую информацию;
для выделения в тексте и разбора лексем возможно применять простую, эффективную и теоретически хорошо проработанную технику анализа, в то время как на этапе синтаксического анализа конструкций исходного языка используются достаточно сложные алгоритмы разбора;
сканер отделяет сложный по конструкции синтаксический анализатор от работы непосредственно с текстом исходной программы, структура которого может варьироваться в зависимости от версии входного языка — при такой конструкции компилятора для перехода от одной версии языка к другой достаточно только перестроить относительно простой лексический анализатор.
Функции, выполняемые лексическим анализатором, и состав лексем, которые он выделяет в тексте исходной программы, могут меняться в зависимости от реализации компилятора. То, какие функции должен выполнять лексический анализатор и какие типы лексем он должен выделять во входной программе, а какие оставлять для этапа синтаксического разбора, решают разработчики компилятора. В основном лексические анализаторы выполняют исключение из текста исходной программы комментариев, незначащих пробелов, символов табуляции и перевода строки, а также выделение лексем следующих типов: идентификаторов, строковых, символьных и числовых констант, ключевых (служебных) слов входного языка, знаков операций и разделителей.
Результатом работы лексического анализатора является перечень всех найденных в тексте исходной программы лексем с учетом характеристик каждой лексемы. Этот перечень лексем можно представить в виде таблицы, называемой таблицей лексем. Каждой лексеме в таблице лексем соответствует некий уникальный условный код, зависящий от типа лексемы, и дополнительная служебная информация. Кроме того, информация о некоторых типах лексем, найденных в исходной программе, должна помещаться в таблицу идентификаторов (или в одну из таблиц идентификаторов, если компилятор предусматривает различные таблицы идентификаторов для различных типов лексем).
ВНИМАНИЕ
Не следует путать таблицу лексем и таблицу идентификаторов — это две принципиально разные таблицы, обрабатываемые лексическим анализатором.
Таблица лексем фактически содержит весь текст исходной программы, обработанный лексическим анализатором. В нее входят все возможные типы лексем, кроме того, любая лексема может встречаться в ней любое количество раз. Таблица идентификаторов содержит только определенные типы лексем — идентификаторы и константы. В нее не попадают такие лексемы, как ключевые (служебные) слова входного языка, знаки операций и разделители. Кроме того, каждая
лексема (идентификатор или константа) может встречаться в таблице идентификаторов только один раз. Также можно отметить, что лексемы в таблице лексем обязательно располагаются в том же порядке, как и в исходной программе (порядок лексем в ней не меняется), а в таблице идентификаторов лексемы располагаются в любом порядке так, чтобы обеспечить удобство поиска (методы организации таблиц идентификаторов рассмотрены в предыдущей главе).
В качестве примера можно рассмотреть некоторый фрагмент исходного кода на языке Pascal и соответствующую ему таблицу лексем, представленную в табл. 3.1:
begin
for I ：= 1 to N do
fg ：= fg * 0.5
Таблица 3.1. Лексемы программы
ЗначениеЗначениеtoКлючевое словоNИдентификаторdoКлючевое словоfgИдентификаторЗнак присваивания电Идентификатор*Знак арифметической операции0.5Вещественная константаtoКлючевое словоNИдентификаторdoКлючевое словоfgИдентификаторЗнак присваивания电Идентификатор*Знак арифметической операции0.5Вещественная константаbeginКлючевое словоforКлючевое словоiИдентификатор:■Знак присваивания1Целочисленная константаbeginКлючевое словоforКлючевое словоiИдентификатор:■Знак присваивания1Целочисленная константаХ1Х21 :S11X3N:电S1也А10.5Х1Х21 :S11X3N:电S1也А10.5Лексема Тип лексемы
Значение
Значение
to
Ключевое слово
N
Идентификатор
do
Ключевое слово
fg
Идентификатор
Знак присваивания
电
Идентификатор
*
Знак арифметической операции
0.5
Вещественная константа
to
Ключевое слово
N
Идентификатор
do
Ключевое слово
fg
Идентификатор
Знак присваивания
电
Идентификатор
*
Знак арифметической операции
0.5
Вещественная константа
beginКлючевое слово
forКлючевое слово
iИдентификатор
:■Знак присваивания
1Целочисленная константа
beginКлючевое слово
forКлючевое слово
iИдентификатор
:■Знак присваивания
1Целочисленная константа
Х1Х21 :S11X3N:电S1也А10.5
Х1Х21 :S11X3N:电S1也А10.5
Поле «Значение» в табл. 3.1 подразумевает некое кодовое значение, которое будет помещено в итоговую таблицу лексем в результате работы лексического анализатора. Конечно, значения, которые записаны в примере, являются условными. Конкретные коды выбираются разработчиками при реализации компилятора. Важно отметить также, что устанавливается связка таблицы лексем с таблицей идентификаторов (в примере это отражено некоторым индексом, следующим после идентификатора за знаком：, а в реальном компиляторе определяется его реализацией).
Принципы построения лексических анализаторов
Лексический анализатор имеет дело с такими объектами, как различного рода константы и идентификаторы (к последним относятся и ключевые слова). Язык
констант и идентификаторов является регулярным — то есть может быть описан с помощью регулярных грамматик. Распознавателями для регулярных языков являются конечные автоматы. Следовательно, основой для реализации лексических анализаторов служат регулярные грамматики и конечные автоматы.
Существуют правила, с помощью которых для любой регулярной грамматики может быть построен конечный автомат, распознающий цепочки языка, заданного этой грамматикой (эти правила рассмотрены далее в этой главе).
Конечный автомат для каждой входной цепочки языка дает ответ на вопрос о том, принадлежит или нет цепочка языку, заданному автоматом. Однако в общем случае задача лексического анализатора несколько шире, чем просто проверка цепочки символов лексемы на соответствие входному языку. Кроме этого, он должен выполнить следующие действия:
определить границы лексем, которые в тексте исходной программы явно не указаны;
выполнить действия для сохранения информации об обнаруженной лексеме (или выдать сообщение об ошибке, если лексема неверна).
Эти действия связаны с определенными проблемами. Далее рассмотрено, как эти проблемы решаются в лексических анализаторах.
Определение границ лексем
Выделение границ лексем является нетривиальной задачей. Ведь в тексте исходной программы лексемы не ограничены никакими специальными символами. Если говорить в терминах лексического анализатора, то определение границ лексем —это выделение тех строк в общем потоке входных символов, для которых надо выполнять распознавание.
Иллюстрацией случая, когда определение границ лексемы вызывает определенные сложности, может служить пример оператора программы на языке FORTRAN: по фрагменту исходного кода DO 10 1=1 невозможно определить тип оператора языка (а соответственно, и границы лексем). В случае DO 10 1=1.15 это присвоение вещественной переменной DO10I значения константы 1.15 (пробелы в языке FORNTAN игнорируются), а в случае DO 10 >1,15 — это цикл с перечислением от 1 до 15 по целочисленной переменной I до метки 10.
Другой иллюстрацией может служить оператор языка С, имеющий вид: к = =1+++++J,. Существует только одна единственно верная трактовка этого оператора: k = 1++ + ++J ： (если явно пояснить ее с помощью скобок, то данная конструкция имеет вид: к 工(i++) + (++j);). Однако найти ее лексический анализатор может, лишь просмотрев весь оператор до конца и перебрав все варианты, причем неверные варианты могут быть обнаружены только на этапе семантического анализа (например, вариант k = (i++)++ + j： является синтаксически правильным, но семантикой языка С не допускается). Конечно, чтобы эта конструкция была в принципе допустима, входящие в нее операнды к, т и j должны быть описаны ” должны допускать выполнение операций языка ++ и +.
Поэтому в большинстве компиляторов лексический и синтаксический анализаторы —это взаимосвязанные части. Возможны два принципиально различных метода организации взаимосвязи лексического и синтаксического анализа:
последовательный;
параллельный1.
При последовательном варианте лексический анализатор просматривает весь текст исходной программы от начала до конца и преобразует его в таблицу лексем. Таблица лексем заполняется сразу полностью, компилятор использует ее для последующих фаз компиляции, но в дальнейшем не изменяет. Дальнейшую обработку таблицы лексем выполняют следующие фазы компиляции. Если в процессе разбора лексический анализатор не смог правильно определить тип лексемы, то считается, что исходная программа содержит ошибку.
При параллельном варианте лексический анализ текста исходной программы выполняется поэтапно, по шагам. Лексический анализатор выделяет очередную лексему в исходном коде и передает ее синтаксическому анализатору. Синтаксический анализатор, выполнив разбор очередной конструкции языка, может подтвердить правильность найденной лексемы и обратиться к лексическому анализатору за следующей лексемой либо же отвергнуть найденную лексему. Во втором случае он может проинформировать лексический анализатор о том, что надо вернуться назад к уже просмотренному ранее фрагменту исходного кода и сообщить ему дополнительную информацию о том, какого типа лексему следует ожидать. Взаимодействуя между собой таким образом, лексический и синтаксические анализаторы могут перебрать несколько возможных вариантов лексем, и если ни один из них не подойдет, будет считаться, что исходная программа содержит ошибку. Только после того, как синтаксический анализатор успешно выполнит разбор очередной конструкции исходного языка (обычно такой конструкцией является оператор исходного языка), лексический анализатор помещает найденные лексемы в таблицу лексем и в таблицу идентификаторов и продолжает разбор дальше в том же порядке.
Работа синтаксического и лексического анализаторов в варианте их параллельного взаимодействия изображена в виде схемы на рис. 3.1.
Последовательная работа лексического и синтаксического анализаторов представляет собой самый простой вариант их взаимодействия. Она проще в реализации и обеспечивает более высокую скорость работы компилятора, чем их параллельное взаимодействие. Поэтому разработчики компиляторов стремятся организовать взаимодействие лексического и синтаксического анализаторов именно таким образом.
Для большинства языков программирования границы лексем распознаются по заданным терминальным символам. Эти символы — пробелы, знаки операций, символы комментариев, а также разделители (запятые, точки с запятой и т. п.). Набор таких терминальных символов зависит от синтаксиса входного языка. Важ-
Параллельный метод работы лексического анализатора и синтаксического разбора вовсе не означает, что они должны будут выполняться как параллельные взаимодействующие процессы. Такой вариант возможен, но не обязателен.
но отметить, что знаки операций сами также являются лексемами, и необходимо не пропустить их при распознавании текста.
Рис. 3.1. Параллельное взаимодействие лексического и синтаксического анализаторов
Но для многих языков программирования на этапе лексического анализа может быть недостаточно информации для однозначного определения типа и границ очередной лексемы. Однако даже и тогда разработчики компиляторов стремятся избежать параллельной работы лексического и синтаксического анализаторов. В ряде случаев помогает принцип выбора из всех возможных лексем лексемы наибольшей длины: очередной символ из входного потока данных добавляется в лексему всегда, когда он может быть туда добавлен. Как только символ не может быть добавлен в лексему, то считается, что он является границей лексемы и началом следующей лексемы (если символ не является пустым разделителем — пробелом, символом табуляции или перевода строки, знаком комментария).
Такой принцип не всегда позволяет правильно определить границы лексем в том случае, когда они не разделены пустыми символами. Например, приведенная выше строка языка С k = 1+++++J: будет разбита на лексемы следующим образом: < =1++ ++ + j； 一 и ЭТо разбиение неверное. Лексический анализатор, разбирая строку из 5 знаков +, дважды выбрал лексему наибольшей возможной длины — знак операции инкремента (увеличения значения переменной на 1) ++, хотя это неправильно. Компилятор должен будет выдать пользователю сообщение об ошибке, при том что правильный вариант распознавания этой строки существует.
Разработчики компиляторов сознательно идут на то, что отсекают некоторые правильные, но не вполне читаемые варианты исходных программ. Попытки усложнить лексический распознаватель неизбежно приведут к необходимости его взаимосвязи с синтаксическим разбором. Это потребует организации их па- эаллельной работы и неизбежно снизит эффективность работы всего компилятора. Возникшие накладные расходы никак не оправдываются достигаемым эффектом — распознаванием строк с сомнительными лексемами. Достаточно обязать пользователя явно указать с помощью пробелов (или других незначащих символов) границы лексем, что значительно проще1.
Желающие могут воспользоваться любым доступным компилятором С и проверить, насколько он способен разобрать приведенный здесь пример.
Не для всех входных языке» тайюй подход возможен. Наиример, для {шссмот- ренною выше примеря с язьща FORTRAN невозможно применить указ^ный метод — разница между оператором цикла и оператором присваивания слишком существенна, чтобы ао м%кн9 было пренебречь. Здесь придется прибегнуть к связи с синтаксическим разбором1. В таком случае приходится организовывать параллельную работу лексического и синтаксического анализаторов.
Очевидно, что последовательный вариант организации взаимодействия лексического и синтаксичесйсого анализаторов является более эффективным, так как он не требует организации сложных механизмов обмена данными и не нуждается в повторном прочтении уже |)аэобранных лексем. Этот метод является и более простым. Однако не для всех языков программирежания возможно организовать такое взаимодействие. Это зависит в основном от синтаксиса языка, заданного его грамматикой. Большинство современных ппфоко распространенных языков программирования, таких как , С и Pascal, тем не менее, позволяют построить лекси^ский анализ nb более простому, последовательному методу.
Выполнение действийу связанных с лексемами .
Выпошение действе^ в щюцессе распознаванцж лексем представляет для лексического анализатора гораздо Меньшую пробле^ чем определение транш! лексем. Зктически шма^шый автомат, который лежит в основе лексического ана- лизгшфа, должен нетошко входной язык, но и выз^одной. Ой деи^жен не толысо уметь распознать правильную лексему на входе, но и породить сш!зам- йук> с ней последоват^лькйсть <тмволов на выхода^ В такой конфигурации конечный автомат преобразуется в конечный преобразователь £，4, т. L 28, 32]. Для лексического анализатора действия по обнаружению лексемы могут трактоваться несколько ппфе, чем только порождение цепочки символов выходного языка. Он должен уметь выполнять такие действия, как запись найденной лексемы в таблицу лексей, поиск ее в таблице идента^шкаторов и запись новой лексемы в таблицу идентификаторов. Набор действий определяется реализацией компилятора. Обычно эти действия выполняются сразу же при обнаружении конца распознаваемой лексемы.
В конечном автомате, пежаще^ в основе лексического анализатора, эти д^ствия можно отобразить довольно просто — достаточно иметь возможность с каждым перехода на графе автомата (или в функции переходов автомата) связать вы・ палн^ние некоторой произвольной функции f(q3)t где q — текущее состояние автомата, а — текший входной символ. Функция f(q,a) может выполнять любые действия, доступные лексическому анализатору:
помещать новух> лексему в таблицу лексем;
прш^ять наличие валенной лексемы в табтще идев1м4»1каторов;
'П!^ида^1е эдес&^9a оператору ца языке FOKTKAN, различающиеся только на один символ —' о (точкО или 明》(запятая), — представляют собой не столько проблему для шпяшлятефв, скольмо для програмяшета, посколису позволяют дашустить очень неприятно и трудно обнаруживаемую ошибку [6].
добавлять новую лексему в таблицу идентификаторов;
выдавать сообщения пользователю о найденных ошибках и предупреждения об обнаруженных неточностях в программе;
прерывать процесс компиляции.
Возможны и другие действия, предусмотренные реализацией компилятора. Такую функцию f(q,a), если она есть, обычно записывают на графе переходов конечного автомата под дугами, соединяющими состояния автомата. Функция f(q,a) может быть пустой (не выполнять никаких действий), тогда соответствующая запись отсутствует.、
Регулярные языки и грамматики
Чтобы перейти к примерам реализации лексических анализаторов, необходимо более подробно рассмотреть регулярные языки и грамматики, лежащие в их основе.
Регулярные и автоматные грамматики
Регулярные грамматики
К регулярным, как уже было сказано, относятся два типа грамматик: леволинейные и праволинейные.
Леволинейные грамматики G(VT,VN,P,S), V 工 VNuVT могут иметь правила двух видов: А -> Ву или А -> % где A,BeVN, yeVT*.
В свою очередь, праволинейные грамматики G(VT,VN,P,S), V VNuVT могут иметь правила также двух видов: А -> уВ или А -> у, где A,BeVN, yeVT*.
Доказано, что эти два класса грамматик эквивалентны. Для любого регулярного языка, заданного праволинейной грамматикой, может быть построена леволинейная грамматика, определяющая эквивалентный язык; и наоборот — для любого регулярного языка, заданного леволинейной грамматикой, может быть построена праволинейная грамматика, задающая эквивалентный язык.
Разница между леволинейными и праволинейными грамматиками заключается в основном в том, в каком порядке строятся предложения языка: слева направо для леволинейных, либо справа налево для праволинейных. Поскольку предложения языков программирования строятся, как правило, в порядке слева направо, то в дальнейшем в разделе регулярных грамматик будет идти речь в первую очередь о леволинейных грамматиках.
Автоматные грамматики
Среди всех регулярных грамматик можно выделить отдельный класс — автоматные грамматики. Они также могут быть леволинейными и праволинейными.
Леволинейные автоматные грамматики G(VT,VN,P,S), V = VNuVT могут иметь правила двух видов: А — Bt или Aft, где A,BeVN, teVT.
Праволинейные автоматные грамматики G(VT,VN,P,S), V = VNuVT могут иметь правила двух видов: A f tB или Aft, где A.BeVN, teVT.
Разница между автоматными грамматиками и обычными регулярными грамматиками заключается в следующем: там, где в правилах обычных регулярных грамматик может присутствовать цепочка терминальных символов, в автоматных грамматиках может присутствовать только один терминальный символ. Любая автоматная грамматика является регулярной, но не наоборот — не всякая регулярная грамматика является автоматной.
Доказано, что классы обычных регулярных грамматик и автоматных грамматик почти эквивалентны. Это значит, что для любого языка, который задан регулярной грамматикой, можно построить автоматную грамматику, определяющую почти эквивалентный язык (обратное утверждение очевидно).
Чтобы классы автоматных и регулярных грамматик были полностью эквивалентны, в автоматных грамматиках разрешается дополнительное правило вида S—入, где S — целевой символ грамматики. При этом символ S не должен встречаться в правых частях других правил грамматики. Тогда язык, заданный автоматной грамматикой G, может включать в себя пустую цепочку: XeL(G).
Автоматные грамматики, так же как обычные леволинейные и праволинейные грамматики, задают регулярные языки. Поскольку реально используемые языки, как правило, не содержат пустую цепочку символов, разница на пустую цепочку между этими двумя типами грамматик значения не имеет, и правила вида S -> А, далее рассматриваться не будут.
Существует алгоритм, который позволяет преобразовать произвольную регулярную грамматику к автоматному виду — то есть построить эквивалентную ей автоматную грамматику. Этот алгоритм рассмотрен ниже. Он является исключительно полезным, поскольку позволяет существенно облегчить построение распознавателей для регулярных грамматик.
Преобразование регулярной грамматики к автоматному виду
Имеется регулярная грамматика G(VT,VN,P,S), необходимо преобразовать ее в почти эквивалентную автоматную грамматику G'(VT,VN；P',S) Как уже было сказано выше, будем рассматривать леволинейные грамматики (для праволинейных грамматик можно легко построить аналогичный алгоритм).
Алгоритм преобразования прост и заключается он в следующей последовательности действий:
Шаг 1. Все нетерминальные символы из множества VN грамматики G переносятся во множество VN' грамматики G'.
Шаг 2 Необходимо просматривать все множество правил Р грамматики G.
Если встречаются правила вида А -> Balt A,BeVN, a^^VT или вида А -> а1( AeVN, а^VT, то они переносятся во множество Р' правил грамматики G' без изменений.
Если встречаются правила вида А — В~а2…а^ n > lt A,BeVN, Vn > i > 0: 3仁 VT, то во множество нетерминальных символов VN' грамматики G' добавляются символы А「А2，.・”Ап—1，а во множество правил Р' грамматики G' добавляются правила:
А — А”©
А— f An_2an_1
А? •-А 1^2
А] —> В3[
Если встречаются правила вида А -> а^а?…3中 n > 1, AeVN, Vn > i > 0: a^VT, to во множество нетерминальных символов VN' грамматики G' добавляются символы АьА2>-..,Ап-ь а во множество правил Р' грамматики G' добавляются правила:
А -> Ах%
a… -> A鹏%_1
A? —^ А^а?
А】aj
Если встречаются правила вида А —> В или вида А -> X, то они переносятся во множество правил Р' грамматики G' без изменений.
Шаг 3・ Просматривается множество правил Р' грамматики G'. В нем ищутся правила вида А В или вида А X.
Если находится правило вида А -> В, то просматривается множество правил Р' грамматики G'. Если в нем присутствуют правила вида В -> С, В -> Са, В -> а или В -> X, то в него добавляются правила вида А->С, А->Са, А->аиА->Х соответственно, VA,B，CwVN', VaeVT' (при этом следует учитывать, что в грамматике не должно быть совпадающих правил, и если какое-то правило уже присутствует в грамматике G', то повторно его туда добавлять не следует). Правило А -> В удаляется из множества правил Р'.
Если находится правило вида А -> X (и символ А не является целевым символом S), то просматривается множество правил Р' грамматики G*. Если в нем присутствуют правила вида В -> А или В -> Аа, то в него добавляются правила вида В —九 к В — а соответственно, VA,BwVN', VaeVT' (при этом следует учитывать, что в грамматике не должно быть совпадающих правил, и если какое-то правило уже присутствует в грамматике G', то повторно его туда добавлять не следует). Правило А -> X удаляется из множества правил Р'.
Шаг 4. Если на шаге 3 было найдено хотя бы одно правило вида А -> В или А -> X зо множестве правил Р' грамматики G', то надо повторить шаг 3, иначе перейти к шагу 5.
Шаг 5. Целевым символом S* грамматики G' становится символ S.
Шаги 3 и 4 алгоритма, в принципе, можно не выполнять, если грамматика не содержит правил вида А -> В (такие правила называются цепными) или вида А -> Л
(такие правила называются Х-правилами). Реальные регулярные грамматики обычно не содержат правил такого вида. Тогда алгоритм преобразования грамматики к автоматному виду существенно упрощается. Кроме того, эти правила можно было бы устранить предварительно с помощью специальных алгоритмов преобразования (эти алгоритмы рассмотрены дальше, в главе 4 «Синтаксические анализаторы»).
Пример преобразования регулярной грамматики к автоматному виду
Рассмотрим в качестве примера следующую простейшую регулярную грамматн- ку: еССа^'Ч" ."*",")"."{"•"}"}• {S,C,K},P,S) (символы а, (, *, ), {, } из множества терминальных символов грамматики взяты в кавычки, чтобы выделить их среди фигурных скобок, обозначающих само множество):
Р:
S т С*) | К}
С -► (* | Са | С{ | С} | С( | С* | С)
К т { | Ка | К( | К* | К) | К{
Если предположить, что а здесь — это любой алфавитно-цифровой символ, кроме символов (, *, ), {, }, то эта грамматика описывает два типа комментариев, допустимых в языке программирования Borland Pascal. Преобразуем ее в автоматный вид.
Шаг 1. Построим множество VN' = {S, С, К}.
Шаг 2. Начинаем просматривать множество правил Р грамматики G.
Для правила S -> С*) во множество VN' включаем символ S1, а само правило разбиваем на два: S -> S1) и S1 -> С*; включаем эти правила во множество правил Р'. Правило S -> К} переносим во множество правил Р' без изменений.
Для правила С -> (* во множество VN' включаем символ С1, а само правило разбиваем на два: С -> С1* и С1 -> (; включаем эти два правила во множество правил Р'.
Правила С -> Са | С{ | С} | С( | С* | С) переносим во множество правил Р1 без изменений.
Правила К -> { | Ка | К( | К* | К) | К{ переносим во множество правил Р1 без изменений.
Шаг 3. Правил вида А—В или А->入 во множестве правил Р' не содержится.
Шаг 4. Переходим к шагу 5.
Шаг 5. Целевым символом грамматики G1 становится символ S.
В итоге получаем автоматную грамматику:
G'({"a"."("."*".")"."{"."}"}• {S.Sl.C.Cl.KJ.P'.S):
Р'：
S -> S1) I К}
S1 т С*
С -> Cl* I Са I С{ ! С} I С( I С* I С)
Cl т (
К т { I Ka I К( I К* I К) I К{
Эта грамматика, так же как и рассмотренная выше, описывает два типа комментариев, допустимых в языке программирования Borland Pascal.
Конечные автоматы
Определение конечного автомата
Конечным автоматом (КА) называют пятерку следующего вида:
M(Q, V, 6, q0, F),
где
Q — конечное множество состояний автомата;
V — конечное множество допустимых входных символов (алфавит автомата);
5 — функция переходов, отображающая V*Q (декартово произведение множеств) во множество подмножеств Q: R(Q), то есть 6(a,q)=R, aeV, qeQ, RcQ;
q0 — начальное состояние автомата Q, qoeQ;
F — непустое множество конечных состояний автомата, F=Q, F 工 0.
КА называют полностью определенным, если в каждом его состоянии существует функция перехода для всех возможных входных символов, то есть: VaeV, VqeQ 35(a,q) = R, RcQ.
Работа конечного автомата представляет собой последовательность шагов (или тактов). На каждом шаге работы автомат находится в одном из своих состояний Q (в текущем состоянии), на следующем шаге он может перейти в другое состояние или остаться в текущем состоянии. То, в какое состояние автомат перейдет на следующем шаге работы, определяет функция переходов 5. Она зависит не только от текущего состояния, но и от символа из алфавита V, поданного на вход автомата. Когда функция перехода допускает несколько следующих состояний автомата, то КА может перейти в любое из этих состояний. В начале работы автомат всегда находится в начальном состоянии q0. Работа КА продолжается до тех пор, пока на его вход поступают символы из входной цепочки(oeV+.
Видно, что конфигурацию КА на каждом шаге работы можно определить в виде (qf(o,n), где q — текущее состояние автомата, qwQ ①一цепочка входных символов, (oeV+; п — положение указателя в цепочке символов, neNu{0}f n < |со| (N — множество натуральных чисел). Конфигурация автомата на следующем шаге — это (я',(о,п+1), если q'e5(a,q) и символ aeV находится в позиции n + 1 цепочки со. Начальная конфигурация автомата: (qo.co.O); заключительная конфигурация автомата: (f,①，п), feQ, п = |со|, она является конечной конфигурацией, если feF.
Язык, заданный конечным автоматом
КА M(Q,V}8,q0,F) принимает цепочку символов(oeV+, если, получив на вход эту цепочку, он из начального состояния q0 может перейти в одно из конечных состояний feF. В противном случае КА не принимает цепочку символов.
Язык L(M), заданный КА MldV^q^F), — это множество всех цепочек символов, которые принимаются этим автоматом. Два КА эквивалентны, если они задают один и тот же язык.
Все КА являются распознавателями для регулярных языков [4, т. 1, 15, 28].
Граф переходов конечного автомата
КА часто представляют в виде диаграммы или графа переходов автомата.
Граф переходов КА — это направленный граф, вершины которого помечены символами состояний КА, и в котором есть дуга (p,q) p.qeQ, помеченная символом aeV, если в КА определена 5(а,р) и qe8(a,p). Начальное и конечное состояния автомата на графе состояний помечаются специальным образом (в данном пособии начальное состояние — дополнительной пунктирной линией, конечное состояние —дополнительной сплошной линией).
Рассмотрим конечный автомат: M({H,A,B,S}, {a.b} ,5,Н, {S}) ;5: 5(Н.Ь)=В, 8(В,а)=А, 6(A,b)={B.S}・ На рис. 3.2 приведен пример графа состояний для этого КА.
Рис. 3.2. Граф переходов недетерминированного конечного автомата
Для моделирования работы КА его удобно привести к полностью определенному виду, чтобы исключить ситуации, из которых нет переходов по входным символам. Для этого в КА добавляют еще одно состояние, которое можно условно назвать «ошибка». На это состояние замыкают все неопределенные переходы, а все переходы из самого состояния «ошибка» замыкают на него же.
Если преобразовать подобным образом рассмотренный выше автомат М, то получим полностью определенный автомат: M({H,A.B,E.S}, {a.b} ,6,Н, {S}) ： 8: 5(Н.а)=Е, 5(Н,Ь)=В. 8(В,а)-А, 6(B,b)=E, 5(А,а)={Е). 8(A,b)={B.S}, 3(E,d)={E}, 3(E,b)={E}, B(S.a)={E}, 5(S,b)={E}. Состояние E как раз соответствует состоянию «ошибка». Граф переходов этого КА представлен на рис. 3.3.
Рис. 3.3. Граф переходов полностью определенного недетерминированного конечного автомата
Детерминированные и недетерминированные конечные автоматы
Определение детерминированного конечного автомата
Конечный автомат M(Q,V,5,q0,F) называют детерминированным конечным автоматом (ДКА), если в каждом из его состояний* для любого входного символа функция перехода содержит не более одного состояния VawV, VqeQ: либо 5(a,q) н {г} reQ, либо 5(a,q) я 0.,
В противном случае конечный автомат назывшот детерминированным.
Из этого определения видно, что автоматы, хфедставленные ранее на рис. 3.2 и 3.3 являются недетерминированными КА.
ДКА может быть задан в виде пятерки:
MQ V, 8, q。, F),
где
Q — конечное множество состояний автомата;、
V — конечное множество допустимых входных Символов;
5 — функция переходов, отображающая V*Q в множество Q 3(a,q) - г, aeV, q,rwQ
q()— начальное состояние автомата Q, qosQ;
F — непустое множество конечных состояний автсзта, F=Q, F# 0.
Если функция переходов ДКА определена дая каждого состояния автомата, то автомат называется полностью определенным ДКА: V^^V, VqeQ; либо 35(a,q)工 г, [wQ Доказано, что для любого КА можно построить эквивалентный ему ДКА. Моделировать работу ДКА существенно проще, чем работу произвольного КА, поэтому произвольный КА стремятся преобразовать в ДКА. При построении компиляторов чаще всего используют полностью определенный ДКА.
Преобразование конечного автомата х детерминированному виду
Алгоритм преобразования произвольного КА M(Q,V,5,q0lF) в эквивалентный ему ДКА M'(Q',V5,qhF) заключается в следующем:
Множество состояний Q' автомата М' строится из комбинаций всех состояний множества Q автомата М. Если q^%,…,q^ n > 0 — состояния автомата М, VO < i < n q,eQ, то всего будет 2п-1 состояний автомата М： Обозначим их так: [5,q?,О < m < п.
Функция переходов б1 автомата М1 строится так: 5Ха,[Ч1>Ч2»-><1т]) и [ГрГз，..*,^], где VO < i ^ т 30 < j ^ к так, что 6(a»q) = iy
Обозначим q'o = [qj
Пусть 厶,与,…,f, 1 > 0 — конечные состояния автомата М, VO < i < 1 £wF, тогда множество конечных состояний F* автомата М' строится из всех состояний, имеющих вид […工…J, f sF.
Доказано, что описанный выше алгоритм строит ДКА, эквивалентный заданному произвольному КА.
После построения из нового ДКА необходимо удалить все недостижимые состояния.
Состояние qeQB КА M(Q,V,5,q0,F) называется недостижимым, если ни при какой входной цепочке(oeV+ невозможен переход автомата из начального состояния q0 в состояние q. Иначе состояние называется достижимым.
Для работы алгоритма удаления недостижимых состояний используются два множества: множество достижимых состояний R и множество текущих активных состояний на каждом шаге алгоритма Рг Результатом работы алгоритма является полное множество достижимых состояний R. Рассмотрим работу алгоритма по шагам:
R ：= {qj； i 尸 0; Ро{q0}.
Pq= 0.
VaeV, VqeP; P1+1『Pl+1u5(a,q).,
Если P1+1 一 R = 0, то выполнение алгоритма закончено, иначе R :工 RuPl+1, i i + 1 и перейти к шагу 3.
После выполнения данного алгоритма из КА можно исключить все состояния, не входящие в построенное множество R.,
Рассмотрим работу алгоритма преобразования произвольного КА в ДКА на примере автоматаМ({Н.А,В.5},{а.Ь}.5,Н,{5}): 5: 8(Н,Ь)=В, 5(В,а)«А, 5(A.b)«{B,S}. Видно, что это недетерминированный КА (из состояния А возможны два различных перехода по символу Ь). Граф переходов для этого автомата был изображен выше на рис. 3.2.
Построим множество состояний эквивалентного ДКА:
Q Г[Н].[А].[В].[S].[НА],[НВ],[HS],[АВ].[AS],[BS].[НАВ].[HAS],[HBS].[ABS].[HABS]}.
Построим функцию переходов эквивалентного ДКА:
6'([HLb)YB]
5'([A].b)<BS]
5'([В],а)-[А]
5'([HA],b)=[BS]
5'([НВ].а)«[А]
5'([НВ，Ь)ТВ：|
5'([HS].b)»[B]
5'([АВ],а)«[А]
3'([AB].b)^[BS]
5'([AS].b)<BS]
3'([BS].a)=[A]
5'([HAB].a)=[A]
5'([HAB],b)^[BS]
5'([HAS].b)=[BS]
5'([HBS],b)«[B]
5'([HBSLa)=[A]
5>([ABS].b)«[BS]
5'([ABS],a)=[A]
5'([HABS].a)<A]
5'([HABS].b)=[BS]
Начальное состояние эквивалентного ДКА:
qO' = [Н]
Множество конечных состояний эквивалентного ДКА:
F' 口 {[S],[HS].[AS],[BS].[HAS].[HBS].[ABS],[HABS]}
После построения ДКА исключим недостижимые состояния. Множество достижимых состояний ДКА будет следующим: Z {[H],[B],[A].[BS]}. В итоге, исключив все недостижимые состояния, получим ДКА:*
M'({[H].[B],[A].[BS]}t{a.b}.[H].{[BS]}).
5([Н].Ь)«[В], 5([В].а)«[А]. 8([A](b)«[BS]. 5([BS].a)«[A],，
Ничего не изменяя, переобозначим состояния ДКА. Получим:
M'({H,B,A,S},{d・b}.H,{S}),
5(Н力)=В, 3(В,а)=А, 5(A.b)«St 6(S.d№A.
Граф переходов полученного ДКА изображен на рис. 34
Рис. 3.4. Граф переходов детерминированного конечного автомата
Этот автомат можно преобразовать к полностью определенному виду. Получим граф состояний, изображенный на рис. 3.5 (состояние Е — это состояние «ошибка»).
Рис. 3.5. Граф переходов полностью определенного детерминированного конечного автомата
ВНИМАНИЕ
При построении распознавателей к вопросу о необходимости преобразования КА в ДКА надо подходить, основываясь на принципе разумной достаточности. Моделировать работу ДКА существенно проще, чем произвольного КА, но при выполнении преобразования число состояний автомата может существенно возрасти и в худшем случае составит 2П - 1, где п — количество состояний исходного КА. В этом случае затраты на моделирование ДКА окажутся больше, чем на моделирование исходного КА.
Поэтому не всегда выполнение преобразования автомата к детерминированному виду является обязательным.
Минимизация конечных автоматов
Многие КА можно минимизировать. Минимизация КА заключается в построении эквивалентного КА с меньшим числом состояний. В процессе минимизации необходимо построить автомат с минимально возможным числом состояний, эквивалентный данному КА.
Для минимизации автомата используется алгоритм построения эквивалентных состояний КА. Два различных состояния в конечном автомате М(О，У,5,д0,Р) qeQ и q'eQ называются п-эквивалентными (n-неразличимыми), п > 0 neNu{0}, если, находясь в одном из этих состояний и получив на вход любую цепочку символов со: cogV* |со| < п, автомат может перейти в одно и то же множество конечных состояний. Очевидно, что О-эквивалентными состояниями автомата M(Q,V,5,qo，F) являются два множества его состояний: F и Q-F. Множества эквивалентных состояний автомата называют классами эквивалентности, а всю их совокупность — множеством классов эквивалентности R(n), причем R(0)= ={F,Q-F}.
Рассмотрим работу алгоритма построения эквивалентных состояний по шагам: 1. На первом шаге п 尸 0, строим R(0).
На втором шаге n := n + 1, строим R(n) на основе R(n-l): R(n) = {г,(п): {q】jwQ: VaeV 5(a,qIJ)CTJ(n-l)} VijeN}. To есть в классы эквивалентности на шаге п входят те состояния, которые по одинаковым символам переходят в п-1 эквивалентные состояния.
Если R(n) = R(n-l), то работа алгоритма закончена, иначе необходимо вернуться к шагу 2.
Доказано, что алгоритм построения множества классов эквивалентности завершится максимум для п = т-2, где т — общее количество состояний авто
Алгоритм минимизации КА заключается в следующем:
Из автомата исключаются все недостижимые состояния.
Строятся классы эквивалентности автомата.
Классы эквивалентности состояний исходного КА становятся состояниями результирующего минимизированного КА.
Функция переходов результирующего КА очевидным образом строится на основе функции переходов исходного КА.
Для этого алгоритма доказано: во-первых, что он строит минимизированный КА, эквивалентный заданному; во-вторых, что он строит КА с минимально возможным числом состояний (минимальный КА).
Рассмотрим пример: задан автомат M({A,B.C.DfE.F.G}.{0.1}.5.A.{D.E}), 5(А.0)={В}, 5(А,1)={С}. 5(B,D={D}, 5(С」)={Е}, 5(D.0)={C}, b(D」)={E}, 5(Е.0)={В}, 5(E,D={D}. 5(F,O)={D), 5(F,1)={G}, 5(G,0)={F}, 5(G,1)={F}; необходимо построить эквивалентный ему минимальный КА.
Граф переходов этого автомата приведен на рис. 3.6.
Состояния F и G являются недостижимыми, они будут исключены на первом шаге алгоритма. Построим классы эквивалентности автомата:
R(O)={{A,B,C},{D,E}}, п=0;
R(1)={{A}.{B.C}.{D.E}}. п=1;
R(2)={{A}.{B,C}.{D.E}}, п=2.
Обозначим соответствующим образом состояния полученного минимального КА и построим автомат: М({А,ВС.DE}, {0,1},5',А. {DE}). 5'(А,0)={ВС}. 5'(А, 1)={ВС}, B'(BC,1)={DE}. 5'(DE,O)={BC}, 5'(DE,1)={DE}.
Граф переходов минимального КА приведен на рис. 3.7.
Рис. 3.7. Граф переходов конечного автомата после его минимизации
Минимизация конечных автоматов позволяет при построении распознавателей получить автомат с минимально возможным числом состояний и, тем самым, в дальнейшим упростить функционирование распознавателя.
Регулярные множества и регулярные выражения
Определение регулярного множества.
Определим над множествами цепочек символов из алфавита V операции конкатенации и итерации следующим образом:
PQ— конкатенация PwV* и QeV*: PQ" {pq VpeP, VqeQ};
P* — итерация PwV*: P* " {p* VpeP}.
Тогда для алфавита V регулярные множества определяются рекурсивно:
0 — регулярное множество;
{X} — регулярное множество;
{а} — регулярное множество VaeV;
если Р и Q — произвольные регулярные множества, то множества PuQ, PQ и Р* также являются регулярными множествами;
ничто другое не является регулярным множеством.
Фактически регулярные множества — это множества цепочек символов над заданным алфавитом, построенные определенным образом (с использованием операций объединения, конкатенации и итерации).
Все регулярные языки представляют собой регулярные множества.
Регулярные выражения. Свойства регулярных выражений
Регулярные множества можно обозначать с помощью регулярных выражений.
Эти обозначения вводятся следующим образом:
О — регулярное выражение, обозначающее 0;
入一регулярное выражение, обозначающее {X.};
а — регулярное выражение, обозначающее {a} VaeV;
если р и q — регулярные выражения, обозначающие регулярные множества Р и Q, то р + q, pq, р* — регулярные выражения, обозначающие регулярные множества PkjQ PQ и Р* соответственно,
ПРИМЕЧАНИЕ
Иногда для удобства обозначений вводят также операцию непустой итерации, которая обозначается р+ и для любого регулярного выражения р справедливо: р+ ■ рр* ■
Два регулярных выражения аир равны а " р, если они обозначают одно и то же множество.
Каждое регулярное выражение обозначает одно и только одно регулярное множество, но для одного регулярного множества может существовать сколь угодно много регулярных выражений, обозначающих это множество.
При записи регулярных выражений будут использоваться круглые скобт, как и для обычных арифметических выражений. При отсутствии скобок операции выполняются слева направо с учетом приоритета. Приоритет для операций принят следующий: первой выполняется итерация (высший приоритет), затем конкатенация, потом — объединение множеств (низший приоритет).
Если а, Р и у — регулярные выражения, то свойства регулярных выражений можно записать в виде следующих формул:
Л + аа* = X + а а а* (Л + а+ = а*)
а + р р + аЗ
а + (р + у) = (а + р) + у
а(р + у) = ар + ау
(Р + у)а = ра + уа
а(Ру) в (ар)у
X + а* « а* + X « а*
LO. OF.
Оа " аО "О
О + а^а + О^а
Ха = аХ " а
(а，— а'.
Все эти свойства можно легко доказать, основываясь на теории множеств, так как регулярные выражения — это только обозначения для соответствующих множеств.
Следует также обратить внимание на то, что среди прочих свойств отсутствует равенство аР " Ра, то есть операция конкатенации не обладает свойством коммутативности. Это и не удивительно, поскольку для этой операции важен порядок следования символов.
Уравнения с регулярными коэффициентами
На основе регулярных выражений можно построить уравнения с регулярными коэффициентами [15, 22]. Простейшие уравнения с регулярными коэффициентами будут выглядеть следующим образом:
X = аХ + р,
X^ Ха + р,
где
a,peV* — регулярные выражения над алфавитом V, а переменная X宏V.
Решениями таких уравнений будут регулярные множества. Это значит, что если взять регулярное множество, являющееся решением уравнения, обозначить его в виде соответствующего регулярного выражения и подставить в уравнение, то получим тождественное равенство. Два вида записи уравнений (правосторонняя
н 贯евоеторошт зашгаО о^ага с тем, что дая регулярных вырая^ш^ onq)a- одя к^шсатенации не спадает (жойством коммутативности, поэтому коэффициент можно зашгсать жак сщша, так и слева от переменной, и при этом получатся различные ургшиеия. Обе зшшси равнопрашш.
Решением первого уравнения является множество, обозначенное регулярным выражением а*р. Продлим это решение, подставив его в уравнение вместо переменной X:*
аХ + р« а(ар)+ g- (аа*)Р 十 Р "13 (аа )Р + Х₽ «5 (аа + 入)0 " а*р ■ X.
Над знаками равенства указаны номера свойстр регулярных выражений, которые были использованы для выполнения преобразований.
Решением второго уравнения является множество, обозначенное регулярным выражением Ра*.
Ха + р« (р<Г)а 十 R 届 р(а*а)十 р』з рд») + ₽1 -^ р(а*а + 九)«1 ра* - X.
ПРИМ^АНИЕ
Указанные решения уравнений не всегда яв^ются единствезшыми. Однако доказано, что X - а"В и X *■ ра* — это наименьшие из возможных решений для данных двух уравнений, ^и решения называются наименьшей подвижной точкой [4. т. 1, 15].
Чтобы решить систему уравнений с регулярными коэффициентами, надо найти такие регулярные множества X” при подстановке которых в систему все уравнения превращаются в тождества. Иными словами, решением системы является некоторое отображение f(X) множества переменных уравнения А = {X】：n > i > 0} на множество языков над алфавитом V*.
Системы уравнений с регулярными коэффициентами решаются методом последовательных подстановок. Рассмотрим метод решения для правосторонней записи, Алгоритм решения работает с переменной номера шага i и состоит из следующих шагов:
Шаг 1. Положить i := 1.
Шаг 2. Если i = п, то перейти к шагу 4, иначе записать i-e уравнение в виде: X】=а,Х,+ 自，где а】=аш р, = ₽,0 + 又+任卄】+ ... + pinXn. Решить уравнение и получить X, = а/рг Затем для всех уравнений с переменными Х1+1, ..., Хп подставить в них найденное решение вместо Хг
Шаг 3. Увеличить i на 1 (i := i + 1) и вернуться к шагу 2.
Шаг 4. После всех подстановок уравнение для Хп будет иметь вид Xn = апХп + 0, где ап = апп. Причем р будет регулярным выражением над алфавитом V* (не содержит в своем составе переменных системы уравнений X). Тогда можно найти окончательное решение для Хп: Хп = а；0. Перейти к шагу 5.
Шаг 5. Уменьшить i на 1 (i := i - 1). Если i = 0, то алгоритм завершен, иначе перейти к шагу 6.
Шаг 6. Берем найденное решение для X】=сцХ】+ р„ где а】=ан,自=Р10 + Pll+1X1+1 + + ... + pinXn и подставляем в него окончательные решения для переменных Х1+1,...» Хп. Получаем окончательное решение для Хг Перейти к шагу 5.
Для левосторонней записи системы уравнений алгоритм решения будет аналогичным, С разницей только в порядке записи коэффициентов (справа от переменных).
Система уравнений с регулярными коэффициентами всегда имеет решение, но это решение не всегда единственное. Для рассмотренного алгоритма решения системы уравнений с регулярными коэффициентами доказано, что он всегда находит решение f(X), которое является наименьшей неподвижной точкой системы уравнений. То есть если существует любое другое решение g(X), то всегда f(X)qg(X) [4, т. 1, 15].
В качестве примера рассмотрим систему уравнений с регулярными коэффициентами над алфавитом V = {"-", "+", ".". О, 1} (для ясности записи симво* лы -, + и . взяты в кавычки, чтобы не путать их со знаками операций):
XI = ("-,, + 屮 + 入)
Х2 = XI" "(О + 1) + ХЗ"." + Х2(0 + 1)
ХЗ = ХКО + 1) + ХЗ(0 + 1)
Х4 = Х2 + ХЗ
Решим эту систему уравнений.
Шаг 1.
Шаг 2
Имеем i = 1 < 4.
Берем уравнение для i = 1. Имеем XI = ("-" + "+" + X). Это уже и есть решение для XI.
Подставляем его в другие уравнения. Получаем:
Х2 = ("-" + "+" + Х)"."(0 + 1) + ХЗ"." + Х2(0 + 1)
ХЗ = ("-" + "+" + 入)(0 + 1) + X3(0 + 1)
Х4 = Х2 + ХЗ
Шаг 5.
i := 1 + 1 = 2
Возвращаемся к шагу 2.
Шаг 2.
Имеем i = 2 < 4.
Берем уравнение для i = 2. Имеем Х2 = ("-" + "+" + А)". "(0 + 1) + ХЗ"." + Х2(0 + 1). Преобразуем уравнение к виду: Х2 = Х2(0 + 1) + (("-" + "+" + Х)"."(0 + 1) + ХЗ"."). Тогда а2 = (0 + 1), 02 = ("-" + "+" + 入)"."(0 + 1) + ХЗ".". Решением для Х2 будет: Х2 = 02a2* - (("-" + "+" + 入)"."(0 + 1) + X3".")(0 + 1)* = ("-" + "+" + Х)"."(0 + + 1)(0 + 1)* + X3"."(0 + 1)*.
Подставим его в другие уравнения. Получаем:
ХЗ = ("-" + "+" + 入)(0 + 1) + ХЗ(0 + 1)
Х4 = ("-" + "+" + Х)"."(0 + 1)(0 + 1)* + ХЗ"."(0 + 1)* + ХЗ
Шаг 3.
i := 1 + 1 = з
Возвращаемся к шагу 2.
Шаг 2.
Имеем 1 = 3 < 4.
Берем уравнение для i = 3. Имеем ХЗ = ("-" + "+" + 入)(0 + 1) + ХЗ(0 + 1). Преобразуем уравнение к виду ХЗ = ХЗ(0 + 1) + ("-" + "+" + 入)(0 + 1). Тогда аЗ = (0 + 1). 傥=("-■■ + "+" + 入)(о + 1). Решением для ХЗ будет: ХЗ = рЗаЗ* = ("-" + "+" + 入) (0 + 1)(0 + 1)*
Подставим его в другие уравнения. Получаем:
Х4 - ("-" + "+" + Х)"."(0 + 1)(0 + 1)* + ("-" + "+" + &)(0 + 1)(0 + l)*"."a* + + (”_"+"+”+ 入)(o + 1)(0 + 1)*.
ШагЗ.
i := i + 1 » 4
Возвращаемся к шагу 2.
Шаг 2.
Имеем i =4 = 4.
Переходим к шагу 4.
Шаг 4
Уравнение для Х4 теперь имеет вид Х4 = ("-" + "+" + X)"."(О + 1)(0 + D* + ("-" + "+" + 入)(0 + 1)(0 + 1)*"."(0 + 1)* + ("-" + "+" + 入)(0 + 1)(0 + 1)*. Оно не нуждается в преобразованиях и содержит окончательное решение для Х4. Переходим к шагу 5.
Шаг 5.
1 := 1 - 1 = 3 > 0'
Переходим к шагу 6.
Шаг 6.
Уравнение для ХЗ имеет вид ХЗ = ("-" + "+" + 九)(0 + 1)(0 + 1)*. Оно уже содержит окончательное решение для ХЗ. Переходим к шагу 5.
Шаг 5.
i := 1 - 1 = 2 > 0
Переходим к шагу 6.
Шаг 6.
Уравнение для Х2 имеет вид Х2 = ("-" + "+" + Х)"."аа* + Х3"."а *. Подставим в него окончательное решение для Х3. Получим окончательное решение для Х2: Х2 = ("-" + "+" + Х)"."(0 + 1)(0 + 1)* + ("-" + "+" + 入)(0 + 1)(0 + 1)*"."(0 + D* Переходим к шагу 5.
Шаг 5.
i := 1 - 1 = 1 > 0
Переходим к шагу 6.
Шаг 6.
Уравнение для XI имеет вид XI = ("-" + "+" + X). Оно уже содержит окончательное решение для XI. Переходим к шагу 5.
Шаг 5.
I := 1 -1=0=0
Алгоритм завершен.
В итоге получили решение:
XI =("-"+"+" + 入)
Х2 =("-"+"+" + 入)"."(0+1)(0+1)* +("-"+"+"+X)(0+1)(0+l)*"."(0+D*
ХЗ =("-"+"+" + X)(0 +1)(0 +D*
X4 =("-"+"+" + 入)"."(0+1)(0+1)* +("-"+"+"+X)(0+1)(0+1)*"."(0+1)*
+(.._« + “+" + 九)(o + 1)(0 + 1)*
Выполнив несложные преобразования, это же решение можно представить в более простом виде:
XI =("-"+"+"+入)
Х2 =("-"+"+"+入)("."(0+1)+(0+1)(0+1)*".")(0+D*
ХЗ =("-"+"+"+入)(0 + 1)+
Х4 =("-"+"+"+入)("."(0+1)+(0+1)(0+1)*"."+(0+1))(0 + !)*•
Можно заметить, что регулярное выражение для Х4 описывает язык двоичных чисел с плавающей точкой.
Свойства регулярных языков
Основные свойства регулярных языков
Множество называется замкнутым относительно некоторой операции, если в результате выполнения этой операции над любыми элементами, принадлежащими данному множеству, получается новый элемент, принадлежащий тому же множеству.
Например, множество целых чисел замкнуто относительно операций сложения, умножения и вычитания, но оно не замкнуто относительно операции деления — при делении двух целых чисел не всегда получается целое число.
Регулярные множества (и однозначно связанные с ними регулярные языки) замкнуты относительно многих операций, которые применимы к цепочкам символов.
Например, регулярные языки замкнуты относительно следующих операций:
пересечения;*
объединения;
дополнения;
итерации;
конкатенации;
гомоморфизма (изменения имен символов и подстановки цепочек вместо символов).
Поскольку регулярные множества замкнуты относительно операций пересечения, объединения и дополнения, то они представляют булеву алгебру множеств. Существуют и другие операции, относительно которых замкнуты регулярные множества. Вообще говоря, таких операций достаточно много.
Проблемы, разрешимые для регулярных языков
Регулярные языки представляют собой очень удобный тип языков. Для них разрешимы многие проблемы, неразрешимые для других типов языков.
Например, доказано, что разрешимыми являются следующие проблемы:
Проблема эквивалентности. Даны два регулярных языка Lt(V) и L2(V). Необходимо проверить, являются ли эти два языка эквивалентными.
Проблема принадлежности цепочки языку. Дан регулярный язык L(V) и цепочка символов a eV*. Необходимо проверить, принадлежит ли цепочка данному языку.
Проблема пустоты языка. Дан регулярный язык L(V). Необходимо проверить, является ли этот язык пустым, то есть найти хотя бы одну цепочку а н 入, такую что asL(V).
Эти проблемы разрешимы вне зависимости от того, каким из трех способов задан регулярный язык. Следовательно, эти проблемы разрешимы для всех способов представления регулярных языков: регулярных множеств, регулярных грам-
матик и конечных автоматов. На самом деле достаточно доказать разрешимость любой из этих проблем хотя бы для одного из способов представления языка, тогда для остальных способов можно воспользоваться алгоритмами преобразования, рассмотренными выше1.
Для регулярных грамматик также разрешима проблема однозначности — доказано, что для любой регулярной грамматики можно построить эквивалентную ей однозначную регулярную грамматику.
Лемма о разрастании для регулярных языков
Иногда бывает необходимо доказать, является или нет некоторый язык регулярным. Существует способ проверки, является или нет заданный язык регулярным. Этот метод основан на проверке так называемой леммы о разрастании языка. Доказано, что если для некоторого заданного языка выполняется лемма о разрастании регулярного языка, то этот язык является регулярным; если же лемма не выполняется, то и язык регулярным не является [4. т. 1].
Лемма о разрастании для регулярных языков формулируется следующим образом: если дан регулярный язык и достаточно длинная цепочка символов, принадлежащая этому языку, то в этой цепочке можно найти непустую подцепочку, которую можно повторить сколь угодно много раз, и все полученные таким способом новые цепочки будут принадлежать тому же регулярному языку2.
Формально эту лемму можно записать так: если дан язык L, то 3 константа р > О, такая, что если aeL и |а| > р, то цепочку а можно записать в виде a = §Ре, где О < |р| < р, и тогда а' = &伊£, a'eL VI > 0.
Используя лемму о разрастании регулярных языков, докажем, что язык L = {апЬп | п > 0} не является регулярным.
Предположим, что этот язык регулярный, тогда для него должна выполняться лемма о разрастании. Возьмем некоторую цепочку этого языка a = апЬп и запишем ее в виде a = §Ре. Если Реа+ или РеЬ+, то тогда для i = 0 цепочка §Р°е = бе не принадлежит языку L, что противоречит условиям леммы; если же Реа+Ь+, тогда для i = 2 цепочка 邛2g = gppe не принадлежит языку L. Таким образом, язык L не может быть регулярным языком.
Построение лексических анализаторов
Три способа задания регулярных языков
Регулярные (праволинейные и леволинейные) грамматики, конечные автоматы (КА) и регулярные множества (равно как и обозначающие их регулярные выражения) —это три различных способа, с помощью которых можно задавать регу-
Возможны и другие способы представления регулярных множеств, а для них разрешимость указанных проблем будет уже не очевидна.
Если найденную подцепочку повторять несколько раз, то исходная цепочка как бы «разрастается» —отсюда и название «лемма о разрастании языков».
лярные языки. Регулярные языки, в принципе, можно определять и другими способами, но именно три указанных способа представляют наибольший интерес. Для этих трех способов определения регулярных языков можно записать следующие строгие утверждения.
Утверждение 1. Язык является регулярным множеством тогда и только тогда, когда он задан леволинейной (праволинейной) грамматикой.
Утверждение 2. Язык может быть задан леволинейной (праволинейной) грамматикой тогда и только тогда, когда он является регулярным множеством.
Утверждение 3. Язык является регулярным множеством тогда и только тогда, когда он задан с помощью конечного автомата.
Утверждение 4. Язык распознается с помощью конечного автомата тогда и только тогда, когда он является регулярным множеством.
Все три способа определения регулярных языков равноправны. Существуют алгоритмы, которые позволяют для регулярного языка, заданного одним из указанных способов, построить другой способ, определяющий тот же самый язык. Это не всегда справедливо для других способов, которыми можно определить регулярные языки [4, т. 1, 9, 15, 19, 28].
Из всех возможных преобразований практический интерес представляют два преобразования:
построение регулярного выражения, задающего язык, на основе регулярной грамматики;
построение КА на основе регулярной грамматики.
Ниже рассмотрены алгоритмы, позволяющие выполнять эти преобразования.
Построение регулярного выражения для языка, заданного леволинейной грамматикой
Постановка задачи/
Для любого регулярного языка, заданного регулярной грамматикой, можно получить регулярное выражение, определяющее тот же язык.
Задача формулируется следующим образом: имеется леволинейная грамматика G(VT,VN,P,S), необходимо найти регулярное выражение над алфавитом VT, определяющее язык L(G), заданный этой грамматикой.
Задача решается в два этапа:
На основе грамматики G, задающей язык L(G), строим систему уравнений с регулярными коэффициентами.
Решаем полученную систему уравнений. Решение, полученное для целевого символа грамматики S, будет представлять собой искомое регулярное выражение, определяющее язык L(G).
Поскольку алгоритм решения системы уравнений с регулярными коэффициентами известен, то далее будет рассмотрен только алгоритм, позволяющий на
основе грамматики G(VT,VN,P,S) построить систему уравнений с регулярными коэффициентами.
Построение системы уравнений с регулярными коэффициентами на основе регулярной грамматики
В данном случае преобразование не столь элементарно. Выполняется оно следующим образом:
Обозначим символы алфавита нетерминальных символов VN следующим образом: VN = {Х[, Х2，…，XJ. Тогда все правила грамматики будут иметь вид: Xi -> XjY или Xi -> у Xi(XjeVN, yeVT*; целевому символу грамматики S будет соответствовать некоторое обозначение Хк.
Построим систему уравнений с регулярными коэффициентами на основе переменных Хь Х2,.... Хп:
Х[ = а01 + Х1(Хн +Х2а21 + ... + Хпап1■
X? = СЦ)2 + Х[(Х12 +X2OI22 + …+ Хпап2
Xn = аоп + xtaln +X2a2n + ... + Xnann
Коэффициенты aOi, a02,..., aOn выбираются следующим образом:
aoi e(Yi + ¥2 + …+ Ym)，
Если во множестве правил Р грамматики G существуют правила К т % | у21-1 Ут； а@ = °,
если правил такого вида не существует.
Коэффициенты а^, aj2,..., Ojn для некоторого j выбираются следующим образом:
% = (Yi + ¥2 + …+ Ym)，
если во множестве правил Р грамматики G существуют правила X, -> Х# | Х^2 I…I Xj¥m，
5 = 0，
если правил такого вида не существует.
Находим решение построенной системы уравнений.
Доказано, что решение для Хк, которое обозначает целевой символ S грамматики G, будет представлять собой искомое регулярное выражение, обозначающее язык, заданный грамматикой G.
Остальные решения системы будут представлять собой регулярные выражения, обозначающие понятия грамматики, соответствующие ее нетерминальным символам.
СОВЕТ
В принципе, для поиска регулярного выражения, обозначающего язык, заданный грамматикой, не нужно искать все решения — достаточно найти решение для Х»
Пример построения регулярного выражения для языка, заданного леволинейной грамматикой
Например, рассмотрим леволинейную грамматику, определяющую язык двоичных чисел с плавающей точкой G({".". "-". "+", "О". " 1"}. {<знак>, <дробное>, <целое>, <число>}, Р, <число>):
Р:
<знак> т - I + I 入
<дробное> т <знак>.0 | <знак>.1 | <целое>. | <дробное>0 | <дробное>1
<целое> т <знак>0 | <знак>1 | <целое>0 | <целое>1
<число> т <дробное> | <целое>
Обозначим символы множества VN = {<знак>, <дробное>, <целое>, <число>) соответствующими переменными Xi( получим: VN = {Х〔，Х2. Х3, Х4}.
Построим систему уравнений на основе правил грамматики G:
XI = ("-" + "+" + 入)
Х2 = XI"."(0+1) + ХЗ"." + X2(0+l)
ХЗ = ХК0+1) + ХЗ(0+1)
Х4 = Х2 + ХЗ
Эта система уравнений уже была решена выше. В данном случае нас интересует только решение для Х4, которое соответствует целевому символу грамматики G <число>.
Решение для Х4 может быть записано в виде:
Х4 = ("-" + "+" + 入)("."(0+1) + (0+1)(0+1)*"." + (0+l))(0+D* то есть
<число> = ("-" + "+" + 入)("."(0+1) + (0+1)(0+1)*"." + (0+1))(0+1)*
Это и есть регулярное выражение, определяющее язык двоичных чисел с плавающей точкой, заданный грамматикой G.
Построение конечного автомата на основе леволинейной грамматики
Постановка задачи
На основе имеющейся регулярной грамматики можно построить эквивалентный ей КА и, наоборот, для заданного КА можно построить эквивалентную ему регулярную грамматику.'
Это очень важное утверждение, поскольку регулярные грамматики используются для определения лексических конструкций языков программирования. Создав автомат на основе известной грамматики, мы получаем распознаватель для лексических конструкций данного языка. Таким образом удается решить задачу разбора для лексических конструкций языка, заданных произвольной регул яр-
ной грамматикой. Обратное утверждение также полезно, поскольку позволяет узнать грамматику, цепочки языка которой допускает заданный автомат.
Все языки программирования определяют нотацию записи «слева направо». В той же нотации работают и компиляторы. Поэтому далее рассмотрены алгоритмы для леволинейных грамматик. Доказано, что аналогичные построения возможно выполнить и для праволинейных грамматик.
Задача формулируется следующим образом: имеется леволинейная грамматика G(VT,VN,P,S), задающая язык L(G), необходимо построить эквивалентный ей конечный автомат M(QV,3,q(),F), задающий тот же язык: L(G) = L(M).
Задача решается в два этапа:
Исходную леволинейную грамматику G необходимо привести к автоматному виду G'.
На основе полученной автоматной леволинейной грамматики G'(VT,VN',P',S) строится искомый автомат M(QV,6,q(),F).
Алгоритм преобразования к автоматному виду был рассмотрен выше, поэтому здесь рассмотрим только алгоритм построения КА на основе автоматной леволинейной грамматики.
Алгоритм построения конечного автомата на основе автоматной леволинейной грамматики
Построение КА M(QV,B,q(),F) на основе автоматной леволинейной грамматики G(VT,VN,P,S) выполняется по следующему алгоритму:
Шаг 力 Строим множество состояний автомата Q. Состояния автомата строятся таким образом, чтобы каждому нетерминальному символу из множества VN грамматики G соответствовало одно состояние из множества Q автомата М. Кроме того, во множество состояний автомата добавляется еще одно дополнительное состояние, которое будем обозначать Н. Сохраняя обозначения нетерминальных символов грамматики G, для множества состояний автомата М можно записать: Q = VNu{H}.
Шаг 2. Входным алфавитом автомата М является множество терминальных символов грамматики G: V = VT.
Шаг 3. Просматриваем все множество правил исходной грамматики.
Если встречается правило вида А -> teP, где AeVN, twVT, то в функцию переходов 5(H,t) автомата М добавляем состояние A: Ae5(H,t).
Если встречается правило вида А -> BteP, где A,BeVN, teVT, то в функцию переходов 3(B,t) автомата М добавляем состояние A: Ae5(B,t).
Шаг 4. Начальным состоянием автомата М является состояние Н: q0 = Н.
Шаг 5. Множество конечных состояний автомата М состоит из одного состояния. Этим состоянием является состояние, соответствующее целевому символу грамматики G: F = {S}.
На этом построение автомата заканчивается.
Пример построения конечного автомата на основе заданной леволинейной грамматики
Рассмотрим грамматику G({"a","(","*".")"."{"'"}"}'{S.С,К}.P.S) (символы а, (, * ), {, } из множества терминальных символов грамматики взяты в кавычки, чтобы выделить их среди фигурных скобок, обозначающих само множество):
Р:
S f С*) I К}
С ^ (* I Са I С{ I С} I С( I С* I С)
К ^ { | Ка | К( | К* | К) | К{
Это леволинейная регулярная грамматика. Преобразование ее к автоматному виду уже было выполнено ранее (в разделе «Регулярные и автоматные грамматики» в этой главе).
Получим леволинейную автоматную грамматику следующего вида: G'({"а","(". (S.Sl.C.Cl.KJ.P'.S):
p,:
S т S1) | К}
SI f с*
С f Cl* I Са I С{ I С} I С( I С* I С)
С1 т (
К ^ { I Ka I К( I К* I К) I К{
Для удобства переобозначим нетерминальные символы С1 и S1 символами D и Е. Получим грамматику G'({"а". "("."*".")"."{"•"}"}. {S.E.С.D. К}. Р'.S):
p,:
S т Е) I К}
Е -> С*
С D* I Са I С{ I С} I С( I С* I С)
D т (
К ^ { I Ka I К( I К* I К) I К{
Построим конечный автомат M(Q,V,S,qo，F), эквивалентный указанной грамматике.
Шаг 1.
Строим множество состояний автомата. Получаем: Q = VNu{H} = {S.E.C.D.K.H}.
Шаг 2.:
В качестве алфавита входных символов автомата берем множество терминальных символов грамматики. Получаем: V = {"а"."("."*".")"."{"•"}"}•
Шаг 3.
Рассматриваем множество правил грамматики.
Для правил S -> Е) | К} имеем 5(Е.")") = {S}; 5(К."}") = {S}.
Для правила Е -» С* имеем 5(С,"*") = {Е}.
Для правил С т D* | Са | С{ | С} | С( | С* | С) имеем 6(D."*") = {С}: 5(С,"а")= {С}; 5(С,"{") = {С}: 5(С."}") = {С}: 5(С,"(") = {С}: S(C,"*") = {Е.С}; 5(С.")") = {С}.
Для правила D -» ( имеем S(H."(") = {D}.
J } } IJ } J и J } >yj J } J » J 1J KDKKKKKSCCCCCECS ft { ft ft rt ft { rl{ { { { { { { f<lJ } } IJ } J и J } >yj J } J » J 1J KDKKKKKSCCCCCECS ft { ft ft rt ft { rl{ { { { { { { f<lДля правил К -> { | Ка | К( | К* | К) | К{ имеем 8(Н."{") - {К}； б(К,"а") ^ (К}: 5(К."(") - {К}： 8(К."*") - {К}： 8(К,")") - {К}: 8 (К,"{") - {К}.?'
J } } IJ } J и J } >yj J } J » J 1J KDKKKKKSCCCCCECS ft { ft ft rt ft { rl{ { { { { { { f<l
J } } IJ } J и J } >yj J } J » J 1J KDKKKKKSCCCCCECS ft { ft ft rt ft { rl{ { { { { { { f<l
Шаг 4.
Начальным состоянием автомата является состояние qO « Н.
Шаг 5.
Множеством конечных состояний автомата является множество F = {S}.
Выполнение алгоритма закончено.
В итоге получаем автоматM({S,E,C,D,K,H}, {"а"."("."*4'.")"."{"."}"}-З.НДЗ}) с функцией переходов:
5(Н."{")= 8(Н,"(")- 5(К,"а")- 8(К."(")= 8(К,"*")= 5(К.")")= 5(К."{")= 8(К,"}")= 5(D."*")- 5(С,"а")= 8(С."{")- 5(С."}")= 8(С."(")- 5(С."*")- 5(С.")")- 5(Е.")")-
Рис. 3.8. Недетерминированный КА для языка комментариев в Borland PascalРис. 3.8. Недетерминированный КА для языка комментариев в Borland PascalГраф переходов этого автомата изображен на рис. 3.8.
Рис. 3.8. Недетерминированный КА для языка комментариев в Borland Pascal
Рис. 3.8. Недетерминированный КА для языка комментариев в Borland Pascal
Это недетерминированный конечный автомат, поскольку существует состояние, в котором множество, получаемое с помощью функции переходов по одному и тому же символу, имеет более одного следующего состояния. Это состояние С и функция 8(С,"*") = {Е.С}.
128
Моделировать поведение недетерминированного КА — непростая задача, поэтому можно построить эквивалентный ему детерминированный КА. Полученный таким путем КА можно затем минимизировать.
В результате всех преобразований получаем детерминированный конечный автомат М'({S.Е.С.D.K.H}. {"а". "(","*",")","{","}"},S'.H,{S}) с функцией переходов:
5'(Н,"{")= бЧН.'Ч")= 5'(К,"а")= 5'(К,"(")= 5'(К."*")= 5'(К.")")=
5'(К."{")= 5'(К."}")= 5'(D."*")= 5'(С."а")= 5'(С,"{")= 5'(С."}")=
8'(С."(")= 5'(С.")")= 5'(С."*")= 5'(Е."а")= 5'(Е."{")= 5'(Е."}")=
5'(Е."(")= 5'(Е."*")= 5'(Е,")")=
、—>J 1?J 1?J ч> ■»、>，<^*; 1> J、—>J 1> J ч> ■»、1■*;、1■*; ч> ■»、> j、> ;、：，ч> ■» ч> ■»、—>J ч> ■» 1> JKDKKKKKSCCCCCCECCCCESfl { fl f<l f<l { { { f<l f<l { f\ л { л /I /I { Л { ft.、—>J 1?J 1?J ч> ■»、>，<^*; 1> J、—>J 1> J ч> ■»、1■*;、1■*; ч> ■»、> j、> ;、：，ч> ■» ч> ■»、—>J ч> ■» 1> JKDKKKKKSCCCCCCECCCCESfl { fl f<l f<l { { { f<l f<l { f\ л { л /I /I { Л { ft.Рис. 3.9. Детерминированный КА для языка комментариев в Borland PascalРис. 3.9. Детерминированный КА для языка комментариев в Borland PascalГраф переходов этого автомата изображен на рис. 3.9.
、—>J 1?J 1?J ч> ■»、>，<^*; 1> J、—>J 1> J ч> ■»、1■*;、1■*; ч> ■»、> j、> ;、：，ч> ■» ч> ■»、—>J ч> ■» 1> JKDKKKKKSCCCCCCECCCCESfl { fl f<l f<l { { { f<l f<l { f\ л { л /I /I { Л { ft.
、—>J 1?J 1?J ч> ■»、>，<^*; 1> J、—>J 1> J ч> ■»、1■*;、1■*; ч> ■»、> j、> ;、：，ч> ■» ч> ■»、—>J ч> ■» 1> JKDKKKKKSCCCCCCECCCCESfl { fl f<l f<l { { { f<l f<l { f\ л { л /I /I { Л { ft.
Рис. 3.9. Детерминированный КА для языка комментариев в Borland Pascal
Рис. 3.9. Детерминированный КА для языка комментариев в Borland Pascal
На основании этого автомата можно легко построить распознаватель. В данном случае мы можем получить распознаватель для двух типов комментариев языка программирования Borland Pascal, если учесть, что а может означать любой алфавитно-цифровой символ, кроме символов (, * ), {, }.
Построение леволинейной грамматики на основе конечного автомата
Задача формулируется так: имеется конечный автомат M(Q,V,S,q0,F), необходимо построить эквивалентную ему леволинейную грамматику G(VT,VN,P,S).
Построение выполняется по следующему алгоритму:
Шаг 1. Множество терминальных символов грамматики G строится из алфавита входных символов автомата М: VT = V.
Шаг 2. Множество нетерминальных символов грамматики G строится на основании множества состояний автомата М таким образом, чтобы каждому состоянию автомата, за исключением начального состояния, соответствовал один нетерминальный символ грамматики: VN = Q\{q0}.
Шаг 3. Просматриваем функцию переходов автомата М для всех возможных состояний из множества Q для всех возможных входных символов из множества V. Если имеем 5(A,t) = 0, то ничего не выполняем.
Если имеем 5(A,t) = {В1(В2，…,Bn}, п > 0, где AeQ, Vn > i > 0: B.eQ, teV, тогда для всех состояний Bj выполняем следующее:
добавляем правило В, -> t во множество Р правил грамматики G, если А = q0; □ добавляем правило В, -» At во множество Р правил грамматики G, если А н q0. Шаг 4. Если множество конечных состояний F автомата М содержит только одно состояние F = {Fo}, то целевым символом S грамматики G становится символ множества VN, соответствующий этому состоянию: S = Fo; иначе, если множество конечных состояний F автомата М содержит более одного состояния F = {FbF2，…,Fn}, n > 1, тогда во множество нетерминальных символов VN грамматики G добавляется новый нетерминальный символ S: VN = VNu{S}, а во множество правил Р грамматики G добавляются правила: S -» Ft | F21...| Fn.
На этом построение грамматики заканчивается.
Примеры построения лексических анализаторов
Теперь можно рассмотреть практическую реализацию лексических анализаторов. В принципе, компилятор может иметь в своем составе не один, а несколько лексических анализаторов, каждый из которых предназначен для выборки и проверки определенного типа лексем.
Таким образом, обобщенный алгоритм работы простейшего лексического анализатора в компиляторе можно описать следующим образом:
из входного потока выбирается очередной символ, в зависимости от которого запускается тот или иной сканер (символ может быть также проигнорирован либо признан ошибочным);
запущенный сканер просматривает входной поток символов программы на исходном языке, выделяя символы, входящие в требуемую лексему, до обнаружения очередного символа, который может ограничивать лексему, либо до обнаружения ошибочного символа;
при успешном распознавании информация о выделенной лексеме заносится в таблицу лексем и таблицу идентификаторов, алгоритм возвращается к первому этапу и продолжает рассматривать входной поток символов с того места, на котором остановился сканер;
при неуспешном распознавании выдается сообщение об ошибке, а дальнейшие действия зависят от реализации сканера — либо его выполнение прекращается, либо делается попытка распознать следующую лексему (идет возврат к первому этапу алгоритма).
В целом, техника построения сканеров основывается на моделировании работы детерминированных и недетерминированных КА с дополнением функций распознавателя вызовами функций обработки ошибок, а также заполнения таблиц лексем и таблиц идентификаторов. Такая техника не требует сложной математической обработки и принципиально важных преобразований входных грамматик. Для разработчиков сканера важно только решить, где кончаются функции сканера и начинаются функции синтаксического разбора. После этого процесс построения сканера легко поддается автоматизации.
Лексический анализатор целочисленных констант языка С
Рассмотрим пример анализа лексем, представляющих собой целочисленные константы в формате языка С. В соответствии с требованиями языка, такие константы могут быть десятеричными, восьмеричными или шестнадцатеричными. Восьмеричной константой считается число, начинающееся с 0 и содержащее цифры от 0 до 7; шестнадцатеричная константа должна начинаться с последовательности символов Ох и может содержать цифры и буквы от а до f. Остальные числа считаются десятеричными (правила их записи напоминать, наверное, не стоит). Константа может начинаться также с одного из знаков, + или -, а в конце цифры, обозначающей значение константы, в языке С может следовать буква или две буквы, явно обозначающие ее тип (u, U — unsigned; h, Н — short; 1, L — long).
При построении сканера будем учитывать, что константы входят в общий текст программы на языке С. Во избежание путаницы и для сокращения объема информации в примере будем считать, что все допустимые буквы являются строчными (читатели легко смогут самостоятельно расширить пример для прописных букв, которые язык С в константах не отличает от строчных).
Рассмотренные выше правила могут быть записаны в форме Бэкуса—Наура в грамматике целочисленных констант для языка С.
G({S, W, U. L. V, D. G, X, Q, Z, N}. {0...9, х. a...f. и, 1. h. 1},P,S)
Р:
S G丄I Z丄I D丄I Q丄I U丄I L丄I V丄I W丄
W -> LuIVuIUIIUh
U -> GuIZuIHuIQu
L -> G1IZ1IHlIQI
V -> GhIZhIHhIQh
DtY|2|3|4|5|6|7|8|9|
N1 I N2IN3IN4IN5IN6IN7IN8IN9I
DO I DII02ID3ID4ID5ID6I07ID8I D9 I
Z8 | Z9|Q8|Q9
G ->Х0|XI|Х2|ХЗ|Х4|Х5|Х6|Х7|Х8| Х9 |
Ха | ХЬ|Хс|Xd|Хе|Xf|
GO | G1|G2|G3|G4|G5|G6|G7|G8|G9|
Ga I GbIGcIGdIGeIGf
X -> Zx
Q -> ZOIZ1IZ2IZ3IZ4IZ5IZ6IZ7I
QO I QIIQ2IQ3IQ4IQ5IQ6IQ7
Z -> 0 I NO
N - + I -
Эта грамматика является леволинейной автоматной регулярной грамматикой. По ней можно построить КА, который будет распознавать цепочки входного языка (см. раздел «Конечные автоматы»). Граф переходов этого автомата приведен на рис. 3.10. Видно, что построенный автомат является детерминированным КА, поэтому в дальнейших преобразованиях он не нуждается. Начальным состоянием автомата является состояние Н.
Приведем автомат к полностью определенному виду — дополним его новым состоянием Е, на которое замкнем все дуги неопределенных переходов. На графе автомата дуги, идущие в это состояние, не нагружены символами — они обозначают функцию перехода по любому символу, кроме тех символов, которыми уже помечены другие дуги, выходящие из той же вершины графа (такое соглашение
принято, чтобы не загромождать обозначениями граф автомата). На рис. 3.10 это состояние и связанные с ним дуги переходов изображены пунктирными линиями. При построении КА знаком 丄 были обозначены любые символы, которыми может завершаться целочисленная константа языка С. Однако в реальной программе этот символ не встречается, поскольку границы лексем в ней явно не указаны. При моделировании КА надо решить проблему определения границ лексем. Следует принять во внимание, какими реальными символами входного языка может завершаться целочисленная константа языка С.
В языке С в качестве границы константы могут выступать:
знаки пробелов, табуляции, перевода строки;
разделители (,),[,],{,},,,：,;；
знаки операций +, -,*,/,&, |, ?, ~, <, >，人，=,%.
Теперь можно написать программу, моделирующую работу указанного автомата. Ниже приводится текст функции на языке Pascal, реализующей данный распознаватель. Результатом функции является текущее положение считывающей головки анализатора в потоке входной информации после завершения разбора лексемы при успешном распознавании либо 0 при неуспешном распознавании (если лексема содержит ошибку).
В программе переменная 1 State отображает текущее состояние автомата, переменная 1 является счетчиком символов входной строки. В текст программы вписаны комментарии в те места функции, где возможно выполнить запись найденной лексемы в таблицу лексем и таблицу символов, а также выдать сообщение об обнаруженной ошибке.
function RunAuto (const slnput： string： IPos： integer)： Integer；
(* slnput - входная строка исходного текста；
IPos - текущее положение считывающей головки 80 входной строке исходного текста *)
type
TAutoState = (AUTO_H, AUTO_S, AUTO_W, AUTO_U, AUTO_L. AUTO_V, AUTO_D, AUTO_G, AUTO_X, AUTO_Q, AUTO_Z, AUTO_N, AUTO_E):
const
AutoStop = [' '. #10. #13. #7.
'+ '.. '&', ' I'. '?'., '<'. '>'.. ' = '. T];
var
iState : TAutoState；
i ,1L : integer；
sOut : string； begin
i := iPos；
IL ：= Length(slnput)；
sOut ：='';
iState := AUT0_H;
repeat
case 1 State of
AUT0_H：
case slnput[1] of
iState:=AUT0_N；
'О':1 State:=AUTOJ:
T'..'9‘： IState:=AUTO_D；
else1 State:=AUTO_E;
end；
AUTO_N:
case slnput[i] of
'0':iState := AUTO_Z;
. '9' ： 1 State ：= AUTO二D： elseiState := AUTO_E；
end;
AUTO_Z:
case slnput[i] of
'x':I State := AUTO_X;
'O'.. '7': iState := AUTOR;
'8'.'9'： iState := AUTO_D: else
if slnput[1] in AutoStop then iState := AUTO_S
else iState := AUTO_E;
end;
AUTO_X:
case slnput[1] of 'O'..'9'.
'a'.. 'f': iState ：= AUTO_G;
else IState := AUTO_E;
end;
AUTO_Q：
case slnput[i] of
'O'..'7': iState:=AUTO_Q：
'8'.'9':iState:=AUTO_D；
'u' ：iState:=AUTO_U:
'Г：IState:=AUTOJ:
'h':iState:=AUTO_V;
else
if slnput[1] in AutoStop then IState := AUTO_S
else IState := AUTO_E;
end；
AUTO_D：
case slnput[i] of
'0'..'9': iState:=AUTO_D;
'u' ：iState:=AUTO_U;
'1'：IState：=AUTOj；
'h':iState:=AUTO_V:
else
1f slnputCi] in AutoStop then IState := AUTO_S
else iState := AUTO_E;
end;
AUTO_G:
case slnput[1] of
'O'..'9'.
'a'.. 'f ： IState：=AUTO_G:.
U:IState:=AUTOlu：
'Г；IState:=AUTOJ:
'h' ：iState：=AUTO);
else
if slnput[1] in AutoStop then IState := AUTO_S else IState ：= AUTO_E:
end：
AUTO_U：
case slnput[i] of
'1','h'： IState := AUTO_W:
else
if slnput[i] in AutoStop then IState := AUTO_S else IState ：= AUTO_E:
end；
AUTO_L:
case slnput[i] of
U:IState := AUT0_W;
else
if slnput[i] in AutoStop then IState := AUT0_S
else IState := AUT0_E:
end：
AUT0_V：
case slnput[i] of
'u':IState := AUT0_W；
else
if slnput[i] in AutoStop then IState := AUTO_S else IState ：= AUTO_E；
end：
AUT0_W：
if slnputEi] in AutoStop then
IState := AUT0_S
else IState ：= AUT0_E；
end {case}：
If not (iState in [AUT0_E.AUT0_S]) then begin
sOut ：= sOut + slnput[i];
i ：= 1 + 1；
end：
until ((IState = AUTO_E) or (IState = AUTO_S) or (1 > ID)；
if (IState = AUTO S) or (i > iL) then
begin
{ Сюда надо вставить вызов функций записи лексемы sOut }
RunAuto := 1;
end
else
begin
{ Сюда надо вставить вызов функции формирования сообщения об ошибке } RunAuto ：= 0;
end:
end; { RunAuto }
Конечно, рассмотренная программа — это всего лишь пример для моделирования такого рода автомата. Она построена так, чтобы можно было четко отследить соответствие между этой программой и построенным на рис. 3.10 автоматом. Конкретный распознаватель будет существенно зависеть от того, как организовано его взаимодействие с остальными частями компилятора. Это влияет на возвращаемое функцией значение, а также на то, как она должна действовать при обнаружении ошибки и при завершении распознавания лексемы.
В данном примере предусмотрено, что основная часть лексического анализатора сначала считывает в память весь текст исходной программы, а потом начинает его последовательный просмотр. В зависимости от текущего символа вызывается тот или иной сканер. По результатам работы каждого сканера разбор либо продолжается с позиции, которую вернула функция сканера, либо прерывается, если функция возвращает 0.
Лексический анализатор для поиска строк в исходном тексте программы, написанной на языке Pascal
Действия, решаемые этим лексическим анализатором, возникли из реальной практической задачи. Эта задача является удачным примером практического применения лексических анализаторов, причем в данном случае лексический анализатор не является частью компилятора, а выступает как самостоятельная программная единица. Такие примеры довольно часто встречаются в реальной жизни, поскольку, как уже было отмечено, лексический анализ находит применение не только в компиляции.
Задача-, имеется исходный текст программы, написанной на языке Pascal, необходимо найти в этом тексте все строковые константы и записать их в отдельный файл.
ПРИМЕЧАНИЕ
На практике такая задача может возникнуть, например, для перевода интерфейса и текстовых сообщений программы с одного естественного языка на другой (скажем, с русского на английский). В этом случае выбранные из исходного текста строки надо отдать переводчику, которому весь исходный текст не интересен (да и разбираться в нем он не сможет).
Надо отметить, что в данном случае задача лексического анализатора значительно уже, чем задача лексического анализатора компилятора Pascal. Анализатор
должен найти только все строковые константы, не обращая никакого внимания на все остальные лексемы. Также нет необходимости заполнять таблицу лексем и таблицу идентификаторов — сопоставление лексем и дальнейшая обработка текста не входят в постановку задачи. И, конечно же, нет необходимости проверять синтаксическую правильность исходной программы — это не задача лексического анализатора.
Именно по причине наглядности и простоты решаемой задачи данный лексический анализатор выбран в качестве удачного примера.
Построение лексического анализатора начнем с построения грамматики исходного языка. Исходным языком является язык строковых констант Pascal. Для построения его грамматики следует разобраться, что представляет собой строковая константа в языке Pascal.
Строковая константа в языке Pascal может состоять из одной или более частей, соединенных между собой знаком +. Каждая часть строковой константы начинается с символа ' (одинарная кавычка) и заканчивается символом ' (одинарная кавычка). В состав строковой константы могут входить любые алфавитно-цифровые символы, но если в нее надо включить одинарную кавычку, то она должна быть повторена дважды: ''. Также в строку могут быть включены коды символов. В языке Pascal они записываются восьмеричными цифрами, следующими за знаком #. Коды символов включаются в строку либо сразу после завершающей одинарной кавычки, либо с помощью знака +. Для лексического анализатора строковая константа считается законченной, если после очередной ее части он встретил любой алфавитно-цифровой символ, кроме знаков + и #, или конец файла. Все символы, не входящие в строковые константы, анализатором должны игнорироваться.
Для простоты и удобства работы далее будем символом b обозначать все незначащие символы языка (пробелы, знаки табуляции и перевода строки), символом d — все допустимые восьмеричные цифры (от 0 до 7), а символом а — все остальные алфавитно-цифровые символы, кроме символов, обозначенных через b и d, а также символов ', + и #. Символом 丄 будем обозначать конец файла.
Тогда грамматику языка строковых констант Pascal можно записать следующим образом: Gl({a,b.d. '. + ,#}. {51,82.83,84.01,02,8} .P.S), а ее правила Р:
S1 -» 1 I Sia I Sib I Sid I S1+ I SI# | S2' | S4' | D「
S2 -> 5Г
S3 т S2b I S3b .
S4 т S2+ I S3+ I S4b I D1+ | D2+
DI - # I S2# I S4# I Did I DI#
D2 т Dlb I D2b
S a I b I d I + I S2a I S3a I S4a I Dia I D2a I S21 | S31 | Dll | D21
Эта грамматика учитывает структуру всех возможных строковых констант языка Pascal, но она недостаточна для построения лексического анализатора, поскольку не учитывает комментарии, которые могут встречаться в тексте исход-
ной программы. Естественно, анализатор должен игнорировать комментарии и все сороковые константы, которые могут быть внутри комментариев.
Язык Pascal предусматривает два независимых варианта комментариев. Первый вариант: комментарий начинается последовательностью символов (* и заканчивается последовательностью символов *), второй вариант: комментарий начинается с символа { и заканчивается символом }. Комментарии могут содержать любые алфавитно-цифровые символы.
Тогда грамматику комментариев языка Pascal можно записать следующим образом: G2({a,b,d.{C1.C2.C3.C4,S}.P.S), а ее правила Р：
С1 -> ( | СК
С2 т Cl* I С2а I C2b | C2d | С2' | С2+ | C2# | С2( | ⑵ | С2{ | С2} | СЗа | СЗЬ | C3d I СЗ' I СЗ+ I C3# I С3( I С3{ | СЗ}
СЗ т С2* I СЗ*
С4T { I Cl{ I С4а I C4b | C4d | С4' | С4+ | C4# | С4( | С4* | С4) | С4{
S -> a I b I d I + I I ) I Cla I Clb I Cid I С1+ I Cl) I СЗ) I С4}
Здесь а обозначает уже все алфавитно-цифровые символы, кроме символов, обозначенных ранее через b и d, а также символов ',+,#,(,*,),{ и }.
ПРИМЕЧАНИЕ
Эта грамматика построена таким образом, чтобы игнорировать исходный текст программы, не входящий в комментарии.
На основе двух построенных грамматик Gj и G2 можно реализовать лексический анализатор, решающий задачу в два этапа (он как бы будет состоять из двух лексических анализаторов). На первом этапе из исходной программы исключаются все комментарии анализатором, на основе грамматики G2, и полученный в результате текст записывается в промежуточное хранилище данных (файл). На втором этапе исходный текст из промежуточного хранилища обрабатывается анализатором на основе грамматики Gt и в нем ищутся все строковые константы. Получим двухпроходный лексический анализатор.
Однако анализатор можно упростить, если построить грамматику языка, который будет включать в себя и строковые константы, и комментарии языка Pascal. Такую грамматику можно построить на основе G〔 и G2. Надо только учесть, что строки и комментарии могут следовать в тексте исходной программы друг за другом в произвольном порядке, а также то, что символы, ограничивающие комментарии — (,*,),{ и }, — могут входить в состав строки.
Грамматику строковых констант и комментариев языка Pascal можно записать следующим образом:
3({a,b,d,'.+.#.(.*.).{.}}.{01,02.03.04,81,82,S3,S4.D1>D2,S},P.S), а ее правила Р:
->( IСК IS2( IS3( IS4( IDl( I D2(
：2 ->Cl*IC2aI C2b|C2d|C2'| C2+ | C2# | C2( | C2) | C2{ | C2} | C3a | C3b |
：3d IC3'IC3+I C3#IC3(IC3{I C3}
：3 ->C2*IC3*
С4 -> { ICl{ IS2{ IS3{IS4{IDl{|D2{|C4a|C4b|C4d|C4'|C4+|C4#|
C4( I C4*I C4)I C4{
SI -» • ISia ISib ISidIS1+ISI#|Sl(|SI*|SI)|Sl{|SI}|S2'|S4'|
DI' I СГ
S2 -> 8Г
S3 -» S2b I S3b
S4 т S2+ I S3+ I S4b I D1+ | D2+
DI -> # I S2# I S4# I Did I DI# | Cl#
D2 -» Dlb I D2b
S a I b I d I I I I Cla I Clb I Cid I C1+ I Cl) I C3) I C4} I S2a | S2)
I S3a I S3) I S4a | Dia | DI) | D2a | D2) | S21 | S31 | DI丄 | D21
На основе этой грамматики можно строить однопроходный лексический анализатор, выполняющий поиск строковых констант в исходной программе на языке Pascal. Данный анализатор игнорирует комментарии, а также весь остальной текст исходной программы, не содержащий строковых констант.
Эта грамматика является автоматной грамматикой, поэтому на ее основе элементарно просто построить КА. Он будет иметь 12 состояний. Можно заметить, что построенный КА будет детерминированным, поэтому его сразу можно реализовать в программном коде лексического анализатора.
Лексический анализатор, моделирующий работу данного КА, начинает свое функционирование с начала просмотра исходного текста программы. При этом КА находится в начальном состоянии. Если символ на входе не относится ни к комментарию, ни к строковой константе, то анализатор просто пропускает его — при этом КА сразу переходит в конечное состояние, а потом анализатор должен вернуть его в начальное состояние. Если символ относится к строковой константе, то КА начинает переходить по всем состояниям, относящимся к строковой константе (все состояния Si и D1). Лексический анализатор должен при этом запоминать все символы константы (строку). При переходе КА в конечное состояние S анализатор записывает строку в результирующий файл, а КА возвращает в начальное состояние. Если встречается комментарий, то лексический анализатор должен пропустить все символы до конца комментария (КА при этом находится в состояниях С1).
Таким образом, граф переходов КА лексического анализатора поиска строковых констант языка Pascal должен быть нагружен функциями:
создания пустой строки для записи очередной строковой константы;
добавления символа или подстроки в конец строковой константы;
записи строковой константы в результирующий файл и очистка строки для следующей строковой константы.
Нагрузив граф переходов КА соответствующими функциями, получим конечный преобразователь, преобразующий исходную программу на языке Pascal в файл строковых констант этой программы.
Можно заметить, что построенный КА не является полностью определенным. Это вызвано тем, что существуют ошибки, которые могут быть обнаружены с по-
мощью данного лексического анализатора (хотя это и не является его основной задачей). Примером такой обнаруживаемой ошибки является незакрытый комментарий. Ошибки можно обозначить отдельным «ошибочным» нетерминальным символом грамматики Е и соответствующим состоянием КА. Правило обнаружения ошибок можно записать в виде:
Е -» } I Cl} I S2d I S2* I S2} | S3d | S3' | S3# | S3* | S3} | S4d | S4+ | S4* | S4) I S4) I DI* I DI} I D2d | D2' | D2# | D2* | D2} | СИ | С2丄 | С3± | С4± | SU I S41
Дополнив грамматику G этим правилом, можно построить полностью определенный детерминированный КА. Дуги переходов в состояние Е этого автомата надо нагрузить функцией выдачи пользователю соответствующего сообщения об ошибке.
СОВЕТ
Рекомендуем читателям самостоятельно реализовать лексический анализатор на основе построенной грамматики и проверить его работу на любом исходном тексте программы для языка Pascal.
Данный пример достаточно наглядно иллюстрирует, как просто можно решать задачи лексического анализа, используя математический аппарат регулярных грамматик и КА. После построения КА задача разработчика заключается только в моделировании его работы (что элементарно просто) и реализации всех необходимых функций при переходе КА из одного состояния в другое1.
Автоматизация построения лексических анализаторов (программа LEX)
Лексические распознаватели (сканеры) — это не только важная часть компиляторов. Как было показано выше на примерах, лексический анализ применяется во многих других областях, связанных с обработкой текстовой информации на компьютере. Прежде всего, лексического анализа требуют все возможные командные процессоры и утилиты, предусматривающие ввод командных строк и параметров пользователем. Кроме того, хотя бы самый примитивный лексический анализ вводимого текста применяют практически все современные текстовые редакторы и текстовые процессоры. Практически любой более-менее серьезный разработчик программного обеспечения рано или поздно сталкивается с необходимостью решать задачу лексического анализа (разбора)2.
Рассмотренный выше пример при реализации без использования математического аппарата лексического анализа привел к многочисленным ошибкам разработчика, в результате исправления которых изначально несложный текст программы превратился в путаницу «заплаток», разобраться в которых не смог в конце концов и сам разработчик.
С другой стороны, далеко не каждый разработчик, столкнувшись с этой задачей, понимает, что он имеет дело именно с лексическим анализом текста. Поэтому не всегда такие задачи решаются должным образом, в чем автор мог убедиться на собственном опыте.
С одной стороны, задачи лексического анализа имеют широкое распространение, а с другой — допускают четко формализованное решение на основе техники моделирования работы КА. Все это вместе предопределило возможность автоматизации решения данной задачи. И программы, ориентированные на ее решение, не замедлили появиться. Причем, поскольку математический аппарат КА известен уже длительное время, да и с задачами лексического анализа программисты столкнулись довольно давно, то и программам, их решающим, насчитывается не один десяток лет.
Для решения задач построения лексических анализаторов существуют различные программы. Наиболее известной среди них является программа LEX.
LEX — программа для генерации сканеров (лексических анализаторов). Входной язык содержит описания лексем в терминах регулярных выражений. Результатом работы LEX является программа на некотором языке программирования, которая читает входной файл (обычно это стандартный ввод) и выделяет из него последовательности символов (лексемы), соответствующие заданным регулярным выражениям.
История программы LEX тесно связана с историей операционных систем типа UNIX. Эта программа появилась в составе утилит ОС UNIX и в настоящее время входит в поставку практически каждой ОС этого типа. Однако сейчас существуют версии программы LEX практически для любой ОС, в том числе для широко распространенных MS DOS и MS Windows всех версий.
Поскольку LEX появилась в среде ОС UNIX, то первоначально языком программирования, на котором строились порождаемые ею лексические анализаторы, был язык С. Но со временем появились версии LEX, порождающие сканеры и на основе других языков программирования (например известны версии для языка Pascal).
СОВЕТ
Для поиска нужной версии программы лексического анализа LEX автор советует заинтересованным лицам прежде всего обратиться во всемирную сеть Интернет. В настоящее время существует огромное множество версий этой и подобных ей программ автоматизации построения лексических анализаторов.
Принцип работы LEX достаточно прост: на вход ей подается текстовый файл, содержащий описания нужных лексем в терминах регулярных выражений, а на выходе получается файл с текстом исходной программы сканера на заданном языке программирования (обычно — на С). Текст исходной программы сканера может быть дополнен вызовами любых функций из любых библиотек, поддерживаемых данным языком и системой программирования. Таким образом, LEX позволяет значительно упростить разработку лексических анализаторов, практически сводя эту работу к описанию требуемых лексем в терминах регулярных выражений.
Более подробную информацию о работе с программой LEX можно получить в [3, 8, 20, 29, 46, 48].
Контрольные вопросы и задачи
Вопросы
Какие грамматики относятся к регулярным грамматикам? Назовите два класса регулярных грамматик. Как они соотносятся между собой?
В чем заключается отличие автоматных грамматик от других регулярных грамматик? Всякая ли регулярная грамматика является автоматной? Всякая ли регулярная грамматика может быть преобразована к автоматному виду?
Если язык, заданный регулярной грамматикой, содержит пустую цепочку, то может ли он быть задан автоматной грамматикой?
Можно ли граф переходов конечного автомата использовать для однозначного определения данного автомата (и если нет, то почему)?
Всегда ли недетерминированный КА может быть преобразован к детерминированному виду (если нет, то в каких случаях)?
Какое максимальное количество состояний может содержать детерминированный КА после преобразования из недетерминированного КА? Всегда ли это количество состояний можно сократить?
Являются ли регулярными множествами следующие множества:
О множество целых натуральных чисел;.
О множество вещественных чисел;
О множество всех слов русского языка;
О множество всех возможных строковых констант в языке Pascal;
。множество иррациональных чисел;
。множество всех возможных вещественных констант языка С?
На основании свойств регулярных выражений докажите следующие тождества для произвольных регулярных выражений а, р, у и 5:
(а + 0)(3 + у) = а§ + ау + р§ + |3у
§(а + 0)у = Зау + 30у
р + ₽а + ра* = ра'
0 + раа* + Рааа* = ра*
§ауО* + Sa'y + Зу = §а*у
(О* + аа* + ааа*)* = а*.
Используя свойства регулярных множеств, проверьте, являются ли истинными следующие тождества для произвольных регулярных выражений аир：
(а + Р)* = (а ₽•)*
(ар)* = ар*
(а + 入)* = a,
а^ + ра* = ар*а
а*а" = а*.
Почему возможны две формы записи уравнений с регулярными коэффициентами? Как они соотносятся с двумя классами регулярных грамматик?
Можно ли для языка, заданного леволинейной грамматикой, построить праволинейную грамматику, задающую эквивалентный язык?
Всякая ли регулярная грамматика является однозначной? Если нет, то приведите пример неоднозначной регулярной грамматики.
Можно ли для двух леволинейных грамматик доказать, что они задают один и тот же язык? Можно ли выполнить то же самое доказательство для леволинейной и праволинейной грамматик?
Задачи
Определите, какие из перечисленных ниже грамматик являются регулярными, леволинейными, праволинейными, автоматными:
61({".",+,-.0.1}.{<число>,<часть>,<цифра>,<осн.>},Р1,<число>)
Р1：
<ЧИСЛО> -> +<ОСН.> I -<ОСН.> I <осн.>
<осн.> -> <часть>.<часть> | <часть>. | <часть>
<часть> -> <цифра> | <часть><цифра>
<цифра> -» О I 1
G2({".",+,-,0,1},{<число>.<часть>,<осн.>}.Р2.<число>)
Р2:
<ЧИСЛО> -» +<ОСН.> I -<ОСН.> I <осн.>
<осн.> -> <часть>. I <часть> | <осн.>0 | <осн.>1
<часть> -> О I 1 I <часть>0 | <часть>1
G3({".",+,-.0.1}.{<число>,<часть>,<осн.>},РЗ,<число>)
РЗ：
<ЧИСЛО> -> +<ОСН.> I -<ОСН.> I <осн.>
<осн.> -> 0 I 1 I 0.<часть> | 1.<часть> | 0<осн.> | 1<осн.>
<часть> -> 0 I 1 I 0<часть> | 1<часть>
G4({".".+.-.0,1},{<знак>.<число>.<часть>,<осн.>},Р4.<число>)
Р4:
<число> -> <знак>0 | <знак>1 | <часть>. | <число>0 | <число>1
<часть> -> <знак>0 | <знак>1 | <часть>0 | <часть>1
<знак> ->Х| + |-
G5({".",+,-.0.1},{<знак>,<число>.<часть>.<осн.>},Р5,<число>)
Р5:
<число> -> <часть>. | <осн.>0 | <осн.>1 | <часть>0 | <часть>1
<осн.> -> <насть>. I <осн.>0 | <осн.>1
<часть> -» 0 I 1 I <знак>0 | <знак>1 | <часть>0 | <часть>1
<знак> -> + I -
Докажите (любым способом), что грамматики G3, G4 и G5 из задачи № 1 задают один и тот же язык.
Преобразуйте к автоматному виду грамматики G3 и G4 из задачи № 1.
Постройте КА на основании грамматик G4 или G5 из задачи № 1. Преобразуйте построенный автомат к детерминированному виду.
Задан КА: M({H.I.S.E,F.G}.{b,d}. 5,H.{S}). 5(H,b) = {I.S}, 8(H,d) = {E}. 5(1.b)= {I.S}. 5(1.d) = {I,S}. 5(E.b) = {E.F}, 5(E,d) = {E.F}, S(F,b)=任}, d(F.d)= {E}. 8(G.b) = {F.S}. d(G,d) = {S}; минимизируйте его и постройте эквивалентный ДКА.
Задан КА: M({S,R,Z},{a,b},b,S.{Z}), 5(S,a) = {S.R}. 5(R,b) = {R}. SCR.a) = {Z}. Преобразуйте его к детерминированному виду и минимизируйте полученный КА.
Постройте и решите систему уравнений с регулярными коэффициентами для грамматики G4 из задачи № 1. Какой язык задает эта грамматика?
Докажите, что уравнение с регулярными коэффициентами X = аХ + р имеет решение X = а*(Р + у), где у обозначает произвольное множество, в том случае, когда множество, обозначенное выражением а, содержит пустую цепочку. (Указание: поскольку множество, обозначенное выражением а, содержит пустую цепочку, то выражение а можно представить в виде а = В + 入,при этом а' = 8'.)
Решите систему уравнений с регулярными коэффициентами над алфавитом V = {0,l}:
X] = 0Х2 + IX] + 大
Х2 = 0Х3 + lx?
Х3 = OXt + 1Х3
Постройте регулярную грамматику, которая бы описывала язык строк, целочисленных констант и строковых констант языка Pascal. Постройте и решите систему уравнений с регулярными коэффициентами на основе этой грамматики.
С помощью леммы о разрастании для регулярных языков докажите, что язык L = {an,bn I п > 2} не является регулярным, а язык L2 = {anbm | n > 1, m > 2} является регулярным.
В языке C++ возможны два типа комментариев: обычный комментарий, ограниченный символами /* и */, и строчный комментарий, начинающийся с символов // и заканчивающийся концом строки. Постройте сканер, который бы находил и исключал из входного текста все комментарии языка C++.
Постройте сканер, который выделял бы из текста входной программы на языке С все содержащиеся в ней строковые константы и записывал их в отдельный файл. Строковые константы в языке С состоят из строк, одиночных символов и кодов символов. Длинные строковые константы могут продолжаться на нескольких строках исходной программы подряд. Строки ограничены символами ""(двойные кавычки), одиночные символы — символами '' (одинарные кавычки), а коды символов начинаются со знака \ (обратная косая черта) и содержат цифры1.
Следует заметить, что эта задача отнюдь не так проста, как может показаться. Программа должна уметь не только находить в исходном тексте строки и объединять их между собой, но и правильно игнорировать комментарии (которых в С два типа). Поэтому лучше сначала корректно описать грамматику, а потом на ее основе построить автомат.
Глава 4 Синтаксические анализаторы
Основные принципы работы синтаксических анализаторов
Назначение синтаксических анализаторов
Синтаксический анализатор (синтаксический разбор) — это часть компилятора, которая отвечает за выявление и проверку синтаксических конструкций входного языка. В задачу синтаксического анализа входит:
поиск и выделение синтаксических конструкции в тексте исходной программы;
установка типа и проверка правильности каждой синтаксической конструкции;
представление синтаксических конструкций в виде, удобном для дальнейшей генерации текста результирующей программы.
Синтаксический анализатор — это основная часть компилятора на этапе анализа. Без выполнения синтаксического разбора работа компилятора бессмысленна, в то время как лексический разбор, в принципе, является необязательной фазой. Все задачи по проверке синтаксиса входного языка могут быть решены на этапе синтаксического разбора. Лексический анализатор только позволяет избавить сложный по структуре синтаксический анализатор от решения примитивных задач по выявлению и запоминанию лексем исходной программы.
Выходом лексического анализатора является таблица лексем. Эта таблица образует вход синтаксического анализатора, который исследует только один компонент каждой лексемы — ее тип. Остальная информация о лексемах используется на более поздних фазах компиляции при семантическом анализе, подготовке к генерации и генерации кода результирующей программы.
Синтаксический анализатор воспринимает выход лексического анализатора и разбирает его в соответствии с грамматикой входного языка. Однако в грамматике входного языка программирования обычно не уточняется, какие конструкции следует считать лексемами. Примерами конструкций, которые обычно распозна-
ются во время лексического анализа, служат ключевые слова, константы и идентификаторы. Но эти же конструкции могут распознаваться и синтаксическим анализатором. На практике не существует жесткого правила, определяющего, какие конструкции должны распознаваться на лексическом уровне, а какие надо оставлять синтаксическому анализатору. Обычно это определяет разработчик компилятора исходя из технологических аспектов программирования, а также синтаксиса и семантики входного языка. Принципы взаимодействия лексического и синтаксического анализаторов были рассмотрены ранее в главе 3 «Лексические анализаторы».
В основе синтаксического анализатора лежит распознаватель текста исходной программы, построенный на основе грамматики входного языка. Как правило, синтаксические конструкции языков программирования могут быть описаны с помощью КС-грамматик, реже встречаются языки, которые могут быть описаны с помощью регулярных грамматик.
ПРИМЕЧАНИЕ ；
Чаще всего регулярные цзамматики применимы к языкам ассемблера, а синтаксис языков высокого уровня основан на грамматике КС-языков.
Главную роль в том, как функционирует синтаксический анализатор и какой алгоритм лежит в его основе, играют принципы построения распознавателей для КС-языков. Без применения этих принципов невозможно выполнить эффективный синтаксический разбор предложений входного языка.
Распознавателями для КС-языков являются автоматы с магазинной памятью — МП-автоматы — односторонние недетерминированные распознаватели с линейно ограниченной магазинной памятью (классификация распознавателей приведена в соответствующем разделе главы 1 «Формальные языки и грамматики»). Поэтому важно рассмотреть, как функционирует МП-автомат и как для КС-языков решается задача разбора — построение распознавателя языка на основе заданной грамматики. Далее в этой главе рассмотрены технические аспекты, связанные с реализацией синтаксических анализаторов.
Автоматы с магазинной памятью
Определение МП-автомата
Контекстно-свободными (КС) называются языки, определяемые грамматиками типа G(VT,VN,P,S), в которых правила Р имеют вид: А -> Р，где Ае VN и PeV*, V = VTuVN. Распознавателями КС-языков служат автоматы с магазинной памятью (МП-автоматы).
В общем виде МП-автомат можно определить следующим образом: R(QV,Z,3,qo,z(),F), где
Q — множество состояний автомата;
V — алфавит входных символов автомата;
Z — специальный конечный алфавит магазинных символов автомата, VcZ;
8 — функция переходов автомата, которая отображает множество Qx(Vu{X})xZ на конечное множество подмножеств P(QxZ*);
q0€Q — начальное состояние автомата;
zoeZ — начальный символ магазина;一
FcQ — множество коневых состояний.
МП-автомат в отличие от обычного КА имеет стек (магазин), в который можно помещать специальные «магазинные» символы (обычно это терминальные и нетерминальные символы грамматики языка). Переход из одного состояния в другое зависит не только от входного символа, но и от символа на верхушке стека. Таким образом, конфигурация автомата определяется тремя параметрами: состоянием автомата, текущим символом входной цепочки (положением указателя в цепочке) и содержимым стека.
МП-автомат условно можно представить в виде схемы, показанной на рис. 4.1.
Конфигурация МП-автомата описывается в виде тройки (q,a,co)wQxV*xZ*, которая определяет текущее состояние автомата q, цепочку еще не прочитанных символов а на входе автомата и содержимое магазина (стека) а>. Вместо а в конфигурации можно указать пару (0,п), где |3wV* — вся цепочка входных символов, a neNu{0}, п > 0 — положение считывающего указателя в цепочке.
Тогда один такт работы автомата можно описать в виде (q,aa,zco) + (q',a,y(o), если (q',y)wb(q,a,z), где: q,q'wQ aeVu{X}, aeV*, zcZu{入}, y,coeZ*. При выполнении такта (перехода) из стека удаляется верхний символ, соответствующий условию перехода, и добавляется цепочка, соответствующая правилу перехода. Первый символ цепочки становится верхушкой стека. Допускаются переходы, при которых входной символ игнорируется (и, тем самым, он будет входным символом при следующем переходе). Эти переходы (такты) называются Х-переходами (Х-так- тами). Аналогично, автомат не обязательно должен извлекать символ из стека — когда z =九，этого не происходит.
Начальная конфигурация МП-автомата, очевидно, определяется как (q0fa,z0), a eV*. Множество конечных конфигураций автомата — (q,Xco), qeF, coeZ*.
МП-автомат допускает (принимает) цепочку символов, если, получив эту цепочку на вход, он может перейти в одну из конечных конфигураций — когда при окончании цепочки автомат находится в одном из конечных состояний, а стек содержит некоторую определенную цепочку. Иначе цепочка символов не принимается.
Язык, определяемый МП-автоматом, — это множество всех цепочек символов, которые допускает данный автомат. Язык, определяемый МП-автоматом R, обозначается как L(R). Два МП-автомата называются эквивалентными, если они определяют один и тот же язык: L(RJ = L(R2).
МП-автомат допускает цепочку символов с опустошением магазина, если при окончании разбора цепочки автомат находится в одном из конечных состояний, а стек пуст — конфигурация (q,入,入),qeF. Если язык задан МП-автоматом R, который допускает цепочки с опустошением стека, это обозначается так: LX(R). Доказано, что для любого МП-автомата всегда можно построить эквивалентный ему МП-автомат, допускающий цепочки заданного языка с опустошением стека [4, т. 1]. То есть V МП-автомата R: 3 МП-автомат R', такой, что L(R) = LX(R').
Расширенные МП-автоматы
Кроме обычного МП-автомата существует также понятие расширенного МП-автомата.
Расширенный МП-автомат может заменять цепочку символов конечной длины в верхней части стека на другую цепочку символов конечной длины, в отличие от обычного МП-автомата. В отличие от обычного МП-автомата, который на каждом такте работы может изымать из стека только один символ, расширенный МП-автомат может изымать за один такт цепочку символов, находящуюся на вершине стека. Функция переходов 5 для расширенного МП-автомата отображает множество Qx(Vu{X})xZ* на конечное множество подмножеств P(QxZ*).
Доказано, что для любого расширенного МП-автомата всегда можно построить эквивалентный ему обычный МП-автомат (обратное утверждение очевидно, так как любой обычный МП-автомат является расширенным МП-автоматом) [4, т. 1]. Таким образом, классы МП-автоматов и расширенных МП-автоматов эквивалентны и задают один и тот же тип языков.
Доказано, что для произвольной КС-грамматики всегда можно построить МП- автомат, распознающий заданный этой грамматикой язык [4, т. 1, 15]. Поэтому можно говорить, что МП-автоматы распознают КС-языки. Существует также доказательство того, что для произвольного МП-автомата всегда можно построить КС- грамматику, которая задает язык, распознаваемый этим автоматом. Таким образом, КС-грамматики и МП-автоматы задают один и тот же тип языков — КС-языки. Поскольку класс расширенных МП-автоматов эквивалентен классу обычных МП-автоматов и задает тот же самый тип языков, то можно утверждать, что и расширенные МП-автоматы распознают языки из типа КС-языков. Следовательно, язык, который может распознавать расширенный МП-автомат, также может быть задан с помощью КС-грамматики.
Детерминированные МП-автоматы
МП-автомат называется детерминированным, если из каждой его конфигурации возможно не более одного перехода в следующую конфигурацию. В противном случае МП-автомат называется недетерминированным.
Формально для детерминированного МП-автомата (ДМП-автомата) RQVZB, qo，z(),F) функция переходов 5 VqeQ, VaeV, VzeZ может иметь один из следующих трех видов:
5(q,a,z) содержит один элемент: 5(q,a,z) = {(q',y)}, yeZ* и 5(q,X,z) = 0;
5(q,a,z) = 0 и 5(qA,z) содержит один элемент: 5(q,X,z) = {(q',y)}, yeZ*;
5(q,a,z) = 0 и 5(qA,z) = 0.
Класс ДМП-автоматов и соответствующих им языков значительно уже, чем весь класс МП-автоматов и КС-языков.
ВНИМАНИЕ
В отличие от КА, когда для любого недетерминированного КА можно построить эквивалентный ему детерминированный КА, не для каждого МП-автомата можно построить эквивалентный ему ДМП-автомат. Иными словами, в общем случае невозможно преобразовать недетерминированный МП-автомат в детерминированный.
Детерминированные МП-автоматы дпределяют очень важный класс среди всех КС-языков, называемый детерминированными КС-языками. Доказано, что все языки, принадлежащие к классу детерминированных КС-языков, могут быть построены с помощью однозначных КС-грамматик. Поскольку однозначность — это важное и обязательное требование в грамматике любого языка программирования, ДМП-автоматы представляют особый интерес для создания компиляторов.
ПРИМЕЧАНИЕ
Любой детерминированный КС-язык может быть задан однозначной КС-грамматикой, но обратное неверно: не всякий язык, заданный однозначной КС-грамматикой, является детерминированным. Например, однозначная грамматика G({afb}, {S,A,B}, {S->A|B, A->aAb|ab, B->aBbb|abb}f S) задает КС-язык, который не является детерминированным.
Все без исключения синтаксические конструкции языков программирования задаются с помощью однозначных КС-грамматик. Чаще всего синтаксические структуры этих языков относятся к классу детерминированных КС-языков и могут распознаваться с помощью ДМП-автоматов. Поэтому большинство распознавателей, которые будут рассмотрены далее, относятся к классу детерминированных КС-языков.
Построение синтаксических анализаторов
Проблемы построения синтаксических анализаторов
Синтаксический анализатор должен распознавать весь текст исходной программы. Поэтому, в отличие от лексического анализатора, ему нет необходимости искать
границы распознаваемой строки символов. Он должен воспринимать всю информацию, поступающую ему на вход, и либо подтвердить ее принадлежность входному языку, либо сообщить об ошибке в исходной программе.
Но, как и в случае лексического анализа, задача синтаксического анализа не ограничивается только проверкой принадлежности цепочки заданному языку. Необходимо оформить найденные синтаксические конструкции для дальнейшей генерации текста результирующей программы. Синтаксический анализатор должен иметь некий выходной язык, с помощью которого он передает следующим фазам компиляции информацию о найденных и разобранных синтаксических структурах. В таком случае он уже является не разновидностью МП-автомата, а преобразователем с магазинной памятью — МП-преобразователем [3, 4, т. 1, 15].
ПРИМЕЧАНИЕ
Во всех рассматриваемых далее примерах результатом работы МП-автомата является не только ответ на вопрос о принадлежности входной цепочки заданному языку («да» или «нет»), но и последовательность номеров правил грамматики, использованных для построения входной цепочки. Затем на основе этих правил строятся цепочка вывода и дерево вывода. Поэтому, строго говоря, все рассмотренные примеры МП-автоматов являются не только МП-автоматами, но и МП-преобразователями.
Вопросы, связанные с представлением информации, являющейся результатом работы синтаксического анализатора, и с порождением на основе этой информации текста результирующей программы, рассмотрены в следующей главе, поэтому здесь на них останавливаться не будем.
Однако проблемы, связанные с созданием синтаксического анализатора, не ограничиваются только двумя перечисленными, как это было для лексического анализа. Дело в том, что процесс построения синтаксического анализатора гораздо сложнее аналогичного процесса для лексического анализатора. Так происходит, поскольку КС-грамматики и МП-автоматы, лежащие в основе синтаксического анализа исходной программы, сложнее, чем регулярные грамматики и КА, лежащие в основе лексического анализа.
Алгоритм создания МП-автомата на основе произвольной КС-грамматики прост [4, т. 1, 15], но если напрямую воспользоваться этим алгоритмом, то может оказаться, что работу полученного МП-автомата невозможно будет промоделировать на компьютере. Следовательно, такой автомат практического применения в компиляторе иметь не может. Но даже если реализовать распознаватель на основе МП-автомата удастся, может оказаться, что время его работы непомерно велико и в худшем случае экспоненциально зависит от длины входной цепочки.
С этими проблемами столкнулись в свое время разработчики первых компиляторов с языков высокого уровня. Для их решения были предприняты определенные исследования в теории формальных языков и, в частности, в области КС-языков.
Во-первых, очевидно, что поскольку любой язык программирования должен быть задан однозначной КС-грамматикой, а распознавателями для КС-языков, заданных однозначными КС-грамматиками, являются ДМП-автоматы, то нужно
стремиться построить синтаксический анализатор на основе ДМП-автомата. Моделировать работу ДМП-автомата существенно проще, чем работу произвольного МП-автомата.
Во-вторых, было установлено, что существуют несложные преобразования правил КС-грамматик, выполнив которые, можно привести грамматику к такому виду, когда построение и моделирование работы МП-автомата, распознающего язык, заданный грамматикой, существенно упрощаются. Были найдены и описаны специальные формы правил КС-грамматик, называемые «нормальными формами», для которых построены соответствующие МП-автоматы [4, т. 1, 15]. Преобразовав произвольную КС-грамматику к одной из известных нормальных форм, можно сразу же построить соответствующий МП-автомат (нормальные формы КС-грамматик в данном учебнике не рассматриваются).
Наконец, было найдено множество различных классов КС-грамматик, для которых возможно построить ДМП-автомат, имеющий линейную зависимость времени разбора входной цепочки от ее длины. Такие распознаватели для КС-языков называются линейными распознавателями. Часть таких классов КС-грамматик будет рассматриваться далее в этой главе.
В принципе, было бы достаточно знать хотя бы один такой класс, если бы для КС-грамматик были разрешимы проблема преобразования и проблема эквивалентности. Но поскольку в общем случае это не так, то одним классом КС-грамматик, для которого существуют линейные распознаватели, ограничиться не удается. По этой причине для всех классов КС-грамматик существует принципиально важное ограничение: в общем случае невозможно преобразовать произвольную КС-грамматику к виду, требуемому данным классом КС-грамматик, либо же доказать, что такого преобразования не существует. То, что проблема неразрешима в общем случае, не говорит о том, что она не решается в каждом конкретном частном случае, и зачастую удается найти такие преобразования. И чем шире набор классов КС-грамматик с линейными распознавателями, тем проще их искать.
Среди универсальных распознавателей лучшими по эффективности являются табличные, функционирование которых построено на иных принципах, нежели моделирование работы МП-автомата [4, т. 1, 15]. Табличные распознаватели обладают полиномиальными характеристиками требуемых вычислительных ресурсов в зависимости от длины входной цепочки: для КС-языков, заданных однозначной грамматикой, удается добиться квадратичной зависимости, для всех прочих КС-языков — кубической зависимости. Но в данном учебнике табличные распознаватели не рассматриваются, поскольку они достаточно сложны, требуют значительного объема памяти (объем необходимой памяти квадратично зависит от длины входной цепочки), но при этом не позволяют добиться практически значимых результатов (квадратичная зависимость требуемых вычислительных ресурсов от длины входной цепочки неприемлема для компилятора).
Варианты синтаксических анализаторов
Построение синтаксического анализатора — это более творческий процесс, чем построение лексического анализатора. Этот процесс не всегда может быть полностью формализован.
Имея грамматику входного языка, разработчик синтаксического анализатора должен в первую очередь выполнить ряд формальных преобразований над этой грамматикой, облегчающих построение распознавателя. После этого он должен проверить, подпадает ли полученная грамматика под один из известных классов КС-языков, для которых существуют линейные распознаватели. Если такой класс найден, можно строить распознаватель (если найдено несколько классов — выбрать тот, для которого построение распознавателя проще, либо построенный распознаватель обладает лучшими характеристиками). Если же такой класс КС-языков найти не удалось, то разработчик должен попытаться выполнить над грамматикой некоторые преобразования, чтобы привести ее к одному из известных классов. Вот эти преобразования не могут быть описаны формально, и в каждом конкретном случае разработчик должен попытаться найти их сам (иногда преобразования имеет смысл искать даже в том случае, когда грамматика подпадает под один из известных классов КС-языков, с целью найти другой класс, для которого можно построить лучший по характеристикам распознаватель).
Только в том случае, когда в результате всех этих действий не удалось найти соответствующий класс КС-языков, разработчик вынужден строить универсальный распознаватель. Характеристики такого распознавателя будут существенно хуже, чем у линейного распознавателя, — в лучшем случае удается достичь квадратичной зависимости времени работы распознавателя от длины входной цепочки. Такие случаи бывают редко, поэтому все современные компиляторы построены на основе линейных распознавателей (иначе время их работы было бы недопустимо велико).
Для каждого класса КС-языков существует свой класс распознавателей, но все они функционируют на основе общих принципов, на которых основано моделирование работы МП-автоматов. Все распознаватели для КС-языков можно разделить на две большие группы: нисходящие и восходящие.
Нисходящие распознаватели просматривают входную цепочку символов слева направо и порождают левосторонний вывод. При этом получается, что дерево вывода строится таким распознавателем от корня к листьям (сверху вниз), откуда и происходит название распознавателя.
Восходящие распознаватели также просматривают входную цепочку символов слева направо, но порождают при этом правосторонний вывод. Дерево вывода строится восходящим распознавателем от листьев к корню (снизу вверх), откуда и происходит название распознавателя.
Для моделирования работы этих двух групп распознавателей используются два алгоритма: алгоритм с подбором альтернатив — для нисходящих распознавателей, алгоритм «сдвиг-свертка» — для восходящих распознавателей. В общем случае эти два алгоритма универсальны. Они строятся на основе любой КС-грамматики после некоторых формальных преобразований и поэтому могут быть использованы для разбора цепочки любого КС-языка. В этом случае время разбора входной цепочки имеет экспоненциальную зависимость от длины цепочки. Однако для линейных распознавателей эти алгоритмы могут быть модифицированы так, чтобы время разбора имело линейную зависимость от длины входной
цепочки. Указанные модификации не влияют на принципы, на основе которых построена работа алгоритмов, но позволяют оптимизировать их выполнение при условии, что грамматика входного языка принадлежит к определенному классу КС-грамматик. Для каждого такого класса предусматривается своя модификация. Далее будут рассмотрены формальные преобразования, применимые к КС-грамматикам, которые позволяют строить распознаватели на основе произвольной КС-грамматики. Затем изучаются основы двух названных алгоритмов — алгоритма с подбором альтернатив и алгоритма «сдвиг-свертка». Вначале они даны для распознавателей с возвратами — хотя такие распознаватели КС-языков имеют ограниченное применение, но их рассмотрение позволяет понять принципы, лежащие в основе этих алгоритмов. А потом следуют разделы, посвященные некоторым наиболее известным классам КС-грамматик. Для каждого класса дается его определение, основные ограничения, а также принципы и алгоритмы, лежащие в основе распознавателя для этого класса КС-языков.
Далеко не все известные распознаватели с линейными характеристиками рассматриваются в данном пособии. Более полный набор распознавателей, а также описание связанных с ними классов КС-грамматик и КС-языков можно найти в [4, т. 1, 17, 52].
Выбор распознавателя для синтаксического анализа
Часто одна и та же КС-грамматика может быть отнесена не к одному, а сразу к нескольким классам КС-грамматик, допускающих построение линейных распознавателей. В этом случае необходимо решить, какой из нескольких возможных распознавателей выбрать для практической реализации.
Ответить на этот вопрос не всегда легко, поскольку могут быть построены два принципиально разных распознавателя, алгоритмы работы которых несопоставимы. В первую очередь, речь идет именно о восходящих и нисходящих распознавателях: в основе первых лежит алгоритм подбора альтернатив, в основе вторых —алгоритм «сдвиг-свертка».
На вопрос о том, какой распознаватель — нисходящий или восходящий — выбрать для построения синтаксического анализатора, нет однозначного ответа. Эту проблему необходимо решать, опираясь на некую дополнительную информацию о том, как будут использованы или каким образом будут обработаны результаты работы распознавателя.
СОВЕТ
Следует помнить, что синтаксический анализатор — это один из этапов компиляции. И с этой точки зрения результаты работы распознавателя служат исходными данными для следующих этапов компиляции. Поэтому выбор того или иного распознавателя во многом зависит от реализации компилятора, от того, какие принципы положены в его основу.
Восходящий синтаксический анализ, как правило, привлекательнее нисходящего, так как для языка программирования часто легче построить правосторонний (восходящий) распознаватель. Класс языков, заданных восходящими распозна-
вателями, шире, чем класс языков, заданных нисходящими распознавателями (хотя следует сказать, что не все здесь столь однозначно).
С другой стороны, как будет показано далее, левосторонний (нисходящий) синтаксический анализ предпочтителен с точки зрения процесса трансляции, поскольку на его основе легче организовать процесс порождения цепочек результирующего языка. Ведь в задачу компилятора входит не только распознать (проанализировать) входную программу на входном языке, но и построить (синтезировать) результирующую программу. Более подробную информацию об этом можно получить в главе 5 «Генерация и оптимизация кода» или в работе [4, т, 1, 2]. Левосторонний анализ, основанный на нисходящем распознавателе, оказывается предпочтительным также при учете вопросов, связанных с обнаружением и локализацией ошибок в тексте исходной программы [4, т. 1, 2, 54].
Желание использовать более простой класс грамматик для построения распознавателя может потребовать каких-то манипуляций с заданной грамматикой, необходимых для ее преобразования к требуемому классу. При этом нередко грамматика становится неестественно访 и малопонятной, что в дальнейшем затрудняет ее использование в схеме синтаксически управляемого перевода и трансляции на этапе генерации результирующего кода (см. главу 5 «Генерация и оптимизация кода》). Поэтому бывает удобным использовать исходную грамматику такой, как она есть, не стремясь преобразовать ее к более простому классу.
В целом, следует отметить, что с учетом всего сказанного выше интерес представляют как левосторонний, так и правосторонний анализ. Конкретный выбор зависит от реализации конкретного компилятора, а также от сложности грамматики входного языка программирования.
Преобразование КС-грамматик. Приведенные грамматики
Преобразование грамматик. Цель преобразования
Как было сказано выше, для КС-грамматик невозможно в общем случае проверить их однозначность и эквивалентность. Но очень часто правила КС-грамматик можно и нужно преобразовать к некоторому заданному виду таким образом, чтобы получить новую грамматику, эквивалентную исходной. Заранее определенный вид правил грамматики облегчает создание распознавателей.
Можно выделить две основных цели преобразований КС-грамматик: упрощение правил грамматики и облегчение создания распознавателя языка. Не всегда эти две цели можно совместить. В случае с языками программирования, когда итогом работы с грамматикой является создание компилятора, именно вторая цель преобразования является основной. Поэтому упрощениями правил пренебрегают, если при этом удается упростить построение распознавателя языка [9, 13, 22].
Все преобразования условно можно разбить на две группы:
первая группа — это преобразования, связанные с исключением из грамматики избыточных правил и символов, без которых она может существовать (именно эти преобразования позволяют выполнить упрощения правил);
вторая группа — это преобразования, в результате которых изменяется вид и состав правил грамматики, при этом грамматика может дополняться новыми правилами, а ее словарь нетерминальных символов — новыми символами (то есть преобразования второй группы не связаны с упрощениями).
Следует еще раз подчеркнуть, что всегда в результате преобразований мы получаем новую КС-грамматику, эквивалентную исходной, то есть определяющую тот же самый язык.
Тогда формально преобразование можно определить следующим образом:
G(VT,VN,P,S) f G〈VT',VNrS): L(G) = L(G')
Приведенные грамматики
Приведенные грамматики — это КС-грамматики, которые не содержат недостижимых и бесплодных символов, циклов и 九-правкл (правил с пустыми цепочками).
Для того чтобы преобразовать произвольную КС-грамматику к приведенному виду, необходимо выполнить следующие действия:
удалить все бесплодные символы;
удалить все недостижимые символы;
口 удалить Х-правила;
удалить цепные правила.
Следует подчеркнуть, что шаги преобразования должны выполняться именно в указанном порядке.
Удаление бесплодных символов
В грамматике G(VT,VN,P,S) символ AeVN называется бесплодным, если для него выполняется: {а | Ап*а, aeVT*} = 0. То есть нетерминальный символ является бесплодным тогда, когда из него нельзя вывести ни одной цепочки терминальных символов.
В простейшем случае символ является бесплодным, если во всех правилах, где этот символ стоит в левой части, он также встречается и в правой части. Более сложные варианты предполагают зависимости между цепочками бесплодных символов, когда они в любой последовательности вывода порождают друг друга. Алгоритм удаления бесплодных символов работает со специальным множеством нетерминальных символов YP Первоначально в это множество попадают только те символы, из которых непосредственно можно вывести терминальные цепочки, затем оно пополняется на основе правил грамматики G.
Алгоритм удаления бесплодных символов по шагам
Yo = 0, i := 1;
Y「{A I (A f а)еР,
если Y] / У,，!, то i := i + 1 и перейти к шагу 2, иначе перейти к шагу 4;
VN' = Y" VT' = VT, в Р' входят те правила из Р, которые содержат только символы из множества (VToY,), S' = S.
Удаление недостижимых символов
Символ xw(VTuVN) называется недостижимым, если он не встречается ни в одной сентенциальной форме грамматики G(VT,VN,P,S). То есть символ недостижимый, если он не участвует ни в одной цепочке вывода из целевого символа грамматики. Очевидно, что такой символ в грамматике не нужен.
Алгоритм удаления недостижимых символов строит множество достижимых символов грамматики G(VT,VN,P,S) — V). Первоначально в это множество входит только целевой символ S, затем оно пополняется на основе правил грамматики. Все символы, которые не войдут в данное множество, являются недостижимыми и могут быть исключены в новой грамматике G' из словаря и из правил.
Алгоритм удаления недостижимых символов по шагам
L Vo = {S}, i := 1;
V, = {х I xe(VTuVN) к (А -» axp)sP, AeV”】, a,Be(VTuVN)*}DVi；
если V,工 V]T, то i := i + 1 и перейти к шагу 2, иначе перейти к шагу 4;
VN' = VNcV“ VT' = VTnVp в Р' входят те правила из Р, которые содержат только символы из множества V„ S' = S.
Пример удаления недостижимых и бесплодных символов
Рассмотрим работу алгоритмов удаления недостижимых и бесплодных символов на примере грамматики:
2({a,b,c),{A.B.C,D,E.F.G,S).P,S)
S аАВ I Е
А —> dA I ЬВ
m т ась I ь
：А I ЬА I сС I аЕ
三 т сЕ I 託 I Eb I ED I FG
二 т а I с I Fb
-> ВС I ЕС I АС 三-> Gd I Gb
ВНИМАНИЕ
Для правильного выполнения преобразований необходимо сначала удалить бесплодные символы, а потом — недостижимые символы, но не наоборот.
Удалим бесплодные символы:
Y0 = 0, i:=l (шаг 1);
Y1 = {B.D}, Yl^YO： г=2(шаги2иЗ);
Y2 = {B,D,A}, Y2 wYl： i.=3 (шаги 2 и 3);
Y3 = {B,D,A,S,C}, Y3 ^Y2: i :=4 (шаги 2 и 3);
Y4 = {B,D,A,S,C,F}, Y4 w Y3： i :=5 (шагк 2 к 3);
Y5 = {B,D,A,S,C.F}, Y5 = Y4 (шаги 2 и 3);
строим множества VN' = {A.B.C.D.F.S}, VT' = (a.b.c} и P' (шаг 4).
Получили грамматику:
G'({a.b.c},{A.B,C.D,F,S}.P',S) Р'.
S аАВ
А т аА I ЬВ
В -> АСЬ I b
С f А I ЬА I сС
D -> а I с I Fb
F ВС I АС
Удалим недостижимые символы:
VO = {S}. г=1 (шаг 1);
VI = {S.A,B}( VI ^VO: ъ==2(шаги2иЗ);
V2 = {S.A.B.C}, V2 н VI：】：=2 (шаги 2 и 3);
V3 = {S,A,B,C}, V3 = V2 (шаги 2 и 3);
строим множества VN" = {A.B.C.S}, VT" = {a.b.c} и Р' (шаг 4).
В итоге получили грамматику:
G"({a.b,c}.{A,B.C,S},Pn.S)
Р":
S -> аАВ
А — dA I ЬВ
В т АСЬ I b
С - А I ЬА I сС
Алгоритмы удаления бесплодных и недостижимых символов относятся к первой группе преобразований КС-грамматик. Они всегда ведут к упрощению грамматики, сокращению количества символов алфавита и правил грамматики.
Устранение Х-правил
^-правилами называются все правила грамматики вида А -> 九，где A&VN.
КС-фамматика G(VT,VN,P,S) называется грамматикой без Х,-правил, если в ней не существует правил (А-> X,)gP, А^ S и существует только одно правило (S —九)еР, в том случае, когда 九&L(G), и при этом S не встречается в правой части ни одного правила.
Для того чтобы упростить построение распознавателей языка L(G), грамматику G часто целесообразно преобразовать к виду без Х,-правил. Существует алгоритм преобразования произвольной КС-грамматики к виду без 九-правил. Он работает с некоторым множеством нетерминальных символов W).
Алгоритм устранения Х-правил по шагам
W° = {A:(Af 九)&Р}, i:=l;
W, = W-u{A: (А т а)еР, aeW,.；};
если W］工 W.i，то i := i + 1 и перейти к шагу 2, иначе перейти к шагу 4;
VN' = VN, VT = VT, в Р' входят все правила из Р, кроме правил вида А —> 九；
если (А —> а)еР и в цепочку а входят символы из множества Wlf тогда на основе цепочки а строится множество цепочек {а'} путем исключения из а всех возможных комбинаций символов Wp все правила вида А —> а' добавляются в Р' (при этом надо учитывать дубликаты правил и бессмысленные правила);'
если SgW„ то значит 入&L(G), и тогда в VN' добавляется новый символ S', который становится целевым символом грамматики G', а в Р' добавляются два новых правила: S' т RS; иначе S' = S.
Данный алгоритм часто ведет к увеличению количества правил грамматики, но позволяет упростить построение распознавателя для заданного языка.
Пример устранения Х-правил
Рассмотрим грамматику:
G({a.b,c}.{A.B.C,S}.P.S)
Р:
S т АаВ I аВ I сС
А т АВ I I b I В
В Ва I X
С т АВ I с
Удалим Х,-правила:
W0 = {В}, 1 .=1 (шаг 1);
W1 = {В,A}, W1 ^WO, 1.=2(шаги2иЗ);
W2 = {В,А.С), W2 ^ W1, г=3 (шаги 2 и 3);
W3 = {В,А,С}, W3 = W2 (шаги 2 и 3);
построим VN' = {A.B.C.S}, VT' = {а,Ь,с} и множество правил Р' (шаг 4):
Р':
S т АаВ I аВ 丨 сС
А т АВ I а I b I В
В —> Ва
С -> АВ I с
рассмотрим все правила из множества Р' (шаг 5):
О из правил S -> АаВ | аВ | сС исключим все комбинации W3 = {В.А,С} и получим новые правила S —> Аа | аВ | а | а | с( добавим их в Р', исключая дубликаты, получим: S —> АаВ | аВ | сС | Аа | аВ | а | с;
О из правил А -> АВ | а | b | В исключим все комбинации W3 = {В,А,С} и получим новые правила А -> А | В; в Р' их добавлять не надо, поскольку правило А В там уже есть, а правило А -> А бессмысленно;
О из правила В — Ва исключим все комбинации W3 = {В,А,С} и получим новое правило В — а, добавим его в Р', получим: В Ва | а;
О из правил С —> АВ | с исключим все комбинации W3 = {В,А.С} и получим новые правила С -» А | В, добавим их в Р', получим: С -» АВ | А | В | с.
S%W3, поэтому в грамматику G' не надо добавлять новый целевой символ S', S' = S (шаг 6).
Получим грамматику:
G'({a.b(c}.{A.B.C.S}.P,,S)
Р'
S -> АаВ | аВ | сС | Аа | а | с
А АВ | а | b | В
В -> Ва | а
С т АВ | А | В | с
Устранение цепных правил
Циклом (циклическим выводом) в грамматике G(VT,VN,P,S) называется вывод вида A n *А, AgVN. Очевидно, что такой вывод абсолютно бесполезен. В распознавателях КС-языков целесообразно избегать возможности появления циклов. Циклы возможны только в том случае, если в КС-грамматике присутствуют цепные правила вида А —> В, A,BgVN. Чтобы исключить возможность появления циклов в цепочках вывода, достаточно устранить цепные правила из правил грамматики.
Чтобы устранить цепные правила в КС-грамматике G(VT,VN,P,S ), для каждого нетерминального символа XeVN строится специальное множество цепных символов Nx, а затем на основании построенных множеств выполняются преобразования правил Р. Поэтому алгоритм устранения цепных правил надо выполнить для всех нетерминальных символов грамматики из множества VN.
Алгоритм устранения цепных правил по шагам
Шаг 1. Для всех символов X из VN повторять шаги 2-4, затем перейти к шагу 5.
Шаг 2. N% = {X}, i := 1.
Шаг 3. N^ - NRw{B: (A f В)еР, BeN%}.
Шаг 4. Если N号 н N^.lt то i := i + 1 и перейти к шагу 3, иначе Nx = N^ - {X} и продолжить цикл по шагу 1.
Шаг 5. VN' = VN, VT' = VT, в Р' входят все правила из Р, кроме правил вида А - В, S' = S.
Шаг 6. Для всех правил (А -> а)еР\ если BgNa, В w А, то в Р' добавляются правила вида В а.
Данный алгоритм, так же как и алгоритм устранения 九-правил, ведет к увеличению числа правил грамматики, но упрощает построение распознавателей.
Пример устранения цепных правил
Рассмотрим в качестве примера грамматику арифметических выражений над символами а и Ь, которая уже рассматривалась ранее в этом учебном пособии:
G({+,a.b},{S.T,E},P,S)：
Р:
S т S+T | S-Т | Т т т Т*Е I Т/Е I Е
Е т (S) | а | b
Устраним цепные правила:
NSO = {S}. 1:=1;
NS1 = {S.T}, NS1 工 NSO, 1:=2;
NS2 = {S,T,E}, NS2 н NSL 】=3;
NS3 = {S,T,E}. NS3=NS2, NS = {Т.Е);
NT0 =⑴，i:=l；
NT1 = {Т,Е}, NTl HNTO. j：=2;
NT2 = {Т,Е}, NT2 = NTL NT = {Е};
NEO = {Е}, i.=l;
NE1 = (Е}. NE1 = NEO. NE = 0；
получили: NS = {Т,Е}, NT = {Е}, NE = 0, S' = S, построим множества VN1 = {S.T, Е}, VT' = {+.-,/,*.а,Ь} и множество правил Р';
И. рассмотрим все правила из множества Р' — интерес представляют только правила для символов Т и Е, так как NS = {Т,Е} к NT = {Е}:
О для правил Т —> Т*Е | Т/Е имеем новые правила S т Т*Е | Т/Е, поскольку Tens；
О для правил Е (S) I a I b имеем новые правила S -> (S) | а | b и Т -> (S) | а I Ь, поскольку EeNS к E&NT.
Получим новую грамматику:
G'({+.-,/.*,a1b},{S1T,E}.P'.S)
Р':
$ т S+T I s-Т I Т*Е I Т/Е I (S) I a I b
ТТ*Е I Т/Е I (S) I a I b
Е (S) I a I b
Эта грамматика далее будет использована для построения распознавателей КС- языков.
Устранение левой рекурсии
Определение левой рекурсии
Символ AgVN в КС-грамматике G(VT,VN,P,S) называется рекурсивным, если для него существует цепочка вывода вида А п +аА0, где a,Pe(VTuVN)*.
Если а = X, и р ^ X,, то рекурсия называется левой, а грамматика G — леворекурсивной; если a ^ X, и р = X,, то рекурсия называется правой, а грамматика G — праворекурсивной. Если a = X, и Р = X,, то рекурсия представляет собой цикл. Алгоритм исключения циклов был рассмотрен выше, поэтому далее циклы рассматриваться не будут.
Любая КС-грамматика может быть как леворекурсивной, так и праворекурсивной, а также леворекурсивной и праворекурсивной одновременно.
КС-грамматика называется нелеворекурсивной, если она не является леворекурсивной. Аналогично, КС-грамматика является неправорекурсивной, если не является праворекурсивной.
Некоторые алгоритмы левостороннего разбора для КС-языков не работают с леворекурсивными грамматиками, поэтому возникает необходимость исключить левую рекурсию из выводов грамматики. Далее будет рассмотрен алгоритм, который позволяет преобразовать правила произвольной КС-грамматики таким образом, чтобы в выводах не встречалась левая рекурсия.
Следует отметить, что поскольку рекурсия лежит в основе построения языков на основе правил грамматики в форме Бэкуса—Наура, полностью исключить рекурсию из выводов грамматики невозможно. Можно избавиться только от одного вида рекурсии — левого или правого, то есть преобразовать исходную грамматику G к одному из видов: нелеворекурсивному (избавиться от левой рекурсии) или неправорекурсивному (избавиться от правой рекурсии). Для левосторонних распознавателей интерес представляет избавление от левой рекурсии — то есть преобразование грамматики к нелеворекурсивному виду.
Доказано, что любую КС-грамматику можно преобразовать к нелеворекурсивному или неправорекурсивному виду [4, т. 1].
Алгоритм устранения левой рекурсии
Условие', дана КС-грамматика G(VT,VN,P,S), необходимо построить эквивалентную ей нелеворекурсивную грамматику G'(VN',VT,P'S): L(G) = L(G').
Алгоритм преобразования работает со множеством правил исходной грамматики Р, множеством нетерминальных символов VN и двумя переменными счетчиками: i и j.
Шаг 7. Обозначим нетерминальные символы грамматики так: VN = {А^А?,…,AJ, i:= 1.
Шаг 2. Рассмотрим правила для символа А「Если эти правила не содержат левой рекурсии, то перенесем их во множество правил Р' без изменений, а символ А] добавим во множество нетерминальных символов VN'.
Иначе запишем правила для А】в виде A, f 入必 | A,a2 l-l A】am I Bi I B21…I Bp，где VI < j < p ни одна из цепочек 为 не начинается с символов Ак, таких, что k < i.
Вместо этого правила во множество Р' запишем два правила вида:
А, ^ ₽! | ₽21...I 饵丨 PtA； I р2А； |...| ₽РА,'
А「-> а! | а21...| ат | сцА" а2А,' |...| атА；
Символы А[ и А/ включаем во множество VN'.
Теперь все правила для А〔 начинаются либо с терминального символа, либо с нетерминального символа Ак, такого, что k > i.
Шаг 3. Если i = п, то грамматика G' построена, перейти к шагу 6, иначе i := i + 1, j := 1 и перейти к шагу 4.
Шаг 4, Для символа Aj во множестве правил Р' заменить все правила вида А, -» Aja, где ae(VTuVN)*, на правила вида А1 -> Ra | 132a |…| Pma, причем Aj —氏 | р21.*.| Вт — все правила для символа А「
Так как правая часть правил Aj -> В J р21...| рт уже начинается с терминального символа или нетерминального символа Ак, к > j, то и правая часть правил для символа А, будет удовлетворять этому условию.
Шаг 5. Если j = i - 1, то перейти к шагу 2, иначе j := j + 1 и перейти к шагу 4.
Шаг 6. Целевым символом грамматики G' становится символ Ак, соответствующий символу S исходной грамматики G.
Рассмотрим в качестве примера грамматику для арифметических выражений над символами а и Ь:
G({+,а,b}.{S,T,E}.P.S):
Р.
S т S+T I S-Т I Т
Т Т*Е I Т/Е I Е
Е т (S) I а I b
Эта грамматика является леворекурсивной. Построим эквивалентную ей нелеворекурсивную грамматику G1.
Шаг 7. Обозначим VN = {Al, А2, АЗ}. 1 ：= 1.
Тогда правила грамматики G будут иметь вид:
А1 т А1+А2 I А1-А2 | А2
А2 т А2*АЗ I А2/АЗ | АЗ
АЗ т (Al) j а I b
Шаг 2. Для А1 имеем правила А1 —> А1+А2 | А1-А2 | А2. Их можно записать в виде Al f Alai I Ala2 | pl, где al = +A2. a2 =・A2, pi 工 A2.
Запишем новые правила для множества Р':
А1 т А2 I А2АГ
АГ т +А2 I -А2 I +А2АГ | -А2АГ
Добавив эти правила в Р', а символы А1 и АГ во множество нетерминальных символов, получим: VN' = {А1,А1‘}.
Шаг 5. 1 = 1 < 3. Построение не закончено: i := i+l = 2, j := 1.
Шаг 4. Для символа А2 во множестве правил Р' нет правила вида А2 -> Ala, поэтому на этом шаге никаких действий не выполняем.
Шаг 5. j = 1 = 1-1, переходим опять к шагу 2.
Шаг 2 Для А2 имеем правила А2 -> А2*АЗ | А2/АЗ | АЗ. Их можно записать в виде А2 т A2al | A2a2 | pi, где al 工 *АЗ. a2 = /АЗ. pi 二 АЗ.
Запишем новые правила для множества Р':
А2 т АЗ I АЗА2'
А2‘ — *АЗ I /АЗ I *АЗА2' I /АЗА2，
Добавим эти правила в Р', а символы A2HA2' во множество нетерминальных символов, получим: VN' = {А1.АГ .А2.А2' }•
Шаг 5.1 = 2 < 3. Построение не закончено: ч := ч + 1 = 3, j .= 1.
Шаг 4. Для символа АЗ во множестве правил Р' нет правила вида АЗ -> Ala, поэтому на этом шаге никаких действий не выполняем.
Шаг 5. j = 1 < 1 - 1, j .= j + 1 = 2, переходим к шагу 4.
Шаг 4. Для символа АЗ во множестве правил Р' нет правила вида АЗ -> А2а, поэтому на этом шаге никаких действий не выполняем.
Шаг 5. J = 2 = 1 - 1, переходим опять к шагу 2.
Шаг 2, Для АЗ имеем правила АЗ -> (А1) | а | Ь. Эти правила не содержат левой рекурсии. Переносим их в Р‘, а символ АЗ добавляем в VN'. Получим: VN' = {А1, АГ,А2.А2',АЗ}.
Шаг 3. 1 =3 = 3. Построение грамматики G' закончено.
В результате выполнения алгоритма преобразования получили нелеворекурсивную грамматику G({+.-,/.*.а,Ь},{А1,АГ .А2.А2',АЗ}.Р' .А1) с правилами:
т А2 I А2АГ
1 - +А2 I -А2 I +А2АГ I -А2АГ т АЗ I АЗА2'
1 т *АЗ I /АЗ I *АЗА2' | /АЗА2* т (Al) I а I Ь
Синтаксические распознаватели с возвратом
Принципы работы распознавателей с возвратом
Распознаватели с возвратом — это самый примитивный тип распознавателей для КС-языков. Логика их работы основана на моделировании недетерминированного МП-автомата.
Поскольку моделируется недетерминированный МП-автомат, то на некотором шаге работы моделирующего алгоритма существует возможность возникновения
нескольких возможных следующих состояний автомата. В таком случае есть два варианта реализации алгоритма [15].
В первом варианте на каждом шаге работы алгоритм должен запоминать все возможные следующие состояния МП-автомата, выбирать одно из них, переходить в это состояние и действовать так до тех пор, пока либо не будет достигнуто конечное состояние автомата, либо автомат не перейдет в такую конфигурацию, когда следующее состояние будет не определено. Если достигнуто одно из конечных состояний — входная цепочка принята, работа алгоритма завершается. В противном случае алгоритм должен вернуть автомат на несколько шагов назад, когда еще был возможен выбор одного из набора следующих состояний, выбрать другой вариант и промоделировать поведение автомата с этим условием. Алгоритм завершается с ошибкой, когда все возможные варианты работы автомата перебраны и при этом не было достигнуто ни одного из возможных конечных состояний.
Во втором варианте алгоритм моделирования МП-автомата должен на каждом шаге работы при возникновении неоднозначности с несколькими возможными следующими состояниями автомата запускать новую свою копию для обработки каждого из этих состояний. Алгоритм завершается, если хотя бы одна из выполняющихся его копий достигнет одного из конечных состояний. При этом работа всех остальных копий алгоритма прекращается. Если ни одна из копий алгоритма не достигла конечного состояния МП-автомата, то алгоритм завершается с ошибкой.
Второй вариант реализации алгоритма связан с управлением параллельными процессами в вычислительных системах, поэтому сложен в реализации. Кроме того, на каждом шаге работы МП-автомата альтернатив следующих состояний может быть много, а количество возможных параллельно выполняющихся процессов в операционных системах ограничено, поэтому применение второго варианта алгоритма осложнено. По этим причинам большее распространение получил первый вариант алгоритма, который предусматривает возврат к ранее запомненным состояниям МП-автомата, — отсюда и название «разбор с возвратами».
Следует отметить, что, хотя МП-автомат является односторонним распознавателем, алгоритм моделирования его работы предусматривает возврат назад, к уже прочитанной части цепочки символов, чтобы исключить недетерминизм в поведении автомата (который невозможно промоделировать).
Есть еще одна особенность в моделировании МП-автомата: любой практически ценный алгоритм должен завершаться за конечное число шагов (успешно или неуспешно). Алгоритм моделирования работы произвольного МП-автомата в общем случае не удовлетворяет этому условию.
Чтобы избежать таких ситуаций, алгоритмы разбора с возвратами строят не для произвольных МП-автоматов, а для МП-автоматов, удовлетворяющих некоторым заданным условиям. Как правило, эти условия связаны с тем, что МП-автомат должен строиться на основе грамматики заданного языка только после того, как она подвергнется некоторым преобразованиям. Поскольку преобразования грамматик сами по себе не накладывают каких-либо ограничений на входной
класс КС-языков, то они и не ограничивают применимости алгоритмов разбора с возвратами — эти алгоритмы применимы для любого КС-языка, заданного произвольной КС-грамматикой.
Алгоритмы разбора с возвратами обладают экспоненциальными характеристиками. Это значит, что вычислительные затраты алгоритмов экспоненциально зависят от длины входной цепочки символов: a, atVT\ п = |а|. Конкретная зависимость определяется вариантом реализации алгоритма [4, т. 1].
Доказано, что в общем случае при первом варианте реализации для произвольной КС-грамматики G(VT,VN,P,S) время выполнения данного алгоритма Тэ будет иметь экспоненциальную зависимость от длины входной цепочки, а необходимый объем памяти Мэ — линейную зависимость от длины входной цепочки: Тэ = О(еп) и М? = О(п). При втором варианте реализации, наоборот, время выполнения данного алгоритма Тэ будет иметь линейную зависимость от длины входной цепочки, а необходимый объем памяти Мэ — экспоненциальную зависимость от длины входной цепочки: Тэ = О(п) и Мэ = О(еп).
Экспоненциальная зависимость вычислительных затрат от длины входной цепочки существенно ограничивает применимость алгоритмов разбора с возвратами. Они тривиальны в реализации, но имеют неудовлетворительные характеристики, поэтому могут использоваться только для простых КС-языков с малой длиной входных предложений языка1. Для многих классов КС-языков существуют более эффективные алгоритмы распознавания, поэтому алгоритмы разбора с возвратами применяются редко.
Далее рассмотрены два основных варианта таких алгоритмов.
Нисходящий распознаватель с возвратом
Принцип работы нисходящего распознавателя с подбором альтернатив
Нисходящий распознаватель с подбором альтернатив моделирует работу МП- автомата с одним состоянием q: R({q},V,Z,5,q,S,{q}). Автомат распознает цепочки КС-языка, заданного КС-грамматикой G(VT,VN,P,S). Входной алфавит автомата содержит терминальные символы грамматики: V = VT, а алфавит магазинных символов строится из терминальных и нетерминальных символов грамматики: Z = VTuVN.
Начальная конфигурация автомата определяется так: (q,a,S) — автомат пребывает в своем единственном состоянии q, считывающая головка находится в начале входной цепочки символов awVT*, в стеке лежит символ, соответствующий целевому символу грамматики S.
Возможность использовать эти алгоритмы в реальных компиляторах весьма сомнительна, поскольку длина входной цепочки может достигать нескольких тысяч и даже десятков тысяч символов. Очевидно, что время работы алгоритма будет в таком варианте явно неприемлемым даже на самых современных компьютерах.
Конечная конфигурация автомата определяется так: (q,九入)一автомат пребывает в своем единственном состоянии q, считывающая головка находится за концом входной цепочки символов, стек пуст.
Функция переходов МП-автомата строится на основе правил грамматики:
(q,a)wb(q,储A), AwVN, aw(VTDVN)*, если правило А -> а содержится во множестве правил Р грамматики G: A f a w Р;
(qA)e5(q,a,a) VaeVT.
Работу данного МП-автомата можно неформально описать следующим образом: если на верхушке стека автомата находится нетерминальный символ А, то его можно заменить на цепочку символов а, если в грамматике языка есть правило А -> а, не сдвигая при этом считывающую головку автомата (этот шаг работы называется «подбор альтернативы»); если же на верхушке стека находится терминальный символ а, который совпадает с текущим символом входной цепочки, то этот символ можно выбросить из стека и передвинуть считывающую головку на одну позицию вправо (этот шаг работы называется «выброс»). Данный М 11- автомат может быть недетерминированным, поскольку при подборе альтернативы в грамматике языка может оказаться более одного правила вида Afa, тогда функция B(q,儿А) будет содержать более одного следующего состояния — у МП- автомата будет несколько альтернатив.
Решение о том, выполнять ли на каждом шаге работы МП-автомата выброс или подбор альтернативы, принимается однозначно. Моделирующий алгоритм должен обеспечивать выбор одной из возможных альтернатив и хранение информации о том, какие альтернативы на каком шаге уже были выбраны, чтобы иметь возможность вернуться к этому шагу и подобрать другие альтернативы. Такой алгоритм разбора называется алгоритмом с подбором альтернатив.
Данный МП-автомат строит левосторонние выводы для грамматики G(VT,VN, P,S). Для моделирования такого автомата необходимо, чтобы грамматика G(VT, VN,P,S) не была леворекурсивной, — в противном случае, очевидно, алгоритм может войти в бесконечный цикл. Поскольку, как было показано выше, произвольную КС-грамматику всегда можно преобразовать к нелеворекурсивному виду, этот алгоритм применим для любой КС-грамматики. Следовательно, им можно распознавать цепочки любого КС-языка.
Реализация алгоритма распознавателя с подбором альтернатив
Существует масса способов реализации алгоритма с подбором альтернатив [4, т. 1, 31]. Рассмотрим один из примеров реализации алгоритма нисходящего распознавателя с возвратом.
Для удобства работы все правила из множества Р в грамматике G представим в виде А -> at I a21...| an, то есть пронумеруем все возможные альтернативы для каждого нетерминального символа AwVN. Входная цепочка символов имеет вид a = а^г.-Лп，|а| = п. Алгоритм использует также дополнительное состояние b (от «back》—«назад»), которое сигнализирует о выполнении возврата к уже
прочитанной части входной цепочки1. Для хранения уже выбранных альтернатив используется дополнительный стек L2f который может содержать следующую информацию:'
символы awVT входного языка автомата;
символы вида А「где AeVN, — это означает, что среди всех возможных правил для символа А была выбрана альтернатива с номером j.
В итоге алгоритм работает с двумя стеками: L — стек МП-автомата и L2 — стек возвратов. Оба они представлены в виде цепочек символов. Символы в цепочку стека L] помещаются слева, а в цепочку стека L2 — справа. В целом, состояние алгоритма на каждом шаге определяется четырьмя параметрами: (Q,i,L[,L2), где
Q — текущее состояние автомата (q или Ь);
i — положение считывающей головки во входной цепочке символов а;
L — содержимое стека МП-автомата;
L2 — содержимое дополнительного стека.
Начальным состоянием алгоритма является состояние (q,l,S,k), где S — целевой символ грамматики. Алгоритм начинает свою работу с начального состояния и циклически выполняет шесть шагов до тех пор, пока не перейдет в конечное состояние или не обнаружит ошибку. На каждом шаге алгоритма проверяется, соответствует ли текущее состояние алгоритма заданному для данного шага исходному состоянию и выполняются ли заданные дополнительные условия. Если это требование выполняется, алгоритм переходит в следующее состояние, установленное для этого шага, если нет — шаг пропускается, алгоритм переходит к следующему шагу.
Алгоритм предусматривает циклическое выполнение следующих шагов:
Шаг 1 (Разрастание), (q, i, А0, a) f (q, i,力0, аА) если А -> 匕一это первая из всех возможных альтернатив для символа А.
Шаг 2 (Успешное сравнение), (q, i, ар, а) -> (q, i+1, р, аа), если а = a” aeVT.
Шаг 3 (Завершение). Если состояние соответствует (q, п+1,入,а), то разбор завершен, алгоритм заканчивает работу, иначе (q, i, I, а) -> (b, i, X, а), когда i ^ n + 1. Шаг 4 (Неуспешное сравнение), (q, i, а0, а) f (b, i, ар, а), если a 力 a” awVT.
Шаг 5 (Возврат по входу), (b, i, 0, аа) -> (q, i-lf а0, а), V aeVT.
Шаг 6 (Другая альтернатива). Исходное состояние (b, i, %0, аА), действия:
перейти в состояние (q, i, yj+1p, aAJ+1), если еще существует альтернатива А -> yj+1 для символа AeVN;
сигнализировать об ошибке и прекратить выполнение алгоритма, если A=S и не существует больше альтернатив для символа S;
иначе перейти в состояние (q, i, Ар, a).
Сам автомат имеет только одно состояние q, которого достаточно для его функционирования, однако нет возможности моделировать на компьютере работу недетерминированного автомата, поэтому приходится выполнять возврат к уже прочитанной части цепочки и вводить для этой цели дополнительное состояние.
В случае успешного завершения алгоритма цепочку вывода можно построить на основе содержимого стека L2, полученного в результате выполнения алгоритма. Цепочка вывода строится следующим образом: поместить в цепочку номер правила т, соответствующий альтернативе А -> уг если в стеке содержится символ А3 (все символы awVT, содержащиеся в стеке L2, игнорируются).
ВНИМАНИЕ
Следует помнить, что для применения этого алгоритма исходная грамматика не должна быть леворекурсивной. Если это условие не выполняется, то грамматику предварительно надо преобразовать к нелеворекурсивному виду.
Рассмотрим в качестве примера грамматику G({+.-,/.*.a.b},{S.R.T,F.E}.P(S) с правилами:
Р:
S т Т | TR
R т +Т | -Т | +TR | -TR
Т т Е | EF
F т *Е | /Е | *EF | /EF
Е т (S) | а | b
Это нелеворекурсивная грамматика для арифметических выражений (ранее в разделе «Устранение левой рекурсии» она была построена с помощью алгоритма устранения левой рекурсии).
Проследим разбор цепочки а+(а*Ь) из языка этой грамматики с помощью алгоритма нисходящего распознавателя с возвратами. Работу алгоритма будем представлять в виде последовательности его состояний, взятых в скобки {} (фигурные скобки используются, чтобы не путать их с круглыми скобками, предусмотренными в правилах грамматики). Альтернативы будем нумеровать слева направо, правила — слева направо и сверху вниз. Для пояснения каждый шаг работы сопровождается номером шага алгоритма, который был применен для перехода в очередное состояние (записывается через символ : — двоеточие).
Алгоритм работы нисходящего распознавателя с возвратами при разборе цепочки а+(а*Ь) будет выполнять следующие шаги:
0: {q,LS4}
1: {q.l.T.Sl}
1: {q.I.E.SITl}
1: {q.l,{S},SlTlEl}
4: {b.l,{S}.SlTlEl}
6: {q,l,a.SlTlE2}
2: {q.2A.SlTlE2a}
工 3: {b.2A,SlTlE2a}
5: {b,l.a.SlTlE2}
I 6: {q,l,b,SlTlE3}
И. 4
{b,l.b.SlTlE3}
12. 6
{b.I.E.SITl}
13. 6
{q,LEF,SlT2}
14. 1
{q.l,{S}F,SlT2El}
15. 4
{b.l,{S}F,SlT2El}
16. 6
{q(l.aF,SlT2E2}
17. 2
{q.2.F,SlT2E2a}
18. 1
{q,2,*E.SlT2E2dFl}
19. 4
{b.2,*E,SH2E2aFl}
20. 6
{q.2./E.SlT2E2aF2}
21. 4
{b,2./E,SlT2E2dF2}
22. 6
{q,2,*EF,SlT2E2aF3}
23. 4
{b,2,*EF,SlT2E2aF3}
24. 6
{q,2,/EF,SlT2E2aF4}
25. 4
{b,2./EF,SlT2E2aF4}
26. 6
{b,2.F,SH2E2a}
27. 5
{b,l,aF,SlT2E2}
28. 6
{q,l,bF,SlT2E3}
29. 4
{b.l,bF,SlT2E3}
30. 6
{b.l.EF,SlT2}
31. 6
{b.l.T.Sl}
32. 6
{q,LTR,S2}
33. 1
{q.l.ER.S2Tl}
34. 1
{q,L{S}R,S2TlEl}
35. 4
{b,l,{S}R,S2TlEl}
36. 6
{q,l,aR.S2TlE2}
37. 2
{q.2.R,S2TlE2a}
38. 1
{q,2,+T,S2TlE2aRl}
39. 2
{q,3,T.S2TlE2aRl+}
40. 1
{q.3.E.S2TlE2aRl+Tl}
41. 1
{q.3.(S),S2TlE2aRl+TlEl}
42. 2
{q.4,S).S2TlE2aRl+TlEl(}
43. 1
{q,4.T).S2TlE2aRl+TlEl(Sl}
44. 1
{q.4.E).S2TlE2aRl+TlEl(SlTl}
45. 1
{q,4,(S)).S2TlE2aRl+TlEl(SlTlEl}
46. 4
{b.4, (S)) ,S2TlE2aRl+TlEKSlTlEl}
47. 6
{q,4,a),S2TlE2aRl-bTlEl(SlTlE2}
2: {q,5.),S2TlE2aRl+TlEl(SlTlE2a}
4: {b,5,).S2TlE2aRl+TlEl(SlTlE2a}
5: {b,4,a),S2TlE2aRl+TlEl(SlTlE2}
6: {q.4,b),S2TlE2aRl+TlEl(SlTlE3}
4: {b.4.b),S2TlE2aRl+TlEl(SlTlE3}
6: {b,4,E),S2TlE2aRl+TlEl(SlTl}
6: {q.4.EF).S2TlE2aRl+TlEl(SlT2}
1: {q,4,(S)F),S2TlE2dRl+TlEl(SlT2El}
4: {b,4,(S)F),S2TlE2aRl+TlEl(SlT2El}
6: {q.4,aF).S2TlE2aRl+TlEl(SlT2E2}
2: {q,5,F).S2TlE2aRl+TlEl(SlT2E2a}
1: {q.5,*E).S2TlE2aRl+TlEl(SlT2E2aFl}
2: {q,6,E),S2TlE2aRl+TlEl(SlT2E2aFl*}
1: {q,6,(S)),S2TlE2aRl+TlEl(SlT2E2aFl*El}
4: {b,6.(S)).S2TlE2aRl+TlEl(SlT2E2aFl*El}
6: {q.6,a).S2TlE2aRl+TlEl(SlT2E2aFl*E2}
4: {b,6,a)1S2TlE2aRl+TlEKSlT2E2aFl*E2}
6: {q,6,b), S2TlE2aRl+TlEl(SlT2E2aFl*E3}
2: {q,7.).S2TlE2aRl+TlEl(SlT2E2aFl*E3b}
2: {q.8A,S2TlE2aRl+TlEl(SlT2E2aFl*E3b)}
3: Разбор закончен, алгоритм завершен.
На основании полученной цепочки номеров альтернатив S2T1E2R1T1E1S1T2E2F1E3 построим последовательность номеров примененных правил: 2, 7, 14, 3, 7, 13, 1, 8, 14, 9, 15. Получаем левосторонний вывод: S => TR n ER n dR n а+Т n а+Е п a+(S) n а+(Т) n d+(EF) n a+(aF) n а+(а*Е) п а+(а*Ь). Соответствующее ему дерево вывода приведено на рис. 4.2.
Из приведенного примера очейиден недостаток алгоритма нисходящего разбора с возвратами — значительная временная емкость: для разбора достаточно короткой входной цепочки (всего 7 символов) потребовалось 68 шагов работы алгоритма. Такого результата и следовало ожидать.
Преимуществом данного алгоритма можно считать простоту его реализации. Практически этот алгоритм разбора можно использовать только тогда, когда известно, что длина исходной цепочки символов заведомо не будет большой. Для реальных компиляторов такое условие невыполнимо, но для некоторых небольших распознавателей вполне допустимо, и тогда данный алгоритм разбора может найти применение именно благодаря своей простоте.
Еще одно преимущество алгоритма — его универсальность. На его основе можно распознавать входные цепочки языка, заданного любой КС-грамматикой, достаточно лишь привести ее к нелеворекурсивному виду (а это можно сделать с любой грамматикой). Интересно, что грамматика даже не обязательно должна быть
однозначной — для неоднозначной грамматики алгоритм найдет один из возможных левосторонних выводов.
Рис. 4.2. Дерево вывода для грамматики без левых рекурсий
Сам по себе алгоритм разбора с подбором альтернатив, использующий возвраты, не находит применения в реальных компиляторах. Однако его главные принципы лежат в основе многих нисходящих распознавателей, строящих левосторонние выводы и работающих без использования возвратов. Методы, позволяющие строить такие распознаватели для некоторых классов КС-языков, рассмотрены далее.
Распознаватель на основе алгоритма «сдвиг-свертка»
Принцип работы восходящего распознавателя по алгоритму «сдвиг-свертка»
Восходящий распознаватель по алгоритму «сдвиг-свертка» строится на основе расширенного МП-автомата с одним состоянием q: R({q},V,Z,5,q,S,{q}). Автомат распознает цепочки КС-языка, заданного КС-грамматикой G(VT,VN,PtS). Входной алфавит автомата содержит терминальные символы грамматики: V = VT;
а алфавит магазинных символов строится из терминальных и нетерминальных символов грамматики: Z = VTuVN.
Начальная конфигурация автомата определяется так: (q,a,九)—автомат пребывает в своем единственном состоянии q, считывающая головка находится в начале входной цепочки символов aeVT*, стек пуст.
Конечная конфигурация автомата определяется так: (q,k,S) — автомат пребывает в своем единственном состоянии q, считывающая головка находится за концом входной цепочки символов, в стеке лежит символ, соответствующий целевому символу грамматики S..
Функция переходов МП-автомата строится на основе правил грамматики:
(q,A)wb(q,九；у), AeVN, yG(VTuVN)', если правило Ату содержится во множестве правил Р грамматики G: А —> уеР;
(q,a)eS(q,aA) VaeVT.
Неформально работу этого расширенного автомата можно описать так: если на верхушке стека находится цепочка символов у, то ее можно заменить на нетерминальный символ А, если в грамматике языка существует правило вида А -> у, не сдвигая при этом считывающую головку автомата (этот шаг работы называется «свертка»); с другой стороны, если считывающая головка автомата обозревает некоторый символ входной цепочки а, то его можно поместить в стек, сдвинув при этом головку на одну позицию вправо (этот шаг работы называется «сдвиг», или «перенос»). Алгоритм, моделирующий работу такого расширенного МП-ав- томата, называется алгоритмом «сдвиг-свертка», или《перенос-свертка».
Данный расширенный МП-автомат строит правосторонние выводы для грамматики G(VT,VN,P,S). Для моделирования такого автомата необходимо, чтобы грамматика G(VT,VN,P,S) не содержала k-правил и цепных правил — в противном случае алгоритм может войти в бесконечный цикл из сверток. Поскольку, как было доказано выше, произвольную КС-грамматику всегда можно преобразовать к виду без Х-правил и цепных правил, то этот алгоритм применим для любой КС-грамматики. Следовательно, им можно распознавать цепочки любого КС-языка. Данный расширенный МП-автомат потенциально имеет больше неоднозначностей, чем рассмотренный выше МП-автомат, основанный на алгоритме подбора альтернатив. На каждом шаге работы автомата надо решать следующие вопросы:
что необходимо выполнять: сдвиг или свертку;
если выполнять свертку, то какую цепочку у выбрать для поиска правил (цепочка у должна встречаться в правой части правил грамматики);
какое правило выбрать для свертки, если окажется, что существует несколько правил вида Ату (несколько правил с одинаковой правой частью).
Чтобы промоделировать работу этого расширенного МП-автомата, надо на каждом шаге запоминать все предпринятые действия, чтобы иметь возможность вернуться к уже сделанному шагу и выполнить эти же действия по-другому. Этот процесс должен повторяться до тех пор, пока не будут перебраны все возможные варианты.
Реализация распознавателя с возвратами на основе алгоритма «сдвиг-свертка»
Существует несколько реализаций алгоритма «сдвиг-свертка» с возвратами [4, т. 1, 15]. Один из вариантов рассмотрен ниже.
Для работы алгоритма всем правилам грамматики G(VT,VN,P,S ), на основе которой построен автомат, необходимо дать порядковые номера. Будем нумеровать правила грамматики в направлении слева направо и сверху вниз в порядке их записи в форме Бэкуса—Наура. Входная цепочка символов имеет вид а = aia2...an, |а| = п. Алгоритм моделирования расширенного МП-автомата, аналогично алгоритму нисходящего распознавателя, использует дополнительное состояние b и дополнительный стек возвратов L2. В стек помещаются номера правил грамматики, использованных для свертки, если на очередном шаге алгоритма была выполнена свертка, или 0, если на очередном шаге алгоритма был выполнен сдвиг.
В итоге алгоритм работает с двумя стеками: Li — стек МП-автомата и L2 — стек возвратов. Первый представлен в виде цепочки символов, второй — цепочки целых чисел от 0 до т, где т — количество правил грамматики G. Символы в цепочку стека Lj помещаются справа, числа в стек L2 — слева. В целом, состояние алгоритма на каждом шаге определяется четырьмя параметрами: (Q, i, Llf L2), где
Q — текущее состояние автомата (q или Ь);
i — положение считывающей головки во входной цепочке символов а;
Lj — содержимое стека МП-автомата;
L2 — содержимое дополнительного стека возвратов.
Начальным состоянием алгоритма является состояние (q, 1,入,X). Алгоритм начинает свою работу с начального состояния и циклически выполняет пять шагов до тех пор, пока не перейдет в конечное состояние или не обнаружит ошибку.
Алгоритм предусматривает циклическое выполнение следующих шагов:
Шаг 1 (Попытка свертки), (q, i, а0, у) -> (q, i, аА, jy), если А -> 0 — это первое из всех возможных правил из множества правил Р с номером j для подцепочки р, причем оно есть первое подходящее правило для цепочки аР，для которой правило вида А -» р существует. Если удалось выполнить свертку — возвращаемся к шагу 1, иначе — переходим к шагу 2.
Шаг 2 (Перенос — сдвиг). Если i < п + 1, то (q, i, а, у) -> (q, i+1, аар Оу), aqVT. Если i = n + 1, то перейти к шагу 3, иначе перейти к шагу 1.
Шаг 3 (Завершение). Если состояние соответствует (q, n+1, S, у), то разбор завершен, алгоритм заканчивает работу, иначе перейти к шагу 4.
Шаг 4 (Переход к возврату), (q, п+1, а, у) -> (Ь, п+1, а, у).
Шаг 5 (Возврат). Если исходное состояние (b, i, аА, jy), то:
перейти в состояние (q, i, аВ, ку), еслиj > 0, и А -> р — это правило с номеромj, и существует правило В -> 0’ с номером к, к > j, такое, что а0 = а'р'; после чего надо вернуться к шагу 1;
перейти в состояние (Ь, п+1, а® у), если i = n+l,j>0, А->р — это правило с номером j, и не существует других правил из множества Р с номером k > j, таких, что их правая часть является правой подцепочкой из цепочки ар； после этого вернуться к шагу 5;
перейти в состояние (q, i+1, а0а” Оу), &£ VT, если iHn+l,j>0, А->0 — это правило с номером j, и не существует других правил из множества Р с номером k > j, таких, что их правая часть является правой подцепочкой из цепочки ар； после этого перейти к шагу 1;
иначе сигнализировать об ошибке и прекратить выполнение алгоритма.
Если исходное состояние (b, i, аа, Оу), a gVT, то если i > 1, тогда перейти в следующее состояние (b, i-1, а, у), и вернуться к шагу 5; иначе сигнализировать об ошибке и прекратить выполнение алгоритма.
В случае успешного завершения алгоритма цепочку вывода можно построить на основе содержимого стека L2, полученного в результате выполнения алгоритма. Для этого достаточно удалить из стека L2 все цифры 0.
ВНИМАНИЕ
Следует помнить, что для применения этого алгоритма исходная грамматика не должна содержать циклов и Х-правил. Если это условие не удовлетворяется, то грамматику надо предварительно преобразовать к приведенной форме.
Возьмем в качестве примера грамматику G({+(-(/,*,a.b}. {S,T,E} ,P,S):
Р:
S -> S+T I S-T I T*E I T/E I ⑸ I a I b
TT*E I T/E I (S) I a I b
E (S) I a I b
Это грамматика для арифметических выражений, в которой устранены цепные правила (ее уже рассматривали в разделе «Преобразование КС-грамматик. Приведенные грамматики»). Следовательно, в ней не может быть циклов1. Кроме того, видно, что в ней нет 入-правил. Таким образом, цепочки языка, заданного этой грамматикой, можно распознавать с помощью алгоритма «сдвиг-свертка». Проследим разбор цепочки а+(а*Ь) из языка этой грамматики. Работу алгоритма будем представлять в виде последовательности его состояний, взятых в скобки {} (фигурные скобки используются, чтобы не путать их с круглыми скобками, предусмотренными в правилах грамматики). Правила будем нумеровать слева направо и сверху вниз (всего в грамматике получается 15 правил). Для пояснения каждый шаг работы сопровождается номером шага алгоритма, который был применен для перехода в очередное состояние (записывается перед состоянием через символ «:》一двоеточие).
На самом деле исходная грамматика для арифметических выражений, которая была рассмотрена в разделе «Проблемы однозначности и эквивалентности грамматик» главы 1, тоже не содержит циклов (это легко заметить из вида ее правил), однако для чистоты утверждения цепные правила были исключены.
174
Алгоритм работы восходящего распознавателя с возвратами при разборе цепочки а+(а*Ь) будет выполнять следующие шаги:
0: {q」入入}
2: {q.2,a,[0]}
1: {q.2,S.[6,0]}
2: {q.3,S+.[0.6,0]}
2: {q.4.S+(.[0.0,6.0]}
2: {q.5,S+(a,[0,0,0,6,0]}.
1: {q.5,S+(S,[6.0,0(0.6(0]}
2: {q.6.S+(S*,[0.6,0(0,0.6.0]}
2: {q.7,S+(S*b.[0,0.6(0,0,0.6,0]}
1: {q,7.S+(S*S,[7,0.0.6,0,0.0,6.01}
2: {q,8,S+(S*S),[0.7,0(0.6.0.0,0.6(0]}
4: {b,8(S+(S*S),[0.7,0,0.6.0.0,0.6(0]}
5: {b,7.S+(S*S,[7.0.0.6(0.0.0.6,0]}
5: {q.7.S+(S*T.[12.0,0,6,0,0.0.6(0]}
2: {q.8.S+(S*T),[0,12,0.0,6,0.0.0.6.0]}
4: {b,8(S+(S*T),[0.12,0.0,6,0.0,0.6,0]}
5: {b.7,S+(S*T([12(0.0(6,0.0.0.6(0]}
5: {q.7,S+(S*E.[15,0.0,6,0,0,0,6.0]}
2: {qt8,S+(S*E),[0,15.0.0.6.0.0,0.6.0]}
4: {b.8,S+(S*E),[0,15,0,0,6,0.0,0(6,0]}
5: {b(7,S+(S*E,[15,0.0,6.0.0,0.6,0]}
5: {q.8,S+(S*a).[0,0.0,6,0(0,0(6.0]}
4:{b,8,S+(S*a),[0,0,0,6,0,0,0,6,0]}
5:{b.7.S+(S*a.[0.0.6.0,0.0.6,0]}
5:{b.6,S+(S*,[0.6,0.0,0F6.0]}
5:{b.5.S+(S([6,0.0,0,6,0]}
5:{q,5.S+(T([ll(0.0,0(6(0]}
2:{q,6.S+(T*.[0,11.0.0.0,6,0]}
2:{q.7,S+(T*b.[0,0,11,0,0,0,6,01}
l:{q.7,S+(T*S.[7.0.0.11,0.0,0.6.0]}
2:{q.8,S+(T*S).[0.7.0,0,11.0(0,0.6,0]}
4:{b.8,S+(T*S).[0,7(0,0,ll,0(0,0.6,0]}
5:{b,7,S+(T*S,[7.0,0,11.0,0,0.6,0]}
5:{q.7,S+(T*T,[12,0,0,11,0,0,0,6.0]}
2:{q.8.S+(T*T).[0.12,0.0,ll,0.0.0.6.0]}
4:{b.8,S+(T*T).[0.12,0,0,ll,0,0,0,6,0]}
5:{b.7.S+(T*T,[12.0,0.11.0,0.0,6.0]}
5:{q.7.S+(T*E,[15.0.0,11.0.0.0.6,0]}
l:{q,7.S+(S,[3,15.0.0.11,0,0,0.6,0]}
2:{q.8,S+(S).[0.3.15.0.0.11.0.0.0.6,0]}
l:{q,8,S+S.[5.0.3,15.0.0,ll,0.0,0.6,0]}
4:{b,8.S+S,[5.0,3,15.0.0.11,0.0.0,6.0]}
5:{q,8.S+T,[10,0.3.15.0.0.11.0.0.0.6,0]}
l:{q.8.S,[1.10,0.3.15,0.0.11.0,0.0.6.0]}
3: Разбор закончен, алгоритм завершен.
На основании полученной цепочки номеров правил: 1, 10, 3, 15, И, 6 получаем правосторонний вывод: S n S+T => S+(S) n S+(T*E) => S+(T*b) => S+(a*b)=> a+(a*b). Соответствующее ему дерево вывода приведено на рис. 4.3.
Рис. 4.3. Дерево вывода для грамматики без цепных правил
В приведенном примере очевиден тот же недостаток алгоритма восходящего разбора с возвратами, что и у алгоритма нисходящего разбора с возвратами — значительная временная емкость: для разбора достаточно короткой входной цепочки (всего 7 символов) потребовалось 45 шагов работы алгоритма.
Преимущество у данного алгоритма то же, что и у алгоритма нисходящего разбора с возвратами, — простота реализации. Поэтому и использовать его можно практически в тех же случаях — когда известно, что длина исходной цепочки символов заведомо не будет большой.
Этот алгоритм также универсален. На его основе можно распознавать входные цепочки языка, заданного любой КС-грамматикой, достаточно лишь преобразовать ее к приведенному виду, чтобы она не содержала цепных правил и 入-правил.
Сам по себе алгоритм «сдвиг-свертка» с возвратами не находит применения в реальных компиляторах. Однако его базовые принципы лежат в основе многих восходящих распознавателей, строящих правосторонние выводы и работающих без использования возвратов. Методы, позволяющие строить такие распознаватели для некоторых классов КС-языков, рассмотрены далее.
В принципе, два рассмотренных алгоритма — нисходящего и восходящего разбора с возвратами — имеют схожие характеристики по требующимся вычислительным ресурсам и одинаково просты в реализации. То, какой из них лучше взять для реализации простейшего распознавателя в том или ином случае, зависит прежде всего от грамматики языка. В рассмотренном примере восходящий алгоритм смог построить вывод за меньшее число шагов, чем нисходящий, — но это еще не значит, что он во всех случаях будет эффективнее для рассмотренного языка арифметических выражений. Вопрос о выборе типа распознавателя — нисходящий либо восходящий — был рассмотрен выше.
Нисходящие распознаватели КС-языков без возвратов
Стремление улучшить алгоритм с подбором альтернатив для нисходящего разбора заключается в первую очередь в определении метода, по которому на каждом шаге алгоритма можно было бы однозначно выбрать одну из всего множества возможных альтернатив. В таком случае алгоритм не требовал бы возврата на предыдущие шаги и за счет этого обладал бы линейными характеристиками. В случае неуспеха выполнения алгоритма входная цепочка не принимается, повторные итерации разбора не выполняются.
Левосторонний разбор по методу рекурсивного спуска
Наиболее очевидным методом выбора одной из множества альтернатив является выбор ее на основании символа aeVT, обозреваемого считывающей головкой автомата на каждом шаге его работы. Поскольку в процессе нисходящего разбора именно этот символ должен появиться на верхушке магазина для продвижения считывающей головки автомата на один шаг (условие 5(q,a,a) = {(qA)}, VaeVT в функции переходов МП-автомата), разумно искать альтернативу, где он присутствует в начале цепочки, стоящей в правой части правила грамматики.
По такому принципу действует алгоритм разбора по методу рекурсивного спуска.
Алгоритм разбора по методу рекурсивного спуска
В реализации этого алгоритма для каждого нетерминального символа AgVN грамматики G(VN,VT,P,S) строится процедура разбора, которая получает на
вход цепочку символов а и положение считывающей головки в цепочке i. Если для символа А в грамматике G определено более одного правила, то процедура разбора ищет среди них правило вида А -> ay, aeVT, yw(VNuVT)*, первый символ правой части которого совпадал бы с текущим символом входной цепочки а = а】. Если такого правила не найдено, то цепочка не принимается. Иначе (если найдено правило А -> ау или для символа А в грамматике G существует только одно правило А -> у), запоминается номер правила и, когда а = а》 считывающая головка передвигается (увеличивается i), а для каждого нетерминального символа в цепочке у рекурсивно вызывается процедура разбора этого символа.
Название алгоритма происходит из его реализации, которая заключается в последовательности рекурсивных вызовов процедур разбора. Для начала разбора входной цепочки нужно вызвать процедуру для символа S с параметром i = L Условия применимости метода можно получить из описания алгоритма — в грамматике G(VN,VT,P,S) VAgVN возможны только два варианта правил:
А -> % yg(VNuVT)* и это единственное правило для А;
А -» aipt | а2р21-| and，Vi： ^eVT, p1e(VNuVT)^ и если i 工 j, то а尸 а「
Этим условиям удовлетворяет незначительное количество реальных грамматик. Это достаточные, но не необходимые условия. Если грамматика не удовлетворяет этим условиям, еще не значит, что заданный ею язык не может распознаваться с помощью метода рекурсивного спуска. Возможно, над грамматикой просто необходимо выполнить ряд дополнительных преобразований.
К сожалению, не существует алгоритма, который бы позволил преобразовать произвольную КС-грамматику к указанному выше виду, равно как не существует и алгоритма, который бы позволял проверить, возможны ли такого рода преобразования. То есть для произвольной КС-грамматики нельзя сказать, анализируем ли заданный ею язык методом рекурсивного спуска или нет.
СОВЕТ
Можно рекомендовать ряд преобразований, которые способствуют приведению грамматики к требуемому виду (но не гарантируют его достижения).
Эти преобразования заключаются в следующем:
исключение 入-правил;
исключение левой рекурсии;
добавление новых нетерминальных символов (левая факторизация), например, если правило имеет вид: А -> aat | aa21...| aan | b^t | b2p21...| bmpm и ни одна цепочка символов 回 не начинается с символа а, то заменяем его на два: А -» аА' I bQi I b2p21...| bmpm и А' a( I a21...| an;
замена нетерминальных символов в правилах на цепочки их выводов, например, если имеются правила:
А -> Bi | В21...| Bn I biPt I Ь?% l-l bmpm,
Bl — «11 I «12 l-l。也，
Bn f %1 I g^п2 I…Ia叩.
заменяем первое правило на:
А аи I а121...| aik |...| ап1 | ап21…| anp | bQ J b2p21...| bmpm.
Левую факторизацию можно применять к правилам грамматики несколько раз с целью исключить для каждого нетерминального символа правила, начинающиеся с одних и тех же терминальных символов.
В целом алгоритм рекурсивного спуска эффективен и прост в реализации, но имеет очень ограниченную применимость.
Пример реализации метода рекурсивного спуска
Дана грамматика G({a,b,c}, {A,B,C,S} ,P,S):
Р:
S -» аА I ЬВ
A - a I ЬА I cC
В — b I aB I cC
C — AaBb
Необходимо построить распознаватель, работающий по методу рекурсивного спуска.
Видно, что грамматика удовлетворяет условиям, необходимым для построения такого распознавателя.
Напишем процедуры на языке программирования С, которые будут обеспечивать разбор входных цепочек языка, заданного данной грамматикой. Согласно алгоритму, необходимо построить процедуру разбора для каждого нетерминального символа грамматики, поэтому дадим процедурам соответствующие наименования. Входные данные для процедур разбора будут следующие:
цепочка входных символов;
положение указателя (считывающей головки МП-автомата) во входной цепочке;
массив для записи номеров примененных правил;
порядковый номер очередного правила в массиве.
Результатом работы каждой процедуры может быть число, отличное от нуля («истина»), или 0 («ложь»). В первом случае входная цепочка символов принимается распознавателем, во втором случае — не принимается. Для удобства реализации в том случае, если цепочка принимается распознавателем, будем возвращать текущее положение указателя в цепочке. Кроме того, потребуется еще
одна дополнительная процедура для ведения записей в массиве последовательности правил (назовем ее Write Rules).
void WnteRules(mt* piRul, int* iP, mt iRule)
{
piRul[*iP] = iRule；
1P = *iP + 1：
}
mt proc_S (char* szS, mt IN, int* pi Rui, int* IP)
{ 一
switch (szS[iN])
{
case 'a'：
WriteRulesCpiRul,1P,1)：
return proc A(szS,iN+ltpiRul.IP)：
case b~
WriteRules(piRul,1P,2);
return proc_B(szS,iN+l,piRul,1P)；
return 0;
}
int proc_A (char* szS, int iN, mt* pi Rui, int* iP)
{ 一
switch (szS[iN])
{
case ：
WriteRules(p1Rul,1P,3):
return iN+1；
case *b':
WmteRules(piRul ,1P(4):
return proc_A(szS,iN+l,pi Rui,iP)；
case 'c'：
WriteRules(piRul,1P(5);
return proc_C(szS,iN+l,piRul .IP):
return 0;
}
int proc_B (char* szS, int iN. int* piRul, int* IP)
{_
switch (szS[iN])
{
case 'b':
WriteRules(piRul ,1P,6);
return iN+1;
case 'a':
WrlteRulesCpIRul.1P,7);
return proc_B(szS,iN+l,pi Rui,iP);
case 'с':
WriteRules(piRul ,1P,8):
return proc_B(szS л N+l,рт Rui, 1P)：
} 一 return 0;
}
mt proc_C (char* szS, mt 1N, wt* piRul, int* 1P)
{ int
WriteRules(pTRu1,1P,9)：
1 = proc_A(szS,-iN,p1Rul ,1P):
if (i == 0) return 0,
if (szS[i] != a) return 0；
i н proc_B(szS,i,pl Rui,1P);
If (1 == 0) return 0：
if (szS[i] != 'b') return 0：,,
return i+l；
}
Теперь для распознавания входной цепочки необходимо иметь целочисленный массив Rules достаточного объема для хранения нбмеров правил. Тогда работа распознавателя заключается в вызове процедуры pro^SCStr.O.Rules.&N), где Str — это входная цепочка символов, N — переменная для запоминания количества примененных правил (первоначально N = 0). Затем требуется обработка полученного результата: если результат на 1 превышает длину цепочки — цепочка принята, иначе — цепочка не принята. В первом случае в массиве Rules будем иметь последовательность номеров правил грамматики, необходимых для вывода цепочки, а в переменной N — количество этих правил.
Объем массива Rules заранее не известен, так как заранее не известно количество шагов вывода. Во избежание проблем с недостаточным объемом статического массива приведенные выше процедуры распознавателя можно модифицировать так, чтобы они работали с динамическим распределением памяти. На логику работы распознавателя это никак не повлияет1.
Из приведенного примера видно, что алгоритм рекурсивного спуска удобен и прост в реализации. Главным препятствием в его применении является то, что класс грамматик, допускающих разбор на основе этого алгоритма, сильно ограничен.
Расширенные варианты метода рекурсивного спуска
Метод рекурсивного спуска позволяет выбрать альтернативу, ориентируясь на текущий символ входной цепочки, обозреваемый считывающей головкой МП-авто-
Следует помнить также, что метод рекурсивного спуска основан на рекурсивном вызове множества процедур, что при значительной длине входной цепочки символов может потребовать соответствующего объема стека вызовов для хранения адресов процедур, их параметров и локальных переменных. Более подробно этот вопрос рассмотрен в разделе «Распределение памяти» главы 5 данного учебника.
мата. Если имеется возможность просматривать не один, а несколько символов вперед от текущего положения считывающей головки, то можно расширить область применимости метода рекурсивного спуска. В этом случае уже можно искать правила на основе некоторого терминального символа, входящего в правую часть правила. Естественно, и в таком варианте выбор должен быть однозначным — для каждого нетерминального символа в левой части правила необходимо, чтобы в правой части правила не встречалось двух одинаковых терминальных символов. Этот метод требует также анализа типа присутствующей в правилах рекурсии, поскольку один и тот же терминальный символ может встречаться во входной строке несколько раз, и в зависимости от типа рекурсии следует искать его крайнее левое или крайнее правое вхождение в строке.
Рассмотрим грамматику арифметических выражений для символов а и b G({+,-, /,*,a,b},{S,T,E},P,S):
Р:
S f S+T I S-T I т
T f T*E I T/E I E
E (S) I a I b
Это грамматика для арифметических выражений, которая уже была рассмотрена в разделе «Проблемы однозначности и эквивалентности грамматик» главы 1 и служила основой для построения распознавателей в разделе «Синтаксические распознаватели с возвратом».
Запишем правила этой грамматики в форме с применением метасимволов. Получим:
Р:
S f Т{(+Т「Т)}
Т f Е{(*Е,/Е)}
Е - (S) I a I b
При такой форме записи процедура разбора для каждого нетерминального символа становится тривиальной.
Для символа S распознаваемая строка должна всегда начинаться со строки, допустимой для символа Т, за которой может следовать любое количество символов + или -, и если они найдены, то за ними опять должна быть строка, допустимая для символа Т. Аналогично, для символа Т распознаваемая строка должна всегда начинаться со строки, допустимой для символа Е, за которой может следовать любое количество символов * или /, и если они найдены, то за ними опять должна быть строка, допустимая для символа Е. С другой стороны, для символа Е строка должна начинаться строго с символов (, а или Ь, причем в первом случае за символом ( должна следовать строка, допустимая для символа S, а за ней — обязательно символ ).
Исходя из этого построены процедуры разбора входной строки на языке Pascal (используется Borland Pascal или Borland Delphi, которые допускают тип string — строка). Входными данными для них являются:
исходная строка символов;
текущее положение указателя в исходной строке;
длина исходной строки (в принципе, этот параметр можно опустить, но он введен для удобства);,
результирующая строка правил.
Процедуры построены так, что в результирующую строку правил помещаются номера примененных правил в строковом формате, перечисленные через запятую (,).Правила нумеруются в грамматике, записанной в форме Бэкуса—Наура. в порядке слева направо и сверху вниз (всего в исходной грамматике 9 правил). Распознаватель строит левосторонний вывод, поэтому на основе строки номеров правил всегда можно получить цепочку вывода или дерево вывода.
Для начала разбора нужно вызвать процедуру proc_S(S,l,N,Pr),
где:
S — входная строка символов;
N — длина входной строки (в языке Borland Pascal вместо N можно взять Length(S));.
Рг — строка, куда будет помещена последовательность примененных правил. Результатом выполнения proc_S(S,l,N,Pr) будет N + 1, если строка S принимается, и некоторое число, меньшее N + 1, если строка не принимается. Если строка S принимается, то строка Рг будет содержать последовательность номеров правил, которые необходимо применить для того, чтобы вывести S1.
procedure proc_S (S string； i,n- integer, var pr- string): integer： var si • string:
begin
i := proc_T(S,i,n,sl):
if 1 > 0 then
尸'3,' + si;
while (i <= n) and (i <> 0) do
case S[i] of
'+': begin
if 1 = n then i := 0 else begin
1 .= proc_T(S.i+l.n,sl)；
pr := '1,' + pr +','+ si; end；
:begin
if 1 = n then 1 ■= 0
else
Использование языка программирования Borland Pascal накладывает определенные технические ограничения на данный распознаватель — длина строки в этом языке не может превышать 255 символов. Однако данные ограничения можно снять, если реализовать свой тип данных «строка». При использовании Borland Delphi эти ограничения отпадают. Конечно, такого рода ограничения не имеют принципиального значения при теоретическом исследовании работы распознавателя, тем не менее автор считает необходимым упомянуть о них.
begin
i :== proc_T(S,1+l,n.sl)：'
pr := '2,' + pr +' J+ si:
end；
end：
else break；
end；{case}
end； {if}
proc_S ：= i;
procedure proc_S (S： string； i,n： Integer； var pr： string)： integer： var si ： string;
begin
:= proc_E(S,i.n.sl);
if i > 0 then
begin
pr := 6' + si：
while (i <= n) and (1 <> 0) do
case S[i] of
: begin
if i = n then i ：= 0
else
begin
i := proc_E(S,i+l,n,sl);
pr := '4.* + pr +',*+ si：
' end;
end；
/： begin
if i = n then i ：= 0
else
begin
1 ：= proc_E(S,i+l,n,sl);
pr := '5,' + pr +‘「+ si；
end；
end；
else break；
end；{case}
end；{if}
proc_S ：= i；
orocedure proc_E (S： string； i,n： Integer； var pr： string)： integer； /ar si : string： oegin
case S[i] of
'a*: begin
pr ：= 8：
proc_E := i+l；
end；
'Ь'• begin рг 尸 ргос_Е ：= 1+1：.
end； '(' begin proc_E := О： if i < n then begin
尸 proc_S(Sj+l,n,sl): if (i > 05 and (i < n) then
'pr := '7.' + si;
if S[i] = ')' then proc_E := i+l； end： end； end： else proc_E ：= 0； end；{case}
end；
Конечно, и в данном случае алгоритм рекурсивного спуска позволил построить достаточно простой распознаватель, однако прежде чем удалось его применить, потребовался неформальный анализ правил грамматики. Далеко не всегда такого рода неформальный анализ является возможным, особенно если грамматика содержит десятки и даже сотни различных правил — человек не всегда в состоянии уловить их смысл и взаимосвязь. Поэтому модификации алгоритма рекурсивного спуска, хотя просты и удобны, но не всегда применимы. Даже понять сам факт того, можно или нет в заданной грамматике построить такого рода распознаватель, бывает очень непросто [4. т. 1, 13, 15, 17, 19. 50].
Далее будут рассмотрены распознаватели и алгоритмы, которые основаны на строго формальном подходе. Они предваряют построение распознавателя рядом обоснованных действий и преобразований, с помощью которых подготавливаются необходимые исходные данные. В этом случае подготовку всех исходных данных для распознавателя можно формализовать и автоматизировать вне зависимости от объема грамматики (количества правил и символов в ней). Эти предварительные действия можно выполнить на компьютере, в то время как расширенная трактовка рекурсивного спуска предполагает неформальный анализ грамматики человеком, и в этом серьезный недостаток метода.
Щк)-грамматики
Логическим продолжением идеи, положенной в основу метода рекурсивного спуска, является предложение использовать для выбора одной из множества альтернатив не один, а несколько символов входной цепочки. Однако напрямую переложить алгоритм выбора альтернативы для одного символа на такой же алгоритм для цепочки символов не удастся — два соседних символа в цепочке на самом деле могут быть выведены с использованием различных правил грамматики, поэтому неверным будет напрямую искать их в одном правиле. Тем не менее
существует класс грамматик, основанный именно на этом принципе — выборе одной альтернативы из множества возможных на основе нескольких очередных символов в цепочке. Это ЬЬ(к)-грамматики. Правда, алгоритм работы распознавателя для них не так очевидно прост, как рассмотренный выше алгоритм рекурсивного спуска.
Грамматика обладает свойством LL(k), к > 0, если на каждом шаге вывода для однозначного выбора очередной альтернативы достаточно знать символ на верхушке стека и рассмотреть первые к символов от текущего положения считывающей головки во входной цепочке символов.
Грамматика называется LL(k)-грамматикой, если она обладает свойством LL(k) для некоторого к > О1.
Название «LL(k)» несет определенный смысл. Первая литера «L» происходит от слова «left» и означает, что входная цепочка символов читается в направлении слева направо. Вторая литера «L» также происходит от слова «left» и означает, что при работе распознавателя используется левосторонний вывод. Вместо «к» в названии класса грамматики стоит некоторое число, которое показывает, сколько символов надо рассмотреть, чтобы однозначно выбрать одну из множества альтернатив. Так, существуют LL( 1 )-грамматики, ЬЬ(2)-грамматики и другие классы. В совокупности все ЬЬ(к)-грамматики для всех к > 0 образуют класс LL-грамматик. На рис. 4.4 схематично показано частичное дерево вывода для некоторой LL(k)- грамматики, В нем ① обозначает уже разобранную часть входной цепочки а, которая построена на основе левой части дерева у. Правая часть дерева х — это еще не разобранная часть, а А — текущий нетерминальный символ на верхушке стека МП-автомата. Цепочка х представляет собой незавершенную часть цепочки вывода, содержащую как терминальные, так и нетерминальные символы. После завершения вывода символ А раскрывается в часть входной цепочки и, а правая часть дерева х преобразуется в часть входной цепочки т. Свойство LL(k) предполагает, что однозначный выбор альтернативы для символа А может быть сделан на основе к первых символов цепочки от, являющейся частью входной цепочки а. Алгоритм разбора входных цепочек для ЬЬ(к)-грамматики носит название «к-пред- сказывающего алгоритма». Принципы его выполнения во многом соответствуют функционированию МП-автомата с той разницей, что на каждом шаге работы этот алгоритм может просматривать к символов вперед от текущего положения считывающей головки автомата.
Для ЬЬ(к)-грамматик известны следующие полезные свойства:
всякая ЬЬ(к)-грамматика для любого к > 0 является однозначной;
существует алгоритм, позволяющий проверить, является ли заданная грамматика ЬЬ(к)-грамматикой для строго определенного числа к.
Требование к > 0, безусловно, является разумным — для принятия решения о выборе той или иной альтернативы МП-автомату надо рассмотреть хотя бы один символ входной цепочки. Если представить себе LL-грамматику с к = 0, то в такой грамматике вывод совсем не будет зависеть от входной цепочки. В принципе, такая грамматика возможна, но в ней будет всего одна-единственная цепочка вывода. Поэтому практическое применение языка, заданного такого рода грамматикой, представляется весьма сомнительным.
Рис. 4.4. Схема построения дерева вывода для Щк)-грамматики
Кроме того, известно, что все грамматики, допускающие разбор по методу рекурсивного спуска, являются подклассом ЬЬ(1)-грамматик. То есть любая грамматика, допускающая разбор по методу рекурсивного спуска, является ЬЬ(1)-грам- матикой (но не наоборот!).
Есть, однако, неразрешимые проблемы для LL(k)• грамматик:
не существует алгоритма, который бы мог проверить, является ли заданная КС-грамматика ЬЬ(к)-грамматикой для некоторого произвольного числа к;
не существует алгоритма, который бы мог преобразовать произвольную КС- грамматику к виду ЬЬ(к)-грамматики для некоторого к (или доказать, что преобразование невозможно).
Это общие проблемы, характерные для всех классов КС-грамматик.
Для ЬЬ(к)-грамматики при k > 1 совсем не обязательно, чтобы все правые части правил грамматики для каждого нетерминального символа начинались с к различных терминальных символов. Принципы распознавания предложений входного языка такой грамматики накладывают менее жесткие ограничения на правила грамматики, поскольку к соседних символов, по которым однозначно выбирается очередная альтернатива, могут встречаться в нескольких правилах грамматики (эти условия рассмотрены ниже).
ПРИМЕЧАНИЕ
Грамматики, у которых все правые части правил для всех нетерминальных символов начинаются с к различных терминальных символов, носят название «сильно LL(k)- грамматики». Метод построения распознавателей для них достаточно прост, алгоритм разбора очевиден, но, к сожалению, такие грамматики встречаются крайне редко
Поскольку все ЬЬ(к)-грамматики используют левосторонний нисходящий распознаватель, основанный на алгоритме с подбором альтернатив, очевидно, что они не могут допускать левую рекурсию.
ВНИМАНИЕ
Никакая леворекурсивная грамматика не может быть LL-грамматикой. Следовательно, первым делом при попытке преобразовать грамматику к виду LL-грамматики необходимо устранить в ней левую рекурсию.
Класс LL-грамматик широк, но все же он недостаточен для того, чтобы покрыть все возможные синтаксические конструкции в языках программирования. Известно, что существуют детерминированные КС-языки, которые не могут быть заданы LL(k)-грамматикой ни для каких к. Однако LL-грамматики удобны для использования, поскольку позволяют построить линейные распознаватели.
Очевидно, для каждого нетерминального символа LL( 1 )-грамматики не может быть двух правил, начинающихся с одного и того же терминального символа. Однако это менее жесткое условие, чем то, которое накладывает распознаватель по методу рекурсивного спуска, поскольку, в принципе, LL( 1 )-грамматика допускает в правой части правил цепочки, начинающиеся с нетерминальных символов, а также Х-правила. LL( 1 )-грамматики позволяют построить достаточно простой и эффективный распознаватель, поэтому они рассматриваются далее отдельно в соответствующем разделе.
Методы построения распознавателей для LL(k)-грамматик при k > 1 в данной книге не рассматриваются, с ними можно ознакомиться в работах [4, т. 1, 15].
Синтаксический разбор для ЕЬ(1)-грамматик
Для построения распознавателей языков, заданных ЬЬ(к)-грамматиками, используются два множества, определяемые следующим образом:
FIRST(k,a) — множество терминальных цепочек, выводимых из ae(VTuVN)\ укороченных до к символов;
FOLLOW(k,A) — множество укороченных до к символов терминальных цепочек, которые могут следовать непосредственно за AeVN в цепочках вывода.
Формально эти два множества могут быть определены следующим образом: FIRST(k,a) = {coeVT* | либо 同 К к и a => * со, либо |со| > к и a =^> * сох, xe(VTu VN)*}, ae(VTuVN)\k>0,
FOLLOW(k,A) = {cowVr I S => * aAy и a)£FIRST(y,k), aeVT*}, AeVN, к > 0.
Эти множества используются не только для построения распознавателей языков, заданных ЬЬ(к)-грамматиками, но и для ряда других классов грамматик, которые будут рассматриваться далее. В случае ЬЬ(1)-грамматик используются множества FIRST(l,a) и FOLLOW(1,A).'
Для LL( 1 )-грамматик алгоритм работы распознавателя предельно прост. Он заключается всего в двух условиях, проверяемых на шаге выбора альтернативы. Исходными данными для этих условий являются символ awVT, обозреваемый считывающей головкой, и символ AwVN, находящийся на верхушке стека.
Эти условия можно сформулировать так:
необходимо выбрать в качестве альтернативы правило Afa, если aeFIRST(l,a);
необходимо выбрать в качестве альтернативы правило А -> X, если aeFOLLOW(l,A).
Если ни одно из этих условий не выполняется, то цепочка не принадлежит заданному языку, и алгоритм должен сигнализировать об ошибке.
Действия алгоритма на шаге «выброса» остаются без изменений.
Кроме того, чтобы убедиться, является ли заданная грамматика G(VT,VN,P,S) LL( 1 )-грамматикой, необходимо и достаточно проверить следующее условие: для каждого символа AeVN, для которого в грамматике существует более одного правила вида А -> а〔 I а? |...| ап, должно выполняться требование FIRST(l,a]FOtLOW (1,А)) с FIRST(l,aJFOLLOW(l,A)) = 0 Vi н j, n>i>0, n>j>0. Очевидно, что если для символа AeVN отсутствует правило вида А -> X, то согласно этому требованию все множества FIRST(l,aJ, FIRST(l,a2), ..., FIRST(l,an) должны попарно не пересекаться, если же присутствует правило А -> X, то они не должны также пересекаться со множеством FOLLOW(1,A).
ВНИМАНИЕ
Очевидно, что ЬЬ(1)-грамматика не может содержать для любого нетерминального символа AgVN двух правил, начинающихся с одного и того же терминального символа.
Условие, накладываемое на правила LL( 1 )-грамматики, является довольно жестким. Очень немногие реальные грамматики могут быть отнесены к классу ЬЬ(1)-грамматик. Например, даже довольно простая грамматика G({d},{S}, {St а I aS}, S) не удовлетворяет этому условию (хотя она является регулярной праволинейной грамматикой).
Иногда удается преобразовать правила грамматики так, чтобы они удовлетворяли требованию LL( 1 )-грамматик. Например, приведенная выше грамматика может быть преобразована к виду G1 ({а}, {S,A}, {S -> аА.А -> X | S} .S)1. В такой форме она уже является LL( 1 )-грамматикой. Но формального метода преобразовать произвольную КС-грамматику к виду LL( 1 )-грамматики или убедиться в том, что такое преобразование невозможно, не существует.
СОВЕТ
Для приведения произвольной грамматики к виду LL( 1 )-грамматики можно рекомендовать преобразования, рассмотренные выше при знакомстве с методом рекурсивного спуска.
Но применение преобразований не гарантирует, что произвольную КС-грамматику удастся привести к виду LL( 1 )-грамматики.
Можно убедиться, что эти две грамматики задают один и тот же язык: L(G) = L(G'). Это легко сделать, поскольку обе они являются не только КС-грамматиками, но и регулярными праволинейными грамматиками. Кроме того, формальное преобразование G' в G существует — достаточно устранить в грамматике G' Х-правила и цепные правила, и будет получена исходная грамматика G. А вот формального преобразования G в G' нет. В общем случае все может быть гораздо сложнее.
Для того чтобы запрограммировать работу МП-автомата, выполняющего разбор входных цепочек символов языка, заданного LL( 1)-грамматикой, надо научиться строить множества символов FIRST(l,a) и FOLLOW(1,A). Для множества FIRST(l，a) все очевидно, если цепочка а начинается с терминального символа b (а = bp, beVT, ae(VTuVN)+, 0w(VTuVN)*) — в этом случае FIRST(l,a)= ={b}, если же она начинается с нетерминального символа В (a = Bp, BwVN, ae(VTuVN)+, Pe(VTuVN)*), то FIRST(l.a) = FIRST(1,B). Следовательно, для LL (1)-грамматик остается только найти алгоритм построения множеств FIRST(1,B) и FOLLOW(1JA) для всех нетерминальных символов A,BwVN*
Исходными данными для этих алгоритмов служат правила грамматики.
Алгоритм построения множества FIRST(1 ,А)
Алгоритм строит множества FIRST(1,A) сразу для всех нетерминальных символов грамматики G(VT,VN,P,S), AeVN. Для выполнения алгоритма надо предварительно преобразовать исходную грамматику G(VT,VN,P,S) в грамматику G'(VT,VN',P',S'), не содержащую Х-правил. На основании полученной грамматики G' и выполняется построение множеств FIRST(1,A) для всех AgVN (если AwVN, то, согласно алгоритму преобразования, также справедливо AwVN'). Множества строятся методом последовательного приближения. Если в результате преобразования грамматики G в грамматику G' множество VN' содержит новый символ S', то при построении множества FIRST(1,A) он не учитывается.
Алгоритм состоит из нескольких шагов:
Шаг 1. Для всех AeVN: FIRSTO(1,A) = {Х| А-> XaeP, Xe(VTuVN), ae(VTuVN)*} (первоначально вносим во множество первых символов для каждого нетерминального символа А все символы, стоящие в начале правых частей правил для этого символа A); i := 0.
Шаг 2 Для всех AeVN: FIRST1+1(1,A) = FIRSTi(l,A)uFIRST1(l,B), для всех нетерминальных символов Bw(FIRST](l,A)cVN).
Шаг 3. Если 3 AeVN: FIRST1+1(1,A)工 FIRST<1,A), то i := i + 1 и вернуться к шагу 2, иначе перейти к шагу 4.
Шаг 4. Для всех AgVN: FIRST(1,A) = FIRST】(1,A) \ VN (исключаем из построенных множеств все нетерминальные символы).
Алгоритм построения множества FOLLOW(1 ,А)
.Алгоритм строит множества FOLLOW(1,A) сразу для всех нетерминальных :имволов грамматики G(VT,VN,P,S), AgVN. Для выполнения алгоритма пред- зарительно надо построить все множества FIRST(1,A), V AeVN. Множества ггроятся методом последовательного приближения. Алгоритм состоит из нескольких шагов:
Шаг 1. Для всех AeVN: FOLLOW0(tA) = {X | 3 В -> aAX₽e Р, BeVN, Xe(VTu VN), a,pe(VTuVN)*} (первоначально вносим во множество последующих символов для каждого нетерминального символа А все символы, которые в правых частях правил встречаются непосредственно за символом A); i := 0.
Шаг 2. FOLLOW0(1,S)工 FOLLOW0(l,S)u{X} (вносим пустую цепочку во множество последующих символов для целевого символа S — это означает, что в конце разбора за целевым символом цепочка кончается, иногда для этой цели используется специальный символ конца цепочки:丄J.
Шаг 3. Для всех AeVN: FOLLOW； (1,А)工 FOLLOWO,A)uFIRST(l,B), для всех нетерминальных символов Be(FOLLOW1(l,A)nVN).
Шаг 4. Для всех AwVN: FOLLOW； (1,А) = FOLLOW；(l,A)uFOLLOW；(l,B) для всех нетерминальных символов Bw(FOLLOW；(l,A)cVN), если существует правило В —> X.
Шаг 5. Для всех AeVN: FOLLOW1+1(1,A) ^ FOLLOW\(l,A)uFOLLOW\(l,B). для всех нетерминальных символов BeVN, если существует правило В —> аА. ae(VTuVN)4.
Шаг 6. Если 3 AwVN: FOLLOW1+1(1,A) w FOLLOW^ 1,А), то i := i + 1 и вернуться к шагу 3, иначе перейти к шагу 7.
Шаг 7. Для всех AeVN: FOLLOW(1,A) = FOLLOW/1,A)\VN (исключаем из построенных множеств все нетерминальные символы).
Пример построения распознавателя для ЬЬ(1)-грамматики
Рассмотрим в качестве примера грамматику G({+,-,/,*,a.b}.{S,R.T,FtE},P,S) с правилами:
Р:
S — Т | TR
R - +Т | -Т | +TR | -TR
Т - Е | EF
F *Е | /Е | *EF | /EF
Е -> (S) | а | Ь
Это нелеворекурсивная грамматика для арифметических выражений (ранее она была построена в разделе «Синтаксические распознаватели с возвратом»).
Эта грамматика не является LL( 1 )-грамматикой. Чтобы убедиться в этом, достаточно обратить внимание на правила для символов R и F — для них имеется по два правила, начинающихся с одного и того же терминального символа.
Преобразуем ее в другой вид, добавив Х-правила. В результате получим новую грамматику G'({+,-,/,*,a,b}.{S,R,T,F,E},P',S) с правилами:
Р':
S — TR
R -九 I +TR I -TR'
T - EF
F X I *EF I /EF E -> (S) I a I b
Построенная грамматика G1 эквивалентна исходной грамматике G. В этом можно убедиться, если воспользоваться алгоритмом устранения Х-правил из раздела «Преобразование КС-грамматик» главы 4. Применив его к грамматике G', получим грамматику G, а по условиям данного алгоритма L(G') = L(G). Таким образом,
мы получили эквивалентную грамматику, хотя она и построена неформальным методом (следует помнить, что не существует формального алгоритма, преобразующего произвольную КС-грамматику в ЬЬ(к)-грамматику для заданного к).
Эта грамматика является ЬЬ(1)-грамматикой. Чтобы убедиться в этом, построим множества FIRST и FOLLOW для нетерминальных символов этой грамматики (поскольку речь заведомо идет об LL( 1 )-грамматике, цифру 1 в обозначении множеств опустим для сокращения записи).
Для построения множества FIRST будем использовать исходную грамматику G, так как именно она получается из G' при устранении Х-правил.
Построение множества FIRST:
Шаг 1. FIRSTO(S) = {Т};
FIRSTO(R) = { +「}:
FIRSTO(T)=任};
FIRSTO(F) = {*./}：
FIRSTO(E) = {(B,b};
i = 0.
Шаг 2. FIRSTKS) = {T,E}；
FIRSTKR) = {+「}:
FIRSTKT) = {E,(,a,b};
FIRSTl(F) = {*./}.
FIRSTl(E) = {(.a.b}.
Шаг 3・ 1 = 1, возвращаемся к шагу 2.
Шаг 2. FIRST2(S) = {T,E,(,d,b},
FIRST2(R) = {+「}：
FIRST2(T) = {E,(ab};
FIRST2(F) = {*./}:
FIRST2(E) = {(.a.b}.
Шаг 3. i = 2, возвращаемся к шагу 2.
Шаг 2. FIRST3(S) = {T.E,(.a,b}:
FIRST3(R) = {+,-}:
FIRST3(T)=任，(，d,b}：
FIRST3(F) = {*,/};
FIRST3(E) = {(.a.b}.
二％? 3. 1=2, переходим к шагу 4.
二成 4. FIRST(S) = {(.a.b}：
FIRST(R) = {+「};
FIRST(T) = { (,a,b}：
FIRST(F) = {*,/};
FIRST(E) = {(,d*b}；
Построение закончено.
Построение множества FOLLOW:
Шаг 7. FOLLOWO(S) = {)};
FOLLOWO(R) = 0;
FOLLOWO(T) == {R}： FOLLOWO(F) = 0; FOLLOWO(E) = {F}: 1 = 0.
Шаг 2. FOLLOWO(S) = {) A}: FOLLOWO(R) = 0; FOLLOWO(T) = {R}: FOLLOWO(F) = 0： FOLLOWO(E) = {F}.
Шаг 5. FOLLOW 0(S) = {) A}: FOLLOW 0(R) = 0: FOLLOW'O(T) = {R, +「}: FOLLOW 0(F) = 0;
FOLLOW0(E)工{F,*,/}.
Шаг 4. FOLLOW'O(S) = {) A}: FOLLOW'O(R)工 0;
FOLLOW'O(T)工{R, +「}; FOLLOW'O(F) = 0;
FOLLOW'O(E) = {F,*,/};
Шаг 5. FOLLOWKS) = {),九}, FOLLOWKR) = {)4}: FOLLOWKT) = {R, + ,-}; FOLLOWKF) = {% +「}： FOLLOWKE) = {F,*,/};
Шаг 6. i=l, возвращаемся к шагу 3, Шаг 5. FOLLOWKS) = {) А}: FOLLOWKR) = {)А}: FOLLOWKT) = {R. + .-}; FOLLOWKF) = {R. + .-}： FOLLOWKE) = {F,*,/}:
Шаг 4. FOLLOWKS) = {)4}: FOLLOWU(R) = {) A}; FOLLOWKT) = {R, + ,~.)4}: FOLLOWKF) = {R. + .-J A}: FOLLOWKE) = {F,R,)4}:
Шаг 5. FOLLOWS) = {) А}:
F0LL0W2(R) = {) А},
F0LL0W2(T) = {R, +「，)4}:
F0LL0W2(F) = {R, +「.)4}：
F0LL0W2(E) = {F,R,)4}:
Шаг 6. i=2, возвращаемся к шагу 3.
Шаг 3. F0LL0W'2(S) ^ {) А},
F0LL0W'2(R) = {) А};
F0LL0W'2(T) = {R.+「.)“};
FOLLOW 2(F) = {R. +「，)4}；
F0LL0W'2(E) = {F.R.A}:
Шаг 4. F0LL0W"2(S) ^ {) A};.
F0LL0W"2(R)工{)4}:
F0LL0W"2(T) == {R. + .-J A};
F0LL0W"2(F) = {R, +「，)4}:
F0LL0W"2(E) = {F,R,*,/. + ,-.) A};
Шаг 5. F0LL0W3(S) = {)4};
F0LL0W3(R)工{)4}:
F0LL0W3(T) = {R. + .-J A};
F0LL0W3CF) = {R, +「，)7};
F0LL0W3(E) = {F,R.*,/, +「，)，九};
Шаг 6. 1=2, переходим к шагу 7.
Шаг 7. FOLLOW(S) = {),入};
FOLLOW(R) = {) А}:
FOLLOW(T) = { + ,-.) А};
FOLLOW(F) = { + ,-.),九};
FOLLOW(E) =А}:
Построение закончено.
В результате выполнения построений можно увидеть, что необходимое и достаточное условие принадлежности КС-грамматики к классу LL(1)-грамматик выполняется.
Построенные множества FIRST и FOLLOW можно представить в виде таблицы. Результат выполненных построений отражает табл. 4.1.
Рассмотрим работу распознавателя. Ход разбора будем отражать по шагам работы алгоритма в виде конфигурации МП-автомата, к которой добавлена цепочка, содержащая последовательность примененных правил грамматики. Состояние автомата q, казанное в его конфигурации, можно опустить, так как оно единственное: (a,Z,y),
、一непрочитанная часть входной цепочки символов;
Z — содержимое стека (верхушка стека находится слева);
у — последовательность номеров примененных правил (последовательность □、 полняется слева, так как автомат порождает левосторонний вывод).
Таблица 4.1. Множества FIRST и FOLLOW для грамматики G'
Символ AgVN
FIRST(1,A)
FOLLOW(1,A)
S
(а b
）入
R
）入
Т
(а b
+ -)九
F
*/
+ -）入
Е
(а b
*/ + )入
Примем, что правила в грамматике нумеруются в порядке слева направо и сверху вниз. На основе номеров примененных правил при успешном завершение разбора можно построить цепочку вывода и дерево вывода.
В качестве примера возьмем две правильных цепочки символов а+а*Ь и (а+а)*: и две ошибочных цепочки символов d+а* и (+а)*Ь.
Разбор цепочки а+а*Ь:
(a+a*b.SA)
(a+a*b,TR, 1), так как awFIRST(l,TR)
(a+a*b,EFR,1.5), так как dwFIRST(l,EF)
(a+a*b.aFR,l,5.10), так как aeFIRST(l,a)
(+a*b, FR, 1.5.10)
(+a*b,R,1,5.10,6), так как +gFOLLOW(1,F)
(+a*b.+TR, 1,5,10,6.3), так как +gFIRST(1,+TR)
(a*b,TR,1,5,10.6.3)
(a*b,EFR,l,5,10,6,3,5)f так как aeFIRST(l,EF)
(a*b,aFR.1.5.10.6.3.5.10), так как awFIRST(l,a)
И. (*b.FR,l.5,10.6,3,5.10)
(*b,*EFR,1.5.10,6.3.5,107), так как *wFIRST(i,*EF)
(b,EFR.l,5,10.6.3,5.10.7)
4- С1^ ^ ^4- С1^ ^ ^(b,bFR,1.5.10.6,3,5.10.7.11), так как beFIRST(l,b)
4- С1^ ^ ^
4- С1^ ^ ^
(X,FR,1.5,10.6.3,5,10.7,ll)
(X,R,l,5.10.6.3.5.10,7,ll,6)>TaK как XgFOLLOW(1,F)
(XA. 1.5.10.6,3,5,10,7.11.6.2), так как XgFOLLOW(1,R), разбор закончен. Цепочка принимается.
Получили цепочку вывода:
S n TR n EFR n aFR n aFR n aR n a+TR n a+EFR n a+aFR n d+a*EFR n a+a*bFR n a+a*bR п а+а*Ь
Соответствующее ей дерево вывода приведено на рис. 4.5.
Рис. 4.5. Дерево вывода в LL(1 (-грамматике для цепочки «а+а*Ь»
Разбор цепочки (а+а)*Ь:
((a+a)*b,SA)
((a+a)*b.TR,l), так как (gFIRST(1,TR)
((a+d)*b, EFR 丄 5), так как ( е FIRST(1 ,EF)
((a-ba)*b.(S)FR,l,5,9), таккак (eFIRST(l,(S))
(a-ba)*b.S)FR,1.5.9)
(a+a)*btTR)FR.l,5,9,l)> так как aGFIRST(tTR)
(a+a)*b,EFR)FR,l,5.9.1.5), так как dwFIRST(l,EF)
S. (a+a)*b,aFR)FR1l,5,9,1.5,10)JTaK как aGFIRST(l,a)
(+a)*b,FR)FR,l,5,9,l,5.10)
(+a)*b,R)FR,1.5.9,1.5,10,6), так как+gFOLLOW(1,F)
：1・(+a)*b.+TR)FR,159,151063), так как +eFIRST(1,+TR) 1
：2. (a)*b.TR)FR,1,5,9,1,5,10,6,3)
：3. (a)*b,EFR)FR.1.5,9.1l5.10.6.3.5), так как aeFIRST(l,EF)
(a)*b,aFR)FR.l,5,9.1.5,10,6,3,5,10), так как aeFIRST(l}a)
5 (q,)*b.FR)FRf1.5,9,l,5,10.6,3.5.10)
$ (产b,R)FR,1,5,9,1,5,10,6,3,5,10,6), так как )gFOLLOW(1,F)
“(产b,)FR,L5,9,L5」0.6,3,5」0,6・2), так как )wFOLLOW(l,R)
s (*b,FR,1.5,9,1,5.10.6.3.5.10,6.2)
-(*b.*EFR.l,5,9,l,5,10,6,3,5.10,6,2.7), так как *gFOLLOW(1,*EF)
30. (b.EFR.l,5,9.1.5,10.6,3.5,10.6,2.7)
(b.bFR. 1.5,9.1.5.10.6,3,5,10.6,2.7,И), так как beFIRST(l,b)
(X.FR,1.5,9.1.5,10,6,3,5.10,6,2,7.11)
(X.R, 1,5,9.1,5,10.6,3,5.10,6,2.7.11.6), так как Xg FOLLOW(1,F)
(ХД, 1,5.9,1,5,10.6,3.5,10,6,2,7,11,6.2), так как XgFOLLOW(I.R), разбор закончен. Цепочка принимается.
Получили цепочку вывода:'
S n TR n EFR n (S)FR n (TR)FR n (EFR)FR n (aFR)FR n (aR)FR n (“TR)FR п (a+EFR)FR n (d+aFR)FR n (a+aR)FR n (a+a)FR n (a+a)*EFR n (a+a)*bFR п (a+a)*bR п (а+а)*Ь
Соответствующее ей дерево вывода приведено на рис. 4.6.
Рис. 4.6. Дерево вывода в И(1)-грамматике для цепочки «(а+а)*Ь»
Разбор цепочки а+а*:
(d+MS.入)
(a+a*,TR.l), так как aeFIRST(l,TR)
(a+a*,EFR,l,5), так как aeFlRST(l,EF)
(a+a*.aFR,l,5,lQ), так как awFIRST(l,a)
(+a*.FR,lt5,10)
(+a*,R,1,5,10.6), так как +gFOLLOW(1,F)
(+a*,+TR,1,5,10.6,3), так как +eFIRST(1,+TR)
(a*.TR.1.5.10.6,3)
(a*,EFR,1.5.10.6,3.5), так как awFIRST(l,EF)
(a*.aFR.1,5,10.6.3,5.10), так как awFIRST(l,a)
И. (*,FR,1,5,10,6,3,5,10)
(*.*EFR.1.5,10.6.3,5.10,7), так как *eFIRST(l,*EF)
(X,EFR.l,5.10,6,3.5.10,7)
Ошибка, так как 九eFOLLOW(LE), но нет правила вида Е -> X . Цепочка не принимается.
Разбор цепочки (+а)*Ь:
((+a)*b.SA)
((+a)*b,TR,l), так как (gFIRST(1,TR)
((+a)*b,EFR,1.5), так как (gFIRST(1,EF)
((+d)*b,(S)FR, 1,5,9), так как (gFIRST(1,(S))
(+a)*b.S)FR,1.5,9)
Ошибка, так как нет правил для S вида S -> а таких, чтобы +£FIRST(l,a) и + ^FOLLOW(l.S). Цепочка не принимается.
Из рассмотренных примеров видно, что алгоритму разбора цепочек, построенному на основе распознавателя для LL( 1 )-грамматик, требуется гораздо меньше шагов на принятие решения о принадлежности цепочки языку, чем рассмотренному выше алгоритму разбора с возвратами. Надо отметить, что оба алгоритма распознают цепочки одного и того же языка. Данный алгоритм имеет большую эффективность, поскольку при росте длины цепочки количество шагов его растет линейно, а не экспоненциально. Кроме того, ошибка обнаруживается этим алгоритмом сразу, в то время как разбор с возвратами будет просматривать для неверной входной цепочки возможные варианты до конца, пока не переберет их все.
Очевидно, что этот алгоритм является более эффективным, но жесткие ограничения на правила для ЬЬ(1)-грамматик сужают возможности его применения.
Восходящие распознаватели КС-языков без возвратов
Восходящие распознаватели выполняют построение дерева вывода снизу вверх. Результатом их работы является правосторонний вывод. Функционирование таких распознавателей основано на модификациях алгоритма «сдвиг-свертка» (или «перенос-свертка»), который был рассмотрен выше. При их создании применяются методы, которые позволяют однозначно выбрать между выполнением «сдвига» («переноса») или «свертки» на каждом шаге алгоритма, а при выполнении свертки однозначно выбрать правило, по которому будет производиться свертка.
кВ(к)-грамматики
Идея состоит в том, чтобы модифицировать алгоритм «сдвиг-свертка» таким образом, чтобы на каждом шаге его работы можно было однозначно дать ответ на следующие вопросы:
что следует выполнять: сдвиг (перенос) или свертку;
какую цепочку символов а выбрать из стека для выполнения свертки;
какое правило выбрать для выполнения свертки (в том случае, если существует несколько правил вида А( -> а, А2 -> а, ... Ап -> а).
Тогда восходящий алгоритм распознавания цепочек КС-языка не требовал бь выполнения возвратов. Конечно, как уже было сказано, это нельзя сделать в общем случае, для всех КС-языков. Но среди всех КС-языков можно выделить такие классы языков, для которых подобная реализация распознающего алгоритма возможна.
В первую очередь можно использовать тот же самый подход, который был положен в основу определения ЬЬ(к)-грамматик. Тогда мы получим другой класс КС-грамматик, который носит название LR(k)-грамматик.
КС-грамматика обладает свойством LR(k), к > 0, если на каждом шаге вывода для однозначного решения вопроса о выполняемом действии в алгоритме «сдвиг- свертка» («перенос-свертка») достаточно знать содержимое верхней части стека и рассмотреть первые к символов от текущего положения считывающей головки автомата во входной цепочке символов.
Грамматика называется ЬЯ(к)-грамматикой, если она обладает свойством LR(k) для некоторого к > О1.
Название «LR(k)>, как и рассмотренное выше《LL(k)», несет определенный смысл. Первая литера «L» обозначает порядок чтения входной цепочки символов: слева направо. Вторая литера «R» происходит от слова «right» и означает, что в результате работы распознавателя получается правосторонний вывод. Вместо 《к》в названии грамматики стоит число, которое показывает, сколько символов входной цепочки надо рассмотреть, чтобы принять решение о действии на каждом шаге алгоритма «сдвиг-свертка». Существуют ЬК(О)-грамматики, LR(1)- грамматики и другие классы.
В совокупности все ЬИ(к)-грамматики для всех к > 0 образуют класс LR-грамматик.
На рис. 4.7 схематично показано частичное дерево вывода для некоторой LR(k)- грамматики. В нем со обозначает уже разобранную часть входной цепочки а, на основе которой построена левая часть дерева у. Правая часть дерева х — это еще не разобранная часть, а А — это нетерминальный символ, к которому на очередном шаге будет свернута цепочка символов z( находящаяся на верхушке стека
Существование ЬК(О)-грамматик уже не является бессмыслицей, в отличие от LL(0)-грамматик. Расширенный МП-автомат анализирует несколько символов, находящихся на верхушке стека. Поэтому даже если при к = 0 автомат и не будет смотреть на текущий символ входной цепочки, построенный им вывод все равно будет зависеть от содержимого стека, а значит, и от содержимого входной цепочки.
МП-автомата. В эту цепочку уже входит прочитанная, но еще не разобранная часть входной цепочки и. Правая часть дерева х будет построена на основе части входной цепочки т. Свойство LR(k) предполагает, что однозначный выбор действия, выполняемого на каждом шаге алгоритма «сдвиг-свертка», может быть сделан на основе цепочки и и к первых символов цепочки т, являющихся частью входной цепочки а, Этим очередным действием может быть свертка цепочки z к символу А или перенос первого символа из цепочки т и добавление его к цепочке z.
Рис, 4.7. Схема построения дерева вывода для 1Н(к)-грамматики
Рассмотрев схему построения дерева вывода для ЬЯ(к)-грамматики на рис. 4.7 и сравнив ее с приведенной выше на рис. 4.4 схемой для ЬЬ(к)-грамматики, можно предположить, что класс LR-грамматик является более широким, чем класс LL-грамматик. Основанием для такого предположения служит тот факт, что на каждом шаге работы распознавателя ЬК(к)-грамматики обрабатывается больше информации, чем на шаге работы распознавателя ЬЬ(к)-грамматики. Действительно, для принятия решения на каждом шаге алгоритма распознавания ЬЬ(к)-грамматики используются первые к символов из цепочки иг, а для принятия решения на шаге распознавания LR(k)-rpaMMaTMKH — вся цепочка и и еще первые к символов из цепочки т. Очевидно, что во втором случае можно проанализировать больший объем информации и, таким образом, построить вывод для более широкого класса КС-языков.
Приведенное выше довольно нестрогое утверждение имеет строго обоснованное доказательство. Доказано, что класс LR-грамматик является более широким, чем класс LL-грамматик [4, т. 1]. То есть для каждого КС-языка, заданного LL-грамматикой, может быть построена LR-грамматика, задающая тот же язык, но не наоборот1.
Говоря о соотношении классов LL-грамматик и LR-грамматик, мы не затрагиваем вопрос о значениях к для этих грамматик. Если для некоторой ЬЬ(к)-грамматики всегда существует эквивалентная ей LR-грамматика, то это вовсе не значит, что она будет LR(k)-rpaM- матикой с тем же значением к. Но существуют LR-грамматики, для которых нет эквивалентных им LL-грамматик для всех возможных значений к > 0.
Для ЬК(к)-грамматик известны следующие полезные свойства:
всякая ЬК(к)-грамматика для любого к > 0 является однозначной;
существует алгоритм, позволяющий проверить, является ли заданная грамматика ЬК(к)-грамматикой для строго определенного числа к.
Есть, однако, неразрешимые проблемы для ЬК(к)-грамматик:
не существует алгоритма, который бы мог проверить, является ли заданная КС-грамматика ЬК(к)-грамматикой для некоторого произвольного числа к;
не существует алгоритма, который бы мог преобразовать (или доказать, что преобразование невозможно) произвольную КС-грамматику к виду LR(k)rpaM- матики для некоторого к.
Это общие проблемы, характерные для всех классов КС-грамматик.
Формальное определение ЬК(к)-свойства для КС-грамматик можно найти в [4. т. 1]. Оно основано на понятии пополненной КС-грамматики. Грамматика G' является пополненной грамматикой, построенной на основании исходной грамматики G(VT,VN,P(S), если выполняются следующие условия:
грамматика G' совпадает с грамматикой G, если целевой символ S не встречается нигде в правых частях правил грамматики G;
грамматика G1 строится как грамматика G'(VT,VNu{S'},Pu{S' -> S},S) если целевой символ S встречается в правой части хотя бы одного правила из множества Р в исходной грамматике G.
Фактически пополненная КС-грамматика строится таким образом, чтобы ее целевой символ не встречался в правой части ни одного правила. Если нужно, то в исходную грамматику G добавляется новый целевой символ S' и новое правило S' —> S. Очевидно, что пополненная грамматика G' эквивалентна исходной грамматике G.
Понятие «пополненная грамматика» введено, чтобы в процессе работы алгоритма «сдвиг-свертка» выполнение свертки к целевому символу S* служило сигналом к завершению алгоритма (поскольку в пополненной грамматике символ S' в правых частях правил не встречается). Поскольку построение пополненных грамматик выполняется элементарно и не накладывает никаких ограничений на исходную КС-грамматику, то дальше будем считать, что все распознаватели для ЬК(к)-грамматик работают с пополненными грамматиками.
Распознаватель для ЬК(к)-грамматик функционирует на основе управляющей таблицы Т. Эта таблица состоит из двух частей, называемых «Действия» и «Переходы^. По строкам таблицы распределены все цепочки символов на верхушке стека, которые могут приниматься во внимание в процессе работы распознавателя. По столбцам в части «Действия» распределены все части входной цепочки символов длиной не более к (аванцепочки), которые могут следовать за считывающей головкой автомата в процессе выполнения разбора; а в части «Переходы» —все терминальные и нетерминальные символы грамматики, которые могут появляться на верхушке стека автомата при выполнении действий (сдвигов или сверток).
Клетки управляющей таблицы Т в части «Действия» содержат следующие данные: □ 《сНб以2» — если в данной ситуации требуется выполнение сдвига (переноса текущего символа из входной цепочки в стек);
«успех» — если возможна свертка к целевому символу грамматики S, и разбор входной цепочки завершен;
целое число (《csep加&〃》)—если возможно выполнение свертки (целое число обозначает номер правила грамматики, по которому должна выполняться свертка);
«ошибкам — во всех других ситуациях.
Действия, выполняемые распознавателем, можно вычислять всякий раз на основе состояния стека и текущей аванцепочки. Однако этого вычисления можно избежать, если после выполнения действия сразу же определять, какая строка таблицы Т будет использована для выбора следующего действия. Тогда эту строку можно поместить в стек вместе с очередным символом и выбрать из стека в момент, когда она понадобится. Таким образом, автомат будет хранить в стеке не только символы алфавита, но и связанные с ними строки управляющей таблицы Т.
Клетки управляющей таблицы Т в части «Переходы» как раз и служат для выяснения номера строки таблицы, которая будет использована для определения выполняемого действия на очередном шаге. Эти клетки содержат следующие данные: □ целое число — номер строки таблицы Т;
«ошибкам — во всех других ситуациях.
Для удобства работы распознаватель ЬК(к)-грамматики использует также два специальных символа 1н и 丄к. Считается, что входная цепочка символов всегда начинается символом 丄н и завершается символом 丄к. Тогда в начальном состоянии работы распознавателя символ 丄н находится на верхушке стека, а считывающая головка обозревает первый символ входной цепочки. В конечном состоянии в стеке должны находиться символы S (целевой символ) и 丄н, а считывающая головка автомата должна обозревать символ 丄к.
Алгоритм функционирования распознавателя ЬК(к)-грамматики можно описать следующим образом:
Шаг 1. Поместить в стек символ 丄н и начальную (нулевую) строку управляющей таблицы Т. В конец входной цепочки поместить символ 丄氏 Перейти к шагу 2.
Шаг 2 Прочитать с вершины стека строку управляющей таблицы Т. Выбрать из этой строки часть «Действие» в соответствии с аванцепочкой, обозреваемой считывающей головкой автомата. Перейти к шагу 3.
Шаг 3. В соответствии с типом действия выполнить выбор из четырех вариантов:
ссдвиг» — если входная цепочка не прочитана до конца, прочитать и запомнить как «новый символ» очередной символ из входной цепочки, сдвинуть считывающую головку на одну позицию вправо, иначе прервать выполнение алгоритма и сообщить об ошибке;
целое число («свертка») — выбрать правило в соответствии с номером, удалить из стека цепочку символов, составляющую правую часть выбранного правила, взять символ из левой части правила и запомнить его как «новый символ»;
«ошибкам — прервать выполнение алгоритма, сообщить об ошибке;
《успех» — выполнить свертку к целевому символу S, прервать выполнение алгоритма, сообщить об успешном разборе входной цепочки символов, если входная цепочка прочитана до конца, иначе сообщить об ошибке.
Конец выбора. Перейти к шагу 4.
Шаг 4 Прочитать с вершины стека строку управляющей таблицы Т. Выбрать из этой строки часть «Переходы» в соответствии с символом, который был запомнен как «новый символ» на предыдущем шаге. Перейти к шагу 5.
Шаг 5. Если часть «Переходы» содержит вариант «ошибка», тогда прервать выполнение алгоритма и сообщить об ошибке, иначе (если там содержится номер строки управляющей таблицы Т) положить в стек «новый символ» и строку таблицы Т с выбранным номером. Вернуться к шагу 2.
Для работы алгоритма кроме управляющей таблицы Т используется также временная переменная («новый символ»), хранящая значение терминального или нетерминального символа. В программной реализации алгоритма вовсе не обязательно помещать в стек сами строки управляющей таблицы — поскольку таблица неизменна, достаточно запоминать соответствующие ссылки.
Доказано, что данный алгоритм имеет линейную зависимость необходимых для его выполнения вычислительных ресурсов от длины входной цепочки символов Следовательно, распознаватель для ЬК(к)-грамматики является линейным распознавателем.
На практике используются LR( 0) - грамматики и LR( 1 )-грамматики. LR(k)-rpaM- матики со значениями k > 1 практически не применяются. Это вызвано двумя причинами:
построение распознавателей для ЬК(к)-грамматик при k > 1 связано со значительными сложностями, а управляющая таблица Т имеет большой объем;
доказано, что для любого детерминированного КС-языка может быть построена LR( 1 )-грамматика, задающая этот язык, поэтому не имеет смысла использовать ЬЯ(к)-грамматики со значениями k > 1.
ВНИМАНИЕ
Класс языков, заданных LR( 1 )-грамматиками, полностью совпадает с классом детерминированных КС-языков.
То есть любая LR( 1 )-грамматика задает детерминированный КС-язык (это очевидно следует из однозначности всех LR-грамматик), и для любого детерминированного КС-языка можно построить LR( 1 )-грамматику, задающую этот язык. Второе утверждение уже не столь очевидно, но доказано в теории формальных языков [4, т. 1].
ПРИМЕЧАНИЕ
Класс ЬИ(1)-грамматик мог бы быть универсальным для построения синтаксических распознавателей, если бы была разрешима проблема преобразования для КС-грамматик.
Синтаксические конструкции всех языков программирования относятся к классу детерминированных КС-языков. Но детерминированный КС-язык может быть задан грамматикой, которая не относится к классу ЬЯ(1)-грамматик. В таком случае совсем не очевидно, что для этого языка удастся построить распознаватель на основе LR( 1 )-грамматики, потому что в общем случае нет алгоритма, который бы позволил эту грамматику получить, хотя и известно, что она существует. То, что проблема не разрешима в общем случае, совсем не означает, что ее не удастся решить в конкретной ситуации. Факт существования LR (1)-грамма- тики для каждого детерминированного КС-языка играет важную роль — всегда есть смысл попытаться построить такую грамматику.
Синтаксический разбор для ЬН(0)-грамматик
Построение управляющей таблицы для кН(О)-грамматик
Простейшим случаем ЬЯ(к)-грамматик являются ЬК(О)-грамматики. При к = О распознающий расширенный МП-автомат совсем не принимает во внимание текущий символ, обозреваемый считывающей головкой. Решение о выполняемом действии принимается только на основании содержимого стека автомата. При этом не должно возникать конфликтов между выполняемым действием (сдвиг или свертка), а также между различными вариантами при выполнении свертки. Для построения управляющей таблицы Т заданной ЬЯ(О)-грамматики введем понятие последовательности ситуаций.
Ситуация представляет собой множество правил КС-грамматики, записанных с учетом положения считывающей головки МП-автомата, которое может возникнуть в процессе выполнения разбора сентенциальной формы этой грамматики. Положение считывающей головки автомата обозначается в левой части правила А —> а, где ae(VTuVN)* специальным символом •, который может стоять в произвольном месте цепочки a: a = у・0 (причем любая из цепочек у и 0 или обе эти цепочки могут быть пустыми). Этот символ не входит в алфавит грамматики (он не является ни терминальным, ни нетерминальным символом).
Если S — целевой символ грамматики G, и правила S —> а〔 | а? |...| ап входят во множество правил этой грамматики, то ситуация, содержащая множество правил {S —> ・ad S —> «а2； ... S —> ・ап}, называется начальной ситуацией. Смысл начальной ситуации очевиден: считывающая головка распознающего МП-автомата находится в начале одной из возможных сентенциальных форм грамматики.
Последовательность ситуаций строится по определенным правилам, начиная от начальной ситуации. Правила построения последовательности ситуаций следующие: □ если ситуация содержит правило вида А -> у・В0, где A,BwVN, %0£(VNuVT)* и при этом правила В -> at | а2 |...| аП1 входят во множество правил грамматики, то правила вида В —> «а^ В —> *а2； ... В —> «а1П должны быть добавлены в ситуацию;
если ситуация содержит правила вида А -> у・х0, где AwVN, y,0£(VNuVT)\ а х - произвольный символ (xeVNuVT), то из нее может быть построена новая ситуация, содержащая правила вида А -> ух・0, при этом новая ситуация должна проистекать из исходной ситуации на основании символа х.
Ситуации, проистекающие друг из друга на основании различных символов, образуют последовательность ситуаций. Последовательность ситуаций может быть изображена в виде графа взаимосвязи ситуаций, вершины которого соответствуют ситуациям, а дуги — взаимосвязям между ситуациями. Дуги графа взаимосвязи ситуаций будут помечены терминальными и нетерминальными символами грамматики, по которым ситуации связаны между собой.
Поскольку количество правил грамматики конечно, то конечно и количество их комбинаций с символом •. Следовательно, конечно и множество всех возможных подмножеств таких комбинаций, то есть и количество возможных ситуаций также конечно. Поэтому последовательность ситуаций всегда может быть построена и никогда не будет бесконечной.
Обозначим все ситуации в последовательности ситуаций R” где i — номер ситуации от 0 до N - 1 (где N — общее количество ситуаций в последовательности). Тогда начальная ситуация будет обозначаться Ro.
После построения последовательности ситуаций на ее основе строится управляющая таблица Т. Построение таблицы происходит следующим образом:
количество строк в таблице Т соответствует количеству N ситуаций R в последовательности ситуаций, причем каждой строке "Ц в таблице Т соответствует ситуация R】в последовательности ситуаций;
для всех ситуаций в последовательности от Ro до RN.] выполняется следующее:
Q если ситуация R( содержит правило вида S -> у・,yw(VNuVT)*, где S — целевой символ грамматики, то в графе «Действия» строки Т( таблицы Т должно быть записано《успех»;
Q если ситуация R】 содержит правило вида А — у», где AwVN, yw(VNuVT)\ А не является целевым символом и грамматика содержит правило вида А —> у с номером 加，то в графе «Действия» строки Tt таблицы Т должно быть записано число т {свертка по правилу с номером 加)；
Q если ситуация R】 содержит правила вида А -> у«хр, где AwVN, а х ~ произвольный символ (xgVNuVT), YjpeCVNuVT)*, то в графе «Действия» строки Т] таблицы Т должно быть записано «сдвигу
О если ситуация R)проистекает из ситуации R)и связана с нею через символ х (xeVNuVT), то в графе «Переходы», соответствующей символу х, строки Т, таблицы Т должно быть записано число;;
клетки таблицы, оставшиеся пустыми после заполнения таблицы Т на основании последовательности ситуаций, соответствуют состоянию ошибкам.
Если удается непротиворечивым образом заполнить управляющую таблицу Т на основании последовательности ситуаций по описанным выше правилам, то рассматриваемая грамматика является ЬИ(0)-грамматикой. Иначе, когда при заполнении таблицы возникают противоречия, грамматика не является LR(0)-rpaM- матикой, и для нее нельзя построить распознаватель типа LR(O) [4, т. 1, 13, 50].
Пример построения распознавателя для 1Н(0)-грамматики
Рассмотрим КС-грамматику G({a,b).{S}.{S -> aSS | b) ,S). Пополненная грамматика для нее будет иметь вид: G' ({a.b}, {S.S1} - {S' — S.S — aSS | b}.S').
Построим последовательность ситуаций для грамматики G'.
Начальная ситуация R0 будет содержать правило S' -> «Sf но в нее также должны быть включены правила S -> «aSS и S -> «Ь, поскольку в грамматике для символа S есть правила S —> aSS | Ь. Получим ситуацию RO = {S' —> «S.S —> «aSS.S —> ・b}.
Из начальной ситуации R0 по символу S можно получить ситуацию R1, содержащую правило S' -> S«. Других правил в нее не может быть добавлено, поэтому получаем RI = {S' -> S・}.
Из начальной ситуации R0 по символу а можно получить ситуацию R2, содержащую правило S ->а ・SS, но в нее также должны быть включены правила S -> «aSS и S -> ・b, поскольку в грамматике для символа S есть правила S -> aSS | Ь. Получаем R2 = {$ -> a«SS,S — «aSS.S -> ・b}.
Из начальной ситуации R0 по символу b можно получить ситуацию R3, содержащую правило S -> Ь・.Других правил в нее не может быть добавлено, поэтому по* лучаем R3 = {S Ь・}. -
Из ситуации R2 по символу S можно получить ситуацию R4, содержащую правило S ->aS ・S, но в нее также должны быть включены правила S -> *aSS и S -> «Ь, поскольку в грамматике для символа S есть правила S -> aSS | Ь. Получаем R4 = ={S -> dS・S,S -> «aSS.S —・b}・
Из ситуации R4 по символу S можно получить ситуацию R5, содержащую правило S -> aSS*. Других правил в нее не может быть добавлено, поэтому получаем R5 = {S aSS・}.
Из ситуации R2 по символу а можно получить ситуацию R6, содержащую правило S ->а ・SS, но в нее также должны быть включены правила S -> *aSS и S -> «Ь, поскольку в грамматике для символа S есть правила S -> aSS | Ь. Получаем R6 = ={S ->а ・SS, S —> ・aSS, S -> *b}. Можно заметить, что эта ситуация совпадает с ситуацией R2: R6 = R2.
Из ситуации R2 по символу b можно получить ситуацию R7, содержащую правило S ->Ь •. Других правил в нее не может быть добавлено, поэтому получаем R7 = ={S ->Ь •}・ Можно заметить, что эта ситуация совпадает с ситуацией R3: R7 = R3. Из ситуации R4 по символу а можно получить ситуацию R8, содержащую правило S ->а ・SS, но в нее также должны быть включены правила S -> ・dSS и S -> «Ь, поскольку в грамматике для символа S есть правила S -> aSS | Ь. Получаем R8 ^ ={S та ・SS,S -> «aSS.S -> ・b}. Можно заметить, что эта ситуация совпадает с ситуацией R2: R8= R2.
Из ситуации R4 по символу b можно получить ситуацию R9, содержащую правило S ->Ь •. Других правил в нее не может быть добавлено, поэтому получаем R9 = ={S ->Ь •}. Можно заметить, что эта ситуация совпадает с ситуацией R3: R9 = R3.
Всего получилось 6 различных ситуаций от R0 до R5. Граф взаимосвязи ситуаций показан на рис. 4.8.
На основе найденной последовательности ситуаций можно построить управляющую таблицу распознавателя для ЬИ(О)-грамматики. Поскольку при построении управляющей таблицы не возникает противоречий, то рассмотренная грамматика является LR(0)-грамматикой. Управляющая таблица для нее приведена в табл. 4.2.
Рис. 4.8. Пример графа взаимосвязи ситуаций для 1В(0)-грамматики
Таблица 4.2. Пример управляющей таблицы для ЬВ(О)-грамматики
№
Стек
Действия
Переходы
Sа
b
0
丄н
сдвиг
12
3
1
S
успех, 1
2
a
сдвиг
42
3
3
b
свертка, 3
4
aS
сдвиг
52
3
5
aSS
свертка, 2
Колонка «Стек», присутствующая в таблице, не нужна для распознавателя. Она введена для пояснения состояния стека автомата. Правила грамматики пронумерованы от 1 до 3. Распознаватель работает невзирая на текущий символ, обозреваемый считывающей головкой расширенного МП-автомата, поэтому колонка «Действия» в таблице имеет один столбец, не помеченный никаким символом. Рассмотрим примеры распознавания цепочек языка, заданного этой грамматикой. Конфигурацию расширенного МП-автомата будем отображать в виде трех компонентов: непрочитанная часть входной цепочки символов, содержимое стека МП-автомата( последовательность номеров примененных правил грамматики (поскольку автомат имеет только одно состояние, его можно не учитывать). В стеке МП-автомата вместе с помещенными туда символами показаны и номера строк управляющей таблицы, соответствующие этим символам в формате {символ, номер строки}.
Разбор цепочки_аЬаЬаЬЬ:
(аЬаЬаЬЬ1к.{1н.О)А)
(bdbabb丄к, {丄H,0}{d,2},九)
(dbdbb丄к,{丄н,0}{а,2}{Ь,3}4)
(ababblK.{lH,0}{a,2}{S.4},3)
(babb±K,{lH.0}{a.2}{S,4}{a,2},3)
(abb丄к,{丄H,0}{d,2}{S,4}{d,2}{b,3},3)
(abb丄к,{丄H,0}{a,2}{S,4}{a,2}{S,4}.3,3)
(bb丄к.{丄H,0}{d,2}{S,4}{d,2}{S,4}{a,2},3,3)
(b丄к, {丄H,0}{a,2}{S,4}{a,2}{S,4}{a,2}{b,3},3,3)
(b丄к,{丄H,0}{a,2}{S,4}{a,2}{S,4}{a,2}{S,4},3,3,3)
(lK,{lH,0}{a.2}{S,4}{a,2}{S.4}{a,2}{S,4}{b,3},3,3.3)
(丄к, {丄H,0}{d,2}{S,4}{d,2}{S,4}{d,2}{S,4}{S,5},3,3,3,3)
13•(丄к, {丄 H,0}{a,2}{S.4}{d,2}{S,4}{S,5},3,3,3,3,2)
(丄 к, {丄 H,0}{a,2}{S,4}{S,5},3,3,3,3,2,2)
(丄к,{丄h,0}{S,1},3,3,3,3,2,2,2)
(丄к, {丄н,0}{S' ,*} 33,3,322,2,1) — разбор завершен.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S' => S => aSS => aSaSS => aSaSaSS => aSaSaSb n aSaSabb => aSababb => abababb.
Разбор цепочки aabbb:
(dabbb丄к,{丄н,0},九)
(abbb丄к,{丄н,0}{а,2},А)
(bbblK.{±H,0}{a.2}{a,2}A)
(bb丄к,{丄H,0}{a,2}{d,2}{b,3},入)
(比丄к,{丄H,0}{a,2}{d,2}{S,4},3)
(b±K,{lH,0}{a.2}{a.2}{S,4}{b,3},3)
(b±K.{lH,0}{a.2}{a,2}{S.4}{S,5}.3.3)
(blK,{±H.0}{a.2}{S,4}.3,3.2)
(丄к,{丄n,0}{a,2}{S,4}{b,3},3,3,2)
(丄к,{丄h,0}{g,2}{S,4}{S,5},3,3,2,3)
(1k,{1h.0}{S.1},3.3,2.3,2)
(丄 к, {丄 h,O}{S',*} ,3,3,2,3,2,1) — разбор завершен.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S' => S ==> aSS => aSb => aaSSb n aaSbb => aabbb.
Разбор цепочки aabb:
(aabb±K.{±H,O}A)
(abb丄к,{丄н,0}{а,2}4)
(bb丄к,{丄H,0}{d,2}{a,2},入)
(b丄к,{丄H,0}{d,2}{a.2}{b,3},九)
(blK,{lH.0}{a,2}{a.2}{S.4},3)
(lK,{lH.0}{a,2}{a,2}{S.4}{b,3}.3)
(丄к,{丄H,0}{d,2}{d,2}{S,4}{S,5},3,3)
(丄к,{丄H,0}{a,2}{S,4},3,3,2)
ошибка, невозможно выполнить сдвиг.
Распознаватель для ЬК(О)-грамматики достаточно прост. Приведенный выше пример можно сравнить с методом рекурсивного спуска или с распознавателем для LL( 1 )-грамматики — оба эти метода применимы к описанной выше грамматике. По количеству шагов работы распознавателя эти методы сопоставимы, но по реализации нисходящие распознаватели в данном случае немного проще.
Ограничения ЬЯ(О)-грамматик
Управляющая таблица Т для ЬЯ(О)-грамматики строится на основании понятия «левых контекстов» нетерминальных символов: после выполнения свертки для нетерминального символа А в стеке МП-автомата ниже этого символа будут располагаться только те символы, которые могут встречаться в цепочке вывода слева от А. Эти символы и составляют «левый контекст» для А. Поскольку выбор между сдвигом или сверткой, а также между типом свертки в ЬИ(О)-граммати- ках выполняется только на основании содержимого стека, то ЬИ(О)-грамматика должна допускать однозначный выбор на основе левого контекста для каждого символа [4, т. 2].
Однако класс ЬИ(О)-грамматик сильно ограничен, поскольку существует очень мало грамматик, позволяющих выполнять разбор на основании только левого контекста.
Рассмотрим КС-грамматику G({a.b},{S}.{S -> SaSb | 入}・S)・ Пополненная грамматика для нее будет иметь вид G' ({a.b}.{s-s，}- {S' -> S.S -> SaSb | 入},S) Начнем построение последовательности ситуаций для грамматики G'.
Начальная ситуация R0 будет содержать правило S'—> ・S, но в нее также должны быть включены правила S -> ・SaSb и S -> •, поскольку в грамматике для символа S есть правила S -> SaSb | 入(в правиле S -> • пустое место соответствует пустой цепочке 儿 и это правило в равной степени можно рассматривать как S -> «X или S -> 入・).Получим ситуацию RO = {S' — ・S,S -> ・SdSb,S -> •}.
При построении управляющей таблицы Т для этой грамматики уже на шаге для ситуации R0 возникнут противоречия: с одной стороны, ситуация содержит правило S -> •, и для нее в управляющей таблице в графе «Действия» должно быть записано ^свертка^ с номером правила 3: S -> X (правила в грамматике пронумерованы последовательно от 0 до 3); но с другой стороны, ситуация содержит правила S* -> *S и S -> «SaSb, поэтому для нее в той же графе «Действия» должно быть записано «сдвиг». Возникшее противоречие говорит о том, что рассматриваемая грамматика не является ЬК(0)-грамматикой, для нее невозможно выполнить разбор входной цепочки только на основании левого контекста.
ВНИМАНИЕ
Очевидно, что любая грамматика, содержащая Х-правила, не может быть LR(O)- грамматикой.
Можно попытаться выполнить преобразования (например, исключить Х-правила), чтобы привести грамматику к виду ЬН(О)-грамматики, но это не всегда возможно.
В тех случаях, когда невозможно построить восходящий распознаватель на основе использования только левого контекста, для построения распознавателя используется не только левый, но и правый контекст. Правым контекстом является символ входной цепочки, обозреваемый считывающей головкой расширенного МП-автомата. В этом случае мы получаем распознаватель на основе LR(^-грамматики1.
Синтаксический разбор для LR⑴-грамматик
Построение управляющей таблицы для LR(1 )-грамматики
Как и для ЬК(О)-грамматик, управляющую таблицу Т для ЬИ(1)-грамматик можно построить на основании последовательности ситуаций [4, т. 2]. Однако ситуация для LR( 1 )-грамматики имеет более сложную форму, чем для ЬИ(О)-грамматики. Правило в ситуации для LR( 1 )-грамматики должно иметь вид: А -> у・В/а, где AeVN, Y,pe(VNuVT)*} aeVT. Символ •, а также цепочки у и В имеют тот же смысл, что и для ЬИ(О)-грамматик, а символ aw VT определяет правый контекст.
Начальная ситуация в последовательности ситуаций для LR( 1 )-грамматики должна содержать правила {S -> ・а[/丄内 S -> ・。2/丄夕••• S -> ・0^/丄к}，если правила S -> at I a21...| an входят в множество правил этой грамматики, а символ S является целевым символом. Символ 1К обозначает символ конца входной цепочки.
Правила построения последовательности ситуаций для LR( 1)-грамматики следующие:
если ситуация содержит правило вида А -> у«ВЬр/а, где A,BwVN, a,bwVT, ytpe(VNuVT)*f и при этом правила В -> a] | a2 |..,| ат входят во множество правил грамматики, то правила вида В -> ・a[/b; В -> «а2/Ь;... В -> •ащ/Ь должны быть добавлены в ситуацию;
если ситуация содержит правило вида А -> у・В/а, где A,BwVN, aeVT, ye(VNu VT)*, и при этом правила В -> at | а21...| а1П входят во множество правил грамматики, то правила вида В -> ・а[/а; В -> «а2/а;... В -> «ат/а должны быть добавлены в ситуацию;
если ситуация содержит правило вида А -> у・ВС0/а, где A,B,CwVN, a,beVT, y(pe(VNuVT)*, и при этом правила В -> a! | a2 |...| ат входят во множество правил грамматики, тогда VcwVT, таких, что ceFIRST(l,C)t правила вида В -> ・ai/c; В -> *а2/с; ... В -> «ат/с должны быть добавлены в ситуацию;
Как уже было сказано выше, распознаватели для ЬИ(к)-грамматик с k > 1 практически не используются.
если ситуация содержит правила вида А -> у«хр/а, где AeVN, awVT, а х - произвольный символ (xeVNuVT), y,pe(VNuVT)*, то из нее может быть построена новая ситуация, содержащая правила вида А -> ух«р/а, при этом новау ситуация должна проистекать из исходной ситуации на основании символа х
Здесь FIRST(1,C) обозначает множество первых символов для нетерминальногс символа CeVN. Построение этого множества было рассмотрено выше в разделе посвященном нисходящим распознавателям.
Очевидно, что поскольку правила в ситуациях LR( 1 )-грамматики учитывают еще и правый контекст, то общее количество возможных ситуаций в ЬИ(1)-грамма- тике будет существенно больше, чем количество ситуаций в LR(0)-грамматике Управляющая таблица Т для распознавателя на основе LR( 1 )-грамматики строится на основе последовательности ситуаций так же, как и для ЬИ(О)-грамматики, с учетом того, что графа «Действия» в этой таблице разбита на несколько подграф пс количеству возможных терминальных символов, каждая из которых соответствует определенному символу правого контекста. Для всех ситуаций в последовательности от Ro до RN1 с учетом правого контекста выполняются следующие действия: □ если ситуация R, содержит правило вида S -> у«/а, yw(VNuVT)*, aeVT, где
S — целевой символ грамматики, то в графе «Действия» строки Т】таблицы Т для символа о должно быть записано «успех»;
если ситуация R】 содержит правило вида А -> у・/а, где AwVN, ye(VNuVT)' aeVT, А не является целевым символом и грамматика содержит правило вида А -> у с номером 加，то в графе «Действия» строки Т】таблицы Т для символа а должно быть записано число т {свертка по правилу с номером 加)；
если ситуация R, содержит правила вида А -> у・хр/а, где AwVN, aeVT, а х - произвольный символ (xeVNuVT), y,pe(VNuVT)*, то в графе «Действия» строки Т] таблицы Т для символа а должно быть записано《сНб〃2》；
если ситуация Rj проистекает из ситуации R】и связана с нею через символ х (xeVNuVT), то в графе «Переходы», соответствующей символу х, строки Т таблицы Т должно быть записано число j.
Если удается непротиворечивым образом заполнить управляющую таблицу Т на основании последовательности ситуаций по описанным выше правилам, то рассматриваемая грамматика является ЬК(1)-грамматикой. Иначе, когда при заполнении таблицы возникают противоречия, грамматика не является LR(1 ^-грамматикой, и для нее нельзя построить распознаватель типа LR(1) [4, т. 1, 2].
Пример построения распознавателя для LR(1 )-грамматики
Возьмем КС-грамматику G({a.b}, {S}, {S -> SaSb | 入},S), которая уже рассматривалась вытпе. Пополненная грамматика для нее будет иметь вид G' ({d, b}, {S, S'}, {S'-> S.S f SaSb I 入}S).
Построим последовательность ситуаций для грамматики G'.
Начальная ситуация R0 будет содержать правило S'-> ・S/丄к, но в нее также должны быть включены правила S -» «SaSb/±K и S —> •/上к, поскольку в грамматике для символа S есть правила S -> SaSb | 入,а затем на основании правила S ->
•SdSb/丄к еще и правила S -» «SaSb/a и Sf/а. Получим ситуацию R0={S' -» •S/丄 k,S — «SaSb/lK.S — •/丄 k,S —・SaSb/d,S — «/a).
Из начальной ситуации RO по символу S можно получить ситуацию R1, содержащую правила S' -> S•/丄к, S -> S・aSb/丄к и S -» S«aSb/a. Других правил в нее не может быть добавлено, поэтому получаем RI = (S' -> S•/丄k,S ->*S・aSb/丄k,S -> S・aSb/d}. Из ситуации RI по символу а можно получить ситуацию R2, содержащую правила S ->Sa ・Sb/丄к и S ->Sa «Sb/а, но в нее также должны быть включены правила S -> •SaSb/b и S -> •/> поскольку в грамматике для символа S есть правила S -> SaSb | 儿 а затем на основании правила S -> • SaSb/b еще и правила S -> ・SdSb/d и S -> «/а. Получим ситуацию R2 = {S -> Sa«Sb/±K,S -> Sa«Sb/a,S -> ・SdSb/b,S -> ・/b,S -> •SaSb/a,S — «/a).
Продолжив построения, получим 8 различных ситуаций от R0 до R7, граф взаимосвязи которых показан на рис. 4.9.
•5b•5b•5bb'5ba a a a / a / s s s • s • 三三 s s s s s s•5b•5b•5bb'5ba a a a / a / s s s • s • 三三 s s s s s sRe- S—► SaS*b / b S-^SaS・b/a S-^S・aSb/b S"^S・aSb/aRe- S—► SaS*b / b S-^SaS・b/a S-^S・aSb/b S"^S・aSb/aRo: S'-^・S/丄 S-^Sa・Sb /1 S->■/丄 S->Sa«Sb/a S—>・/a
•5b•5b•5bb'5ba a a a / a / s s s • s • 三三 s s s s s s
•5b•5b•5bb'5ba a a a / a / s s s • s • 三三 s s s s s s
Re- S—► SaS*b / b S-^SaS・b/a S-^S・aSb/b S"^S・aSb/a
Re- S—► SaS*b / b S-^SaS・b/a S-^S・aSb/b S"^S・aSb/a
R7： S-^SaSb・/b S―► SaSb •/ a
Рис. 4.9. Пример графа взаимосвязи ситуаций для 1В(1)-грамматики
На основе найденной последовательности ситуаций можно построить управляющую таблицу распознавателя для LR( 1 )-грамматики. Поскольку при построенш управляющей таблицы не возникает противоречий, то рассмотренная грамматики является LR( 1 )-грамматикой. Управляющая таблица для нее приведена в табл. 4.3.
Таблица 4.3. Пример управляющей таблицы для LR( 1 )-грамматики
№
Стек
Действия
Переходы
a
ь1к
а
bS
0
丄н
свертка, 3
свертка, 3
1
1
S
сдвиг
успех, 1
2
2
Sa
свертка, 3
свертка, 3
3
3
SaS
сдвиг
сдвиг
4
5
4
SaSa
свертка, 3
свертка, 3
6
5
SaSb
свертка, 2
свертка, 2
6
SaSaS
сдвиг
сдвиг
4
7
7
SaSaSb
свертка, 2
свертка, 2
Колонка «Стек», присутствующая в таблице, не нужна для распознавателя. Она введена для пояснения состояния стека автомата. Пустые клетки в таблице соответствуют состоянию《ошибка». Правила грамматики пронумерованы от 1 до 3 Колонка «Действия» в таблице содержит перечень действий, соответствующих текущему входному символу, обозреваемому считывающей головкой расширенного МП-автомата.
Рассмотрим примеры распознавания цепочек языка, заданного этой грамматикой. Конфигурацию расширенного МП-автомата будем отображать в виде трех компонентов, как это было сделано для ЬК(О)-грамматик.
Разбор цепочки abababb:
(аЬаЬаЬЫк,{1н,0}А)
(abababblK,{lH,0}{S,l},3)
(bababb丄к.{丄H,0}{SJ}{a,2},3)
(bababb±K.{±H.0}{Sll}{a,2}{Sl3},3(3)
(ababb丄к,{丄H,0}{S」}{a,2}{S,3}{b,5},3,3)
QMbb丄к.{丄h,0}{SJ},3,3.2)
(babb丄к,{丄H,0}{S」}{a,2},3,3,2)
(babblK.{lH,0}{S,l}{a.2}{S,3},3.3,2.3)
(abblK,{lHt0}{S,l}{a.2}{S.3}{b,5},3,3.2.3)
(abblK,{±H.0}{S,l},3l3.2.3.2)
IL (bb丄七{丄H,0}{S,l}{a,2},3,3,2,3.2)
(bb丄к,{丄H,0}{S」}{a,2}{S,3},3.3,2,3,2,3)
(blK,{±H,0}{S,l}{a.2}{S,3}{b,5},3,3,2.3.2,3)
ошибка, нет данных для b в строке 5.
Разбор цепочки aababb:
(aababblK,{±H,O}А)
(ddbabb丄к,{丄h.0}{S,1},3)
(ababblK,{lH,0}{S,l}{a,2},3)，
(ababb丄к,{丄H,0}{S,l}{d,2}{S,3},3,3)
(babblK,{lH,0}{S,l}{a,2}{S.3}{a.4}.3,3)
(babblK,{J-H,0}{S,l}{al2}{S,3}{a,4}{S,6},3,3,3)
(abblK,{±H,0}{S,l){a,2}{S,3}{a,4}{S,6}{b,7},3,3,3)
(abb丄к, {丄H,0}{S」}{a,2}{S,3},3,3,3,2)
(bblK.{lH.O}{S.l}{a,2}{S,3}{a.4},3.3.3.2)
(bb丄к,{丄H,0}{S」}{a,2}{S,3}{a,4}{S,6},3,3,3,2,3)
IL (b丄к,{丄H,0}{S」}{d,2}{S,3}{a,4}{S,6}{b,7}.3,3,3,2,3)
(b 丄 к, {丄 H,0}{S」}{a,2}{S,3}.3,3,3,2,3,2)
(丄к,{丄H,0}{S,l}{a,2}{S.3}{b,5}.3,3,3,2,3,2)
(丄丸{丄h,0}{S,1},3.3,3,2,3,2,2)
(丄к,{丄h,0}{S' ,*},3,3,3.2,3,2,2,1) — разбор завершен.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S' => S => SaSb n SaSaSbb n SaSabb => SaSaSbabb n SaSababb n Saababb n aababb.
Сложности построения LR(1 )-распознавателей
Класс языков, заданных LR( 1 )-грамматиками, является самым широким классом КС-языков, допускающим построение линейного восходящего распознавателя. Все детерминированные КС-языки могут быть заданы с помощью LR(1)- грамматик. Однако не всякая однозначная КС-грамматика является LR( ^-грамматикой. И если язык задан грамматикой, не являющейся LR( 1 )-грамматикой, то в общем случае не существует алгоритма преобразования ее к виду LR(1).
Это проблема общая для всех КС-грамматик. Но для ЬИ(1)-грамматик можно с уверенностью сказать, что если не удалось преобразовать произвольную КС- грамматику к виду LR( 1 )-грамматики, то нет большого смысла пытаться преобразовать ее к виду ЬК(к)-грамматики с k > 1.
Дело в том, что даже для ЬИ(1)-грамматик управляющая таблица распознавателя имеет значительный объем, а для ее построения необходимо рассмотреть большое количество взаимосвязанных ситуаций. В общем случае задача имеет комбинаторную сложность, и для реальной LR( 1 )-грамматики, содержащей несколько десятков правил и несколько десятков терминальных символов, множество рассматриваемых ситуаций будет достаточно велико (сотни возможных ситуаций плюс все взаимосвязи между ними). Сложность построения управляющих таблиц для LR(k)-rpaMMaTHK при k > 1 будет увеличиваться с ростом к в геометрической прогрессии пропорционально количеству терминальных символов грамматики. Поэтому ЬК(к)-грамматики с k > 1 практического применения не имеют.
Например, неоднократно рассмотренная выше грамматика арифметических выражений для символов aHbG({+,-,/,*.a,b},{S,,S,T.E},P,S,):
Р:
S' - S
S S+T I I т
T -> T*E I T/E I E
E -> (S) I a I b
является LR( 1 )-грамматикой, но последовательность ситуаций для нее слишком велика, чтобы ее можно было проиллюстрировать в данном учебном пособии (желающие могут построить последовательность ситуаций и управляющую таблиш для данной грамматики, используя приведенный выше алгоритм).
Высокая трудоемкость построения управляющей таблицы для LR( 1 )-грамматик послужила причиной тому, что для реализации линейных восходящих распознавателей на основе алгоритма «сдвиг-свертка» были предложены другие классы грамматик, такие как 5ЬК(к)-грамматики и LALR(k )-грамматики, грамматики предшествования, грамматики с ограниченным правым контекстом (ОПК) и другие. Не все из этих классов КС-грамматик определяют столь Широкий класс КС- языков, как LR( 1 )-грамматики, но многие из них очень удобны и практичны для построения лексических анализаторов.
Далее в этой главе будут рассмотрены еще два класса КС-грамматик — SLR (1)- грамматики и ЕАЬИ(1)-грамматики, являющиеся незначительной модификацией LR( 1 )-грамматик. Отдельная глава посвящена грамматикам предшествования. Остальные грамматики из всего множества классов КС-грамматик в данном учебном пособии не рассматриваются, их можно найти в [4, т. 2].
SLR(1)- и LALR⑴-「рамматмкм
Распознаватели для обоих этих классов грамматик представляют собой модификацию распознавателя для ЬК(1)-грамматик.
Синтаксический разбор для SLR(1 )-грамматик
Идея распознавателей для 5ЬИ(к)-грамматик заключается в том, чтобы сократить множество рассматриваемых ситуаций и упростить построение управляющей таблицы Т. Ведь увеличение количества рассматриваемых ситуаций в LR( 1 )-грамматике по сравнению с ЬИ(0)-грамматикой происходит из-за того, что в каждом правиле для каждой ситуации учитывается правый контекст. В то же время реально рассматривать правый контекст необходимо не во всех ситуациях, а только в тех, где возникают конфликты в алгоритме построения таблицы Т.
Все 5ЬК(к)-грамматики для всех k > 1 образуют класс SLR-грамматик (k > 1. поскольку 5ЬИ(0)-грамматика совпадает по определению с ЬК(О)-грамматикой) Название SLR-грамматик происходит из самой идеи их построения — SLR означает «Simple LR», то есть упрощенные LR-грамматики.
В распознавателях на основе 5ЬК(к)-грамматик построение управляющей таблицы Т выполняется следующим образом:
строится последовательность ситуаций, соответствующая ЬИ(О)-грамматике;
на основе построенной последовательности ситуаций заполняется управляющая таблица Т, причем если при заполнении таблицы возникают конфликты, то для их разрешения используются правый контекст длиной к и множества символов FIRST(k,a) и FOLLOW(k,A ) для правил вида А->а.
Здесь множества FIRST(k.a) и FOLLOW(k,A) представляют собой соответственно множество к первых терминальных символов цепочки вывода из а и к первых терминальных символов, которые могут следовать в цепочках вывода за символом А. Эти множества были определены выше в разделе, посвященном LL( 1 )-грамматикам.
На практике чаще всего применяются SLR( 1 )-грамматики, поскольку для них построение множеств символов FIRST(l,a) и FOLLOW(1,A) выполняется элементарно просто.
Управляющая таблица Т для распознавателя на основе SLR( 1 )-грамматики строится на основе последовательности ситуаций так же, как и для ЬИ(О)-граммати- ки, но графа «Действия» в этой таблице разбита на несколько подграф по количеству возможных терминальных символов, аналогично LR( 1 )-грамматике. Для всех ситуаций в последовательности от Ro до RN.i с учетом правого контекста выполняются следующие действия:
если ситуация R】 содержит правило вида S —> у・,yg(VNoVT)\ где S — целевой символ грамматики, то в графе «Действия» строки Tt таблицы Т должно быть записано «успеха для всех символов ggFOLLOW(1,S) — фактически, таким символом является символ конца строки 丄工
если ситуация R, содержит правило вида А —> у*, где AgVN, yE(VNuVT)*, А не является целевым символом и грамматика содержит правило вида А->у с номером т, то в графе «Действия» строки Т, таблицы Т должно быть записано число т (свертка по правилу с номером 加)для всех символов ag FOLLOW(1,А)；
если ситуация R】 содержит правила вида А —> у・х0, где AgVN, ах- произвольный символ (xgVNuVT), yfpG(VNoVT)\ то в графе «Действия» строки Т, таблицы Т должно быть записано ^сдвиг^ для всех символов ggFIRS^^x)1;
если ситуация R〕проистекает из ситуации R】и связана с нею через символ х (xgVNoVT), то в графе «Переходы», соответствующей символу х, строки Tv таблицы Т должно быть записано число/
Если удается непротиворечивым образом заполнить управляющую таблицу Т на основании последовательности ситуаций по описанным выше правилам, то рассматриваемая грамматика является SLR( 1 )-грамматикой. Иначе, когда при заполнении таблицы возникают противоречия, грамматика не является SLR(l)-rpaM- матикой и для нее нельзя построить распознаватель типа SLR(l) [4, т. 2].
'Напоминаем, что для терминального символа b справедливо FIRST(l,b) = {b}.
Например, рассмотрим грамматику арифметических выражений для символе: aHbG({+l-,/l*,a,b}.{S'lS,T,E},P,S,):
Р:
S' f s
S S+T I S-T I T
T — T*E I T/E I E
E (S) I a I b
Если начать строить множество ситуаций ЬК(О)-грамматики для этой грамматики, то начальная ситуация будет выглядеть так: RO = {S' -> *S,S -> ・S+T,S — •S-T.S т ・Т,Т т ・Т*Е,Т т ・Т/Е.Т —・Е,Е т ・(S),E т ・а,Е т ・Ь}. Из нее 匚 символу S можно получить ситуацию RI = (S' —> S・，S —> S*+T, S -> S*-T}, a n: символу T — ситуацию R2 = {S -> T*,T -> T**E,T -> T*/E}.
При построении управляющей таблицы Т для этой грамматики на основе алгоритма для ЬК(О)-грамматик в состояниях R1 и R2 возникнут противоречия, 1103ToM данная грамматика не является ЬК(0)-грамматикой. Однако если воспользоваться алгоритмом для 5ЬК(1)-грамматики, то противоречий удается избежать:
для ситуации R1, приняв во внимание, что FOLLOW( 1,S') = {1к}, a FIRSK1.+) = {十 и FIRSK1.-) = {-}, получим, что для правого контекста 丄к («конец строки» необходимо сигнализировать об успехе, а для правых контекстов + и - — выполнять сдвиг (остальные варианты правого контекста в этой ситуации предполагают ошибку);
для ситуации R2 найдем FOLLOW(l.S), получим FOLLOW(l.S)工{+,-,)}, FIRSTd,*)= ={*} и FIRSTd,/) = {/}, получим, что для правых контекстов +, -, ) необходимо выполнять свертку по правилу S -> Т, а для правых контекстов * и / — сдвиг (остальные варианты правого контекста в этой ситуации предполагают ошибку).
Построив полностью последовательность ситуаций для этой грамматики и управляющую таблицу Т на основе данной последовательности, можно убедиться, чтс рассмотренная грамматика является SLR( 1 )-грамматикой.
Ограничения SLR( 1 )-грамматик
Языки, заданные SLR( 1 )-грамматиками, представляют собой более широкий класс КС-языков, чем языки, заданные ЬИ(О)-грамматйками.
С другой стороны, SLR( 1 )-грамматики позволяют сократить объем управляющей таблицы Т распознавателя за счет того, что количество строк в ней соответствует количеству состояний ЬИ(О)-грамматики, которое зачастую существенно меньше, чем количество состояний LR( 1 )-грамматики. В то же время они используют более простой алгоритм исключения конфликтных ситуаций при построении этой таблицы, чем LR( 1 )-грамматики. В этом их преимущество перед LR( 1 )-грамматиками.
Однако не всякая LR( 1 )-грамматика является 5ЬИ(1)-грамматикой. Более того, оказывается, что класс языков, заданных S LR( 1 )-грамматиками уже, чем класс языков, заданных LR( 1 )-грамматиками. Это значит, что он уже, чем класс детерминированных КС-языков.
ВНИМАНИЕ
Не всякий детерминированный К С-язык может быть задан SLR( 1 )-грамматикой.
Возьмем рассмотренную ранее КС-грамматику G( {a ,b}. {^}. {S -> SaSb | X} .S) с пополненной грамматикой G'({a,b},{S1S,}.{S' -> S,S -> SaSb | XJ.S1).
Как было показано выше, начальная ситуация для этой грамматики имеет вид RO = {S' -> *S,S -> *SaSb,S -> •}. При построении управляющей таблицы Т на основе алгоритма для ЬН(О)-грамматики возникают противоречия. Если попытаться воспользоваться алгоритмом для SLR( 1 )-грамматики, то необходимо вычислить множества FIRST(l.S) и FOLLOW(l.S). Получим FIRST(l.S) = {а} и FOLLOW(l.S) = {a.b}. Оказывается, что для правого контекста а конфликта избежать не удается: с одной стороны, в этой ситуации для него необходимо выполнять сдвиг, поскольку S -> *SaSb входит в ситуацию и aeFIRST(l.S), но, с другой стороны, для него надо выполнять свертку по правилу S -> X, поскольку S -> • входит в ситуацию, и aeFOLLOWd,S). Следовательно, эта грамматика не является SLR( 1 )-грамматикой.
Для того чтобы расширить класс языков, заданных упрощенными ЬИ(1)-грамма- тиками, был предложен еще один класс грамматик — LALR( 1 )-грамматики.
Синтаксический разбор для ЬАкН(1)-грамматик
Идея распознавателей для ЬАЬИ(к)-грамматик та же самая, что и для SLR(k)- грамматик: сократить множество рассматриваемых ситуаций до множества ситуаций ЬК(О)-грамматики и упростить построение управляющей таблицы Т, но при этом найти алгоритм разрешения конфликтов при построении для ситуаций, в которых эти конфликты возникают, на основании правого контекста длиной к. Все LALR(k)-rpaMMaTHKH для всех к > 1 образуют класс LALR-грамматик (k > 1, поскольку ЬАЬК(О)-грамматика совпадает по определению с ЬК(О)-граммати- кой). Название LALR-грамматик происходит из идеи, которая используется для разрешения конфликтов — LALR означает «Look Ahead», то есть LR-грамматики с «заглядыванием вперед».
На практике используются только LALR( 1 )-грамматики, так как применяемый для них метод разрешения конфликтов достаточно сложно распространить на ЬАЬК(к)-грамматики с k > 1. *
В распознавателях на основе LALR( 1 )-грамматик построение управляющей таблицы Т выполняется так же, как и для SLR( 1 )-грамматик, но разрешение конфликтов выполняется не на основании множества FOLLOW(i,A), а путем анализа правого контекста для каждого конфликтного правила в ситуации на основании того, как это правило попало в данную ситуацию. Если анализ контекста допуска- lt выполнение свертки для некоторого правого контекста, то для этого правого контекста в управляющую таблицу Т записывается действие《свертка» на основании конфликтного правила. Действие《сдвке» записывается для всех остальных символов правого контекста, которые входят в множество FIRST(l,p) правил зида А —> а*р и не допускают выполнение свертки (более подробное описание анализа правого контекста для LALR( 1 )-грамматик можно найти в [4, т. 2]).
Возьмем КС-грамматику G({a,b}, {S} ,{S — SaSb | 九} .S) с пополненной грамматн- KoftG'({a,b},{S,S'}.{S, — S.S — SaSb | 入}S).
Построим для нее последовательность ситуаций:
RO = {S' ->・S,S -» *SaSb,S - •};
RI = {S' -> S*,S-> S*aSb} (порождена из RO по символу S);
R2 = js -> Sa*Sb,S -> *SaSb,S -> •} (порождена из RI и из R3 по символу а)；
R3 = {S -> SaS*b. S -> S*aSb} (порождена из R2 по символу S).
R4 = {S -> SaSb・} (порождена из R3 по символу Ь).
Конфликты присутствуют в ситуациях R1 и R2.
Рассмотрим ситуацию R1. В ней возможна свертка по правилу S' -> S* или сдвн「 в соответствии с правилом S -> S*aSb. Если проанализировать правило S' -> S» то видно, что оно появилось в ситуации R1 из правила S' -> *S ситуации R0, следовательно, правым контекстом для этого правила может быть только символ ±- Тогда для ситуации R1 имеем, что для правого контекста 丄к должна выполняться свертка по правилу S' -> S (а поскольку в правой части правила стоит целевой символ S\ то это соответствует действию《успех»), а для правого контекста а - сдвиг (FIRST(LaSb) - {а}).
Аналогично, для ситуации R2 возможна свертка по правилу S -> • или сдвиг в соответствии с правилами S -> Sa *Sb и S -> *SaSb. Если проанализировать правиле S -> •, то видно, что оно могло появиться в ситуации R2 из правила S -> Sa ・S二 этой же ситуации — тогда правым контекстом для него должен быть символ 匸 но это же правило могло появиться в ситуации R2 также на основании правила S —> «SaSb из этой же ситуации — тогда правым контекстом для него будет символ а. Получаем, что в ситуации R2 для правых контекстов а и b должна выполняться свертка по правилу S -> X. Сдвиг в этой ситуации выполняться не должен, поскольку FIRST(l.Sb) = FIRST(l.SaSb) = {a.b}, но для символов а и b уже выполняется свертка.
Все конфликтные ситуации удалось разрешить. Таким образом, данная грамматика является LALR( 1 )-грамматикой.
Построим управляющую таблицу для данной грамматики, используя найденнук последовательность ситуаций и правила разрешения конфликтов, полученные для ситуаций R1 и R2.
Таблица 44 Пример управляющей таблицы для 1А1П(1)-грамматики
№
Стек
Действия
ь丄1t
Переходы
а
bS
0
丄U
свертка, 3
свертка, 3
1
1
S
сдвиг
успех, 1
2
2
Sa
свертка, 3
свертка, 3
3
3
SaS
сдвиг
сдвиг
2
4
4
SaSb
свертка, 2
свертка, 2 свертка, 2
Как и в ранее построенных таблицах, колонка «Стек» не нужна распознавателю, а введена для пояснения состояния стека. Пустые клетки в таблице соответству-
ют состоянию «ошибка». Правила грамматики пронумерованы от 1 до 3. Колонка «Действия» в таблице содержит перечень действий, соответствующих текущему входному символу, обозреваемому считывающей головкой автомата.
Рассмотрим примеры распознавания цепочек языка, заданного этой грамматикой. Конфигурацию расширенного МП-автомата будем отображать в виде трех компонентов, как это было сделано выше.
Разбор цепочки abababb:
(abababb丄к,{丄н,0}4)
(abababblK.{lH.0}{S.l},3)
(bababblK.{lH.0}{S.l}{a,2},3)
(bababb±K.{±H,0}{S.l}{a,2}{S.3}.3.3)
(ababb±K,{±H,0}{S.l}{a.2}{S.3}{b.4}.3.3)
(ababb丄к,{丄h.0}{S,1},3,3,2)
(babblK,{lH.0}{S.l}{a.2},3.3.2)
(babblK.{±H.0}{S,l}{a.2}{S.3}.3.3.2.3)
(abblK.{lH.0}{S.l}{a.2}{S.3){b.4}.3.3.2.3)
(abblK.{±H.0}{S.l}.3.3.2.3,2)
(bb±K.{lH.0}{S.l}{a,2}.3.3.2.3.2)
(bb±K.{lH.0}{S.l}{a.2}{S.3}.3.3.2,3.2.3)
(b±K.{lH.0}{S,l}{a.2}{S.3}{b.4}>3.3.2.3.2.3)
(blK,{lH.0}{S,l},3.3.2,3.2.3.2)
ошибка, нет действий для b в строке 1.
Разбор цепочки aababb:
(aababb丄к,{丄н,0}入)
(aababb丄к,{丄h,0}{S,1},3)
(ababblK,{lH.0}{S.l}{a.2},3)
(ababblK.{lH.0}{S>l}{a>2}{S.3},3.3)
(babblK.{lH,0}{S.l}{a,2}{S.3}{a.2}.3.3)
(babblK.{lH,0}{S.l}{a.2}{S.3}{a.2}{S.3},3,3,3)
(abb±K.{lH.0}{S.l}{a.2}{S.3}{a.2}{S.3}{b.4}.3.3,3)
(abblK.{lH,0}{S.l}{a.2}{S.3}.3.3.3.2).
(bblK.{±H.0}{S.l}(a.2}{S.3}{a,2}.3.3.3,2)
(bblK.{lH,0}{S.l}{a.2}{S,3}{a.2}{S,3}.3.3.3,2,3)
(b±K.{±H.0}{S,l}{a.2}{S,3}{a.2}{S.3}{b.4}.3.3.3.2.3)
(blK,{lH,0}{S,l}{a.2}{S.3}.3.3.3.2.3,2)
(丄к,{丄H,0}{S,l}{a,2}{S,3}{b,4}.3,3,3.2.3,2)
14•(丄 к,{丄 h,0}{S,1},3,3,3,2,3,2,2)
(丄к, {1h,0}{S' ,*},3,3,3.2,3,2,2,1) — разбор завершен.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S' n S n SaSb n SaSaSbb n SaSabb n SaSaSbabb n SaSababb 二 Saababb => aababb.
Можно убедиться, что вывод, найденный с помощью распознавателя на основе LALR⑴-грамматики, соответствует выводу, найденному распознавателем на основе LR ⑴-грамматики.
Особенности LALR(1 )-грамматик
Как и SLR( 1 )-грамматики, LALR( 1 )-грамматики позволяют сократить объем управляющей таблицы Т распознавателя за счет того, что количество строк в ней соответствует количеству состояний ЬН(О)-грамматики. Но по сравнению с SLR(l)- грамматиками они используют более сложный алгоритм исключения конфликтных ситуаций при построении этой таблицы. В целом, построить распознаватель на основе LALR( 1 )-грамматики проще, чем распознаватель на основе LR(^-грамматики, но немного сложнее, чем распознаватель на основе SLR⑴-грамматики Класс LALR(l)-rpaMMaTHK шире, чем класс SLR( 1 )-грамматик. Например, рассмотренная выше пополненная КС-грамматика G,({a,b},{S.S,}-{S，—> S.S -> SaSb | 入} S') является LALR( 1)-грамматикой, но не является SLR( 1)-грамматикой. Однакс важно, что и языки, заданные LALR( 1)-грамматиками, представляют собой более широкий класс КС-языков, чем языки, заданные 8ЬН(1)-грамматиками.
ПРИМЕЧАНИЕ
Всякая SLR( 1 )-грамматика является ЬАЬК(1)-грамматикой, но не наоборот.
Доказано, что любой детерминированный КС-язык может быть задан LALR(l)- грамматикой, а это значит, что класс языков, заданных LALR( 1 )-грамматиками. совпадает с классом языков, заданных LR( 1 )-грамматиками [4, т. 2]. Хотя известно, что класс LR⑴-грамматик шире, чем класс LALR( 1 )-грамматик.
ВНИМАНИЕ
Всякий язык, заданный LR( 1 )-грамматикой, может быть задан LALR( 1 )-граммати- кой, но не всякая LR( 1 )-грамматика является LALR( 1 )-грамматикой.
LALR( 1 )-грамматики представляют собой более удобный инструмент для построения распознавателей, чем LR⑴-грамматики. Кроме того, этот класс грамматик достаточно мощный, чтобы на его основе можно было построить синтаксический анализатор для любого языка программирования, представляющего практический интерес (а такой интерес представляют только детерминированные КС-языки). Однако этот класс грамматик уже, чем класс LR( 1 )-грамматик, а значит, существуют LR( 1 )-грамматики, которые не являются LALR( ^-грамматиками. Как и для других классов КС-грамматик, не всегда удается найти преобразование, позволяющее построить LALR⑴-грамматику для языка, заданного LR( 1 )-грамматикой. В ряде случаев этот факт может ограничить применение распознавателей на основе LALR⑴-грамматик.
Но распознаватели на основе LALR( 1 )-грамматик имеют еще один недостаток по сравнению с распознавателями на основе LR( 1 )-грамматик. Дело в том, что метод анализа правого контекста, применяемый при построении распознавателя для LALR( 1 )-грамматики, несколько ограничивает возможности распознавателя по обнаружению ошибок во входной цепочке символов. Ошибка, конечно же, будет обнаружена, но распознавателю на основе LALR( 1 )-грамматики потребуется для этого больше шагов, чем распознавателю на основе LR( 1 )-грамматики. Это значит, что ошибка будет найдена на более поздней стадии синтаксического анализа1. В таком случае у компилятора будет меньше возможностей по диагностике ошибки — поэтому можно сказать, что распознаватели на основе LALR( 1 )-грамматик упрощают выполнение синтаксического анализа, но при этом уменьшают возможности компилятора по диагностике ошибок, по сравнению с распознавателями на основе LR( 1 )-грамматик.
Тем не менее несмотря на указанные недостатки распознаватели на основе LALR( 1 )-грамматик являются одним из самых мощных и эффективных средств для построения синтаксических анализаторов. Именно поэтому данный тип распознавателя используется при решении задачи автоматизации построения синтаксического анализатора.
Автоматизация построения синтаксических анализаторов (программа YACC)
При разработке различных прикладных программ часто возникает задача синтаксического разбора некоторого входного текста. Конечно, ее можно всегда решить, полностью самостоятельно построив соответствующий анализатор. И хотя задача выполнения синтаксического разбора встречается не столь часто, как задача выполнения лексического разбора, но все-таки и для ее решения были предложены соответствующие программные средства.
Автоматизированное построение синтаксических анализаторов может быть выполнено с помощью программы YACC.
Программа YACC (Yet Another Compiler Compiler) предназначена для построения синтаксического анализатора КС-языка. Анализируемый язык описывается 二 помощью грамматики в виде, близком форме Бэкуса—Наура (нормальная форма Бэкуса—Наура — НФБН). Результатом работы YACC является исходный текст программы синтаксического анализатора. Анализатор, который порождается YACC, реализует восходящий распознаватель на основе LALR( 1 )-грамматики [3, 8, 29. 48].
Как и программа LEX, служащая для автоматизации построения лексических анализаторов, программа YACC тесно связана с историей операционных систем типа UNIX. Эта программа входит в поставку многих версий ОС UNIX или Linux. Поэтому чаще всего результатом работы YACC является исходный текст гинтаксического распознавателя на языке С. Однако существуют версии YACC,
Этот факт можно заметить даже на примере разбора простейшей ошибочной входной цепочки, который был рассмотрен выше для LR( 1 )-грамматики, а затем и для LALR(l)-rpaM- матики.
выполняющиеся под управлением ОС, отличных от UNIX, и порождающие исхо二 ный код на других языках программирования (например, Pascal).
Принцип работы YACC похож на принцип работы LEX: на вход поступает фай/ содержащий описание грамматики заданного КС-языка, а на выходе получае*. текст программы синтаксического распознавателя, который, естественно, можн дополнять и редактировать, как и любую другую программу на заданном язьн - программирования.
Исходная грамматика для YACC состоит из трех секций, разделенных двог.- ным символом % — И: секции описаний, секции правил, в которой описываете - грамматика, и секции программ, содержимое которой просто копируется в вь - ходной файл.
Например, ниже приведено описание простейшей грамматики для YACC, коте - рая соответствует грамматике арифметических выражений, многократно исполь зовавшейся в качестве примера в данном пособии:
Ztoken а
Ztoken b
Zstart е-
И
е ： е '+' m I е m I m ；
m ： m t I m '/' t I t ;
t ： a I b |'(' e ;
Секция описаний содержит информацию о том, что идентификатор а является лексемой (терминальным символом) грамматики, а символ е — ее начальным нетерминальным символом.
Грамматика записана обычным образом — идентификаторы обозначают терминальные и нетерминальные символы; символьные константы типа ' + ' и '-' считаются терминальными символами. Символы ：, |, : принадлежат метаязык;. YACC и читаются согласно НФБН «есть по определению», «или» и «конец правила» соответственно.
В отличие от LEX, который всегда способен построить лексический распознаватель, если входной файл содержит правильное регулярное выражение, YACC не всегда может построить распознаватель, даже если входной язык задан правильной КС-грамматикой. Ведь заданная грамматика может и не принадлежать класс、 LALR( 1 )-грамматик. В этом случае YACC выдаст сообщение об ошибке (о наличии неразрешимого конфликта в LALR⑴-грамматике) при построении синтаксического анализатора. Тогда пользователь должен либо преобразовать грамматику, либо задать YACC некоторые дополнительные правила, которые могут облегчить построение анализатора. Например, YACC позволяет указать правила, явно задающие приоритет операций и порядок их выполнения (слева направо или справа налево).
С каждым правилом грамматики может быть связано действие, которое будет выполнено при свертке по данному правилу. Оно записывается в виде заключенной в фигурные скобки последовательности операторов языка, на котором поро-
ждается исходный текст программы распознавателя (обычно это язык С). Последовательность должна располагаться после правой части соответствующего правила. Также YACC позволяет управлять действиями, которые будут выполняться распознавателем в том случае, если входная цепочка не принадлежит заданному языку. Распознаватель имеет возможность выдать сообщение об ошибке, остановиться либо же продолжить разбор, предприняв некоторые действия, связанные с попыткой локализовать либо устранить ошибку во входной цепочке. YACC в настоящее время не является единственным программным продуктом, предназначенным для автоматизации построения синтаксических анализаторов, так же как и LEX не является единственным программным продуктом для автоматизации построения лексических анализаторов. Сейчас на рынке средств разработки программного обеспечения присутствует целый ряд программных продуктов, ориентированных на решение такого рода задач. Некоторые из них распространяются бесплатно или же бесплатно, но с некоторыми ограничениями, другие являются коммерческими программными продуктами. Многие средства такого рода входят в состав ОС и систем программирования (стоит отметить, что LEX и YACC входят в состав ОС типа UNIX).
СОВЕТ
Если у читателей существует потребность в программном обеспечении для автоматизированного построения синтаксических анализаторов, автор прежде всего рекомендует обратиться для поиска таких средств во всемирную сеть Интернет. По ключевым словам «YACC» и «LALR» можно получить достаточное количество полезных ссылок.
Более подробные сведения о программе автоматизированного построения синтаксических распознавателей YACC можно получить в [20, 29, 46].
Синтаксические распознаватели на основе грамматик предшествования
Общие принципы грамматик предшествования
Еще одним распространенным классом КС-грамматик, для которых возможно построить восходящий распознаватель без возвратов, являются грамматики предшествования. Так же как и распознаватель для рассмотренных выше LR-грамматик, распознаватель для грамматик предшествования строится на основе алгоритма «сдвиг-свертка» («перенос-свертка»), который в общем виде был рассмотрен в разделе «Синтаксические распознаватели с возвратом».
Принцип организации распознавателя на основе грамматики предшествования исходит из того, что для каждой упорядоченной пары символов в грамматике устанавливается отношение, называемое отношением предшествования. В процессе разбора расширенный МП-автомат сравнивает текущий символ входной цепочки с одним из символов, находящихся на верхушке стека автомата. В процессе
сравнения проверяется, какое из возможных отношений предшествования с\ ствует между этими двумя символами. В зависимости от найденного отнош(. выполняется либо сдвиг, либо свертка. При отсутствии отношения предшс вания между символами алгоритм сигнализирует об ошибке.
Задача заключается в том, чтобы иметь возможность непротиворечивым образ определить отношения предшествования между символами грамматики. Ес; это возможно, то грамматика может быть отнесена к одному из классов гpa^r тик предшествования.
Существует несколько видов грамматик предшествования. Они различаются те какие отношения предшествования в них определены и между какими типа' символов (терминальными или нетерминальными) могут быть установлены ь отношения. Кроме того, возможны незначительные модификации функционир вания самого алгоритма «сдвиг-свертка» в распознавателях для таких граммат. (в основном на этапе выбора правила для выполнения свертки, когда возможн. неоднозначности) [4, т. 1, 2].
Выделяют следующие виды грамматик предшествования:
простого предшествования;
расширенного предшествования;
слабого предшествования;
смешанной стратегии предшествования;
операторного предшествования.
Далее будут рассмотрены два наиболее простых и распространенных типа - грамматики простого и операторного предшествования.
Грамматики простого предшествования
Грамматикой простого предшествования называют такую приведенную КС-грамматику1 G(VN,VT,P,S), V = VTuVN, в которой:
Для каждой упорядоченной пары терминальных и нетерминальных символе: выполняется не более чем одно из трех отношений предшествования:
О В; =• Bj (VBpBjeV), если и только если 3 правило А — xBjBjyeP, гд AeVN, x,yeV*;
О В1 <• Bj (VBpBjeV), если и только если 3 правило А -> xBQyeP и выво- D => *Sr, где A.DeVN, x,y,zeV*;
О В)•> Bj (DB|,BjGV), если и только если 3 правило А — хСВуеР и вывсы С n *zB| или 3 правило A f xCDyeP и выводы С n *zB, и D n *B」w, гд- A,C,DeVN, x,y,z,weV*.
Различные правила в грамматике имеют разные правые части (то есть в грамматике не должно быть двух различных правил с одной и той же право】' частью).
Напоминаем, что КС-грамматика называется приведенной, если она не содержит циклов, бесплодных и недостижимых символов и 入-правил.
Отношения =・，<• и •> называют отношениями предшествования для символов. Отношение предшествования единственно для каждой упорядоченной пары символов. При этом между какими-либо двумя символами может и не быть отношения предшествования — это значит, что они не могут находиться рядом ни в одном элементе разбора синтаксически правильной цепочки. Отношения предшествования зависят от порядка, в котором стоят символы, и в этом смысле их нельзя путать со знаками математических операций — они не обладают ни свойством коммутативности, ни свойством ассоциативности. Например, если известно, что Bj •> Bj, то не обязательно выполняется В」<• В| (поэтому знаки предшествования иногда помечают специальной точкой:=・，<•, •>).
Для грамматик простого предшествования известны следующие полезные свойства:
всякая грамматика простого предшествования является однозначной;
легко проверить, является или нет произвольная КС-грамматика грамматикой простого предшествования (для этого достаточно проверить рассмотренные выше свойства грамматик простого предшествования или воспользоваться алгоритмом построения матрицы предшествования, который рассмотрен далее).
Как и для многих других классов грамматик, для грамматик простого предшествования не существует алгоритма, который бы мог преобразовать произвольную КС-грамматику в грамматику простого предшествования или доказать, что преобразование невозможно.
Метод предшествования основан на том факте, что отношения предшествования между двумя соседними символами распознаваемой строки соответствуют трем следующим вариантам:
В)<• В1+1, если символ В1+1 — крайний левый символ некоторой основы (это отношение между символами можно назвать «предшествует основе», или просто «предшествует»);
В)•> В1+1, если символ Bj — крайний правый символ некоторой основы (это отношение между символами можно назвать «следует за основой», или просто «следует»);
Bj =• В1+1, если символы В, и В1+1 принадлежат одной основе (это отношение между символами можно назвать «составляют основу»).
Исходя из этих соотношений выполняется разбор строки для грамматики предшествования.
Суть принципа такого разбора можно понять из рис. 4.10. На нем изображена входная цепочка символов ауРб в тот момент, когда выполняется свертка цепочки у. Символ а является последним символом подцепочки а, а символ b — первым символом подцепочки 0. Тогда, если в грамматике удастся установить непротиворечивые отношения предшествования, то в процессе выполнения разбора по алгоритму «сдвиг-свертка» можно всегда выполнять сдвиг до тех пор, пока между символом на верхушке стека и текущим символом входной цепочки существует отношение <• или =•. А как только между этими символами будет обнаружено отношение •>, так сразу надо выполнять свертку. Причем для выполнения свертки из стека надо выбирать все символы, связанные отношением =•. То, что
все различные правила в грамматике предшествования имеют различные праг части, гарантирует непротиворечивость выбора правила при выполнении сверт Таким образом, установление непротиворечивых отношений предшествова! между символами грамматики в комплексе с несовпадающими правыми частя- различных правил дает ответы на все вопросы, которые надо решить для орган, зации работы алгоритма «сдвиг-свертка» без возвратов.
а
а
У
ь
Р |3
Рис. 4.10. Отношения между символами входной цепочки в грамматике предшествован/-
На основании отношений предшествования строят матрицу предшествование грамматики. Строки матрицы предшествования помечаются первыми (левыми) символами, столбцы — вторыми (правыми) символами отношений предшествования. В клетки матрицы на пересечении соответствующих столбца и строки помещаются знаки отношений. При этом пустые клетки матрицы говорят о том что между данными символами нет ни одного отношения предшествования.
Матрицу предшествования грамматики сложно построить, опираясь непосредст венно на определения отношений предшествования. Удобнее воспользоваться дв;. мя дополнительными множествами — множеством крайних левых и множество' крайних правых символов относительно нетерминальных символов граммати G(VN,VT,P,S), V = VTuVN. Эти множества определяются следующим образ(
L(A) = {X | 3 А => *Xz}, AeVN, XeV, zeV* — множество крайних левых си волов относительно нетерминального символа А (цепочка z может быть и пустой цепочкой);
R(A) = {X | 3 А => *zX}, AeVN, XeV, zeV* — множество крайних правых сим волов относительно нетерминального символа А.
Иными словами, множество крайних левых символов относительно нетерминального символа А — это множество всех крайних левых символов в цепочках, которые могут быть выведены из символа А. Аналогично, множество крайних правых символов относительно нетерминального символа А — это множество всех крайних правых символов в цепочках, которые могут быть выведены из символа А Тогда отношения предшествования можно определить так:
Bj =• Bj (VBpBjeV), если 3 правило А -> xB,BjyeP, где AeVN, x,yeV*;
В, <• Bj (VBj.BjeV), если 3 правило А -> xBjDyeP и BjWL(D), где A.DeVN x,yeV;
В, •> Bj (VB„BjeV) , если 3 правило А -> хСВреР и В,еК(С) или 3 правиле А -> xCDyeP и B«R(C), BjCL(D), где A,C,DeVN, x,yeV'.
Такое определение отношений удобнее на практике, так как не требует построения выводов, а множества L(A) и R(A) могут быть построены для каждогс нетерминального символа AeVN грамматики G(VN,VT,P,S), V = VTuVN ь очень простому алгоритму:
Шаг 1. VAeVN:
Ro(A) = {X I A f уХ, XeV, yeV*}, L0(A) = {X | A - Xy, XeV, yeV*}, i := 1.
Для каждого нетерминального символа А ищем все правила, содержащие А в левой части. Во множество L(A) включаем самый левый символ из правой части правил, а во множество R(A) — самый крайний правый символ из правой части. Переходим к шагу 2.
Шаг 2. VAeVN:
К(А) = К“(А)иКг(В), VBe(Ri.1(A)nVN),
L_(A) = LMA)S“(B), VBe(LM(A)nVN).
Для каждого нетерминального символа А: если множество L(A) содержит нетерминальные символы грамматики А', А", ..., то его надо дополнить символами, входящими в соответствующие множества L(A'), L(A"),... и не входящими в L(A). Ту же операцию надо выполнить для R(A).
Шаг 3. Если 3 AeVN: К(А) н КЬ1(А) или L<A) н Ц.^А), то i := i + 1 и вернуться к шагу 2, иначе построение закончено: R(A) = К(А) и L(A) = L/A).
Если на предыдущем шаге хотя бы одно множество L(A) или R(A) для некоторого символа грамматики изменилось, то надо вернуться к шагу 2, иначе построение закончено.
После построения множеств L(A) и R(A) по правилам грамматики создается матрица предшествования. Матрицу предшествования дополняют символами 丄“ и 丄к (начало и конец цепочки). Для них определены следующие отношения предшествования:
1Н < X, VaeV, если 3 S => *Ху, где SeVN, yeV* или (с другой стороны) если XeL(S);
丄к •> X, VaeV, если 3 S => *уХ, где SeVN, yeV* или (с другой стороны) если
XeR(S).
Здесь S — целевой символ грамматики.
Матрица предшествования служит основой для работы распознавателя языка, заданного грамматикой простого предшествования.
Алгоритм «сдвиг-свертка» для грамматики простого предшествования
Отношения предшествования служат для того, чтобы определить в процессе выполнения алгоритма, какое действие — сдвиг или свертка — должно выполняться на каждом шаге алгоритма, и однозначно выбрать цепочку для свертки. Однозначный выбор правила при свертке обеспечивается за счет различия правых частей всех правил грамматики. В начальном состоянии автомата считывающая головка обозревает первый символ входной цепочки, в стеке МП-автомата находится символ 丄и (начало цепочки), в конец цепочки помещен символ 丄к (конец цепочки). Символы 丄” и 丄к введены для удобства работы алгоритма, в язык, заданный исходной грамматикой, они не входят.
Разбор считается законченным (алгоритм завершается), если считывающая 二 ловка автомата обозревает символ 丄心 и при этом больше не может быть выпс_ йена свертка. Решение о принятии цепочки зависит от содержимого стека. Автохог принимает цепочку, если в результате завершения алгоритма в стеке находя" начальный символ грамматики S и символ 丄н. Выполнение алгоритма мо - быть прервано, если на одном из его шагов возникнет ошибка. Тогда входная почка не принимается.
Алгоритм состоит из следующих шагов:
Шаг 1. Поместить в верхушку стека символ 丄н, считывающую головку — в на ло входной цепочки символов.
Шаг 2. Сравнить с помощью отношения предшествования символ, находящи' на вершине стека (левый символ отношения), с текущим символом входной 一 почки, обозреваемым считывающей головкой (правый символ отношения).
Шаг 3. Если имеет место отношение <• или =•, то произвести сдвиг (перенос тек щего символа из входной цепочки в стек и сдвиг считывающей головки на。二 шаг вправо) и вернуться к шагу 2. Иначе перейти к шагу 4.
Шаг 4. Если имеет место отношение •>, то произвести свертку. Для этого н найти на вершине стека все символы, связанные отношением =• («основу»),〉 лить эти символы из стека. Затем выбрать из грамматики правило, имею, правую часть, совпадающую с основой, и поместить в стек левую часть выбр ного правила (если символов, связанных отношением =♦, на верхушке стека :- то в качестве основы используется один, самый верхний символ стека). Е、 правило, совпадающее с основой, найти не удалось, то необходимо прервать полнение алгоритма и сообщить об ошибке, иначе, если разбор не закончен вернуться к шагу 2.
Шаг 5. Если не установлено ни одно отношение предшествования между тек щим символом входной цепочки и символом на верхушке стека, то надо пр? рвать выполнение алгоритма и сообщить об ошибке.
Ошибка в процессе выполнения алгоритма возникает, когда невозможно выпо.' нить очередной шаг — например, если не установлено отношение предшествокс- ния между двумя сравниваемыми символами (на шагах 2 и 4) или если не удаетс - найти нужное правило в грамматике (на шаге 4). Тогда выполнение алгорит* прерывается.
Пример распознавателя для грамматики простого предшествования
Рассмотрим в качестве примера грамматику G({+,-,/,*,a,b},{S,R.T.F.E}.P.S) с пр. вилами:
Р:'
S - TR | Т
r _> +Т | -Т | +TR | -TR Т -> EF | Е
F -> *Е | /Е | *EF | /EF
Е -> (S) | а | b
Эта нелеворекурсивная грамматика для арифметических выражений над символами а и b уже несколько раз использовалась в качестве примера для построения распознавателей. Хотя эта грамматика и содержит цепные правила, легко увидеть, что она не содержит циклов, совпадающих правых частей правил и Х-пра- вил, следовательно, по формальным признакам ее можно отнести к грамматикам простого предшествования. Осталось определить отношения предшествования. Построим множества крайних левых и крайних правых символов относительно нетерминальных символов грамматики.
Шаг 1.
L0(S) = {Т} R0(S) = {R,T}
L0(R) = {+.-}R0(R) = {R.T}
L0(T) = {E} R0(T) = {E.F}
LO(F) = {*,/}R0(F) = {E,F}
L0(E) = {(.a.b} R0(E) = {),a,b}
Шаг 2.
Lt(S) = {T,E}R1(S) = {R.T.E.F}
LKR) = {+「} RKR) = (R.T.E.F)
LKT) = {E,(,a,b} RKT) = {E.FJ.a.b}
LKF) = {*./} RKF) = {EE)ab}
LKE) = {(.a.b} RKE) = {).a,b}
Шаг 3. Имеется L0(S) н LKS), возвращаемся к шагу 2.
Шаг 2.
L2(S) = {T,E,(,a,b}R2(S) = {R.T.E.F,).a,b} •
L2(R) = {+,-}R2(R) = {R.T.E.F,),a.b}
L2(T) = {E,(,a,b} R2(T) = {E.F,),a,b}
L2(F) = {*./}R2(F) = {E.FJ.a.b}
L2(E) = {(.a.b} R2(E) = {),a.b}
Шаг 3. Имеется LKS) н L2(S), возвращаемся к шагу 2.
Шаг 2.
L3(S) = {T.E.(.a,b}R3(S) = {R,T,E,F,),a,b}
L3(R) = {+,-}R3(R) = (R.T.E.F,),a.b} '
L3(T) = {E,(,a.b} R3(T) = {E,F,),a,b}
L3(F) = {*./}R3(F) = {E.F,),a,b}
L3(E) = {(.a.b} R3(E) = {).a.b}
Шаг 3. Ни одно множество не изменилось, построение закончено. Результат:
L(S) = {T.E.(.a.b} R(S) = {R.T.E.F,),a.b}
L(R) = {+.-} R(R) = (R.T.E.F,),a.b}
L(T) = {E,(,a,b}R(T) = {E.F,),a,b}
L(F) = {*,/} R(F) = {E,F.),a,b}
L(E) = {(.a.b} R(E) = {),a,b}
На основании построенных множеств крайних левых и крайних правых сим; лов и правил грамматики построим матрицу предшествования. Результат приз ден в табл. 4.5.
Таблица 4.5. Таблица предшествования для грамматики простого предшествования
+
-*/() а
b
S R
T
F
E丄К
+
<•<•
<.
-
v・<•
<■
<.
V・<.
<■
/
<.<.
<.
i
(
v・v・
<-
=.
v・
<-
)
>
•>•>•>•>
•>
•>
•A
а
>
•>•>■>.>
>
•>
>
b
>
•>•>•>.>
>
•>
A
S
R
•>
>
Т
<.
<••>
=・
>
F
->
>>
>
>
Е
•>
><.<..>
>
•A
丄"
v・v・
<•
<.
V，
Поясним построение таблицы на примере символа +.
Во-первых, в правилах грамматики R f +Т | +TR символ + стоит слева от символа ~ Значит, в строке символа + в столбце, соответствующем символу Т, ставим знак = Кроме того, во множество L(T) входят символы Е, (, а, Ь. Тогда в строке символа - во всех столбцах, соответствующих этим четырем символам, ставим знак <•.
Во-вторых, символ + входит во множество L(R), а в грамматике имеются правила вида S f TR и R -> +TR | -TR. Следовательно, надо рассмотреть также множестве R(T). Туда входят символы Е, F, ), а, Ь. Значит, в столбце символа + во всех строках, соответствующих этим пяти символам, ставим знак •>. Больше символ + нн в какие множества не входит и ни в каких правилах не встречается.
Продолжая эти рассуждения для остальных терминальных и нетерминальных символов грамматики, заполняем все ячейки матрицы предшествования, приведенной выше. Если окажется, что согласно логике рассуждений в какую-либо клетку матрицы предшествования необходимо поместить более чем один знак = <• или •>, то это означает, что исходная грамматика не является грамматикой простого предшествования.
Отдельно можно рассмотреть заполнение строки для символа ±н (начало строки) и столбца для символа 丄к (конец строки). Множество L(S), где S — целевоь
символ, содержит символы Т, Е, (, а, Ь. Помещаем знак <• в строку, соответствующую символу 丄н для всех пяти столбцов, соответствующих этим символам. Аналогично, множество R(S) содержит символы R, Т, Е, F, ), а, Ь. Помещаем знак •> з столбец, соответствующий символу 丄к для всех семи строк, соответствующих этим символам.
Рассмотрим работу алгоритма распознавания на примерах. Последовательность разбора будем записывать в виде последовательности конфигураций МП-автомата из трех составляющих:
не просмотренной автоматом части входной цепочки;
содержимого стека;
последовательности примененных правил грамматики.
Так как автомат имеет только одно состояние, то для определения его конфигурации достаточно двух составляющих — положения считывающей головки во зходной цепочке и содержимого стека. Последовательность номеров правил несет дополнительную полезную информацию, на основании которой можно построить цепочку или дерево вывода. Правила в грамматике нумеруются в направлении слева направо и сверху вниз (всего в грамматике имеется 15 правил).
Будем обозначать такт автомата символом +. Введем также дополнительное обозначение +п, если на данном такте выполнялся перенос, и +с, если выполнялась свертка.
Последовательности разбора цепочек входных символов будут, таким образом, иметь вид:
Пример 1. Входная цепочка а+а*Ь:
{а+а*Ык:±н；0} +п
{+а*Ь丄к；丄на：0} +с'
{+а*Ь丄к；丄нЕ;14} +с
{+a*b丄к：丄нТ； 14,8} +n
{а*Ь丄к；丄нТ+； 14.8} +п
{*Ь丄к；丄нТ+а；14,8} +с
{*Ык;±нТ+Е;14,8,14} +п
{Ык:±нТ+Е*;14.8.14} +п
{±к；±нТ+Е*Ь:14.8,14} +с
：0. {丄к；丄нТ+Е*Е;14.8,14」5} +с
：1. {丄к;丄hT+EF;14,8,14,15,9} +с.
：2. {±к：1нТ+Т;14,8.14,15,9,7} +с
{±k;1hTR;14.8,14.15.9.7,3} +с
{±k;±hS;14,8,14,15.9.7,3,1} алгоритм завершен, цепочка принята.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S n TR n Т+Т n T+EF n Т+Е*Е n T+E*b n T+a*b n E+a*b п а+а*Ь.
Дерево вывода, соответствующее этой цепочке, приведено на рис. 4.11.
Рис. 4.11. Пример дерева вывода для грамматики простого предшествования
Пример 2. Входная цепочка (а+а)*Ь:
{(d+d)*b丄к:丄н：0} +п
{d+d)*b丄к：丄н(:0} +п
{+а)*Ык：1н(а：0} +с
{+а)*Ык：1н(Е:14} +с
{+а)*Ь丄к；丄н(Т；14,8} +п
{а)*Ь丄к：丄н(Т+:14,8} +п
{)*Ык：1н(Т+а：14,8} +с
{)*Ык：1н(Т+Е：14,8,14} +с一
{)*Ык;1н(Т+Т：14,8.14.8} +с
{)*blK；lH(TR：14,8.14.8.3} +с
И. {)*blK；_LH(S：14.8,14.8,3.1} +п
{*blK：lH(S)：14.8.14.8.3.1} +с
{*Ык：1нЕ:14.8.14.8.3.1.13} +п
{Ык：1нЕ*;14,8.14.8.3.1.13} +п
{1к；1нЕ*Ь:14,8,14,8,3,1.13} +с
{1к;1нЕ*Е;14,8,14,8.3,1.13.15} +с
{Ik:IhEF:14.8.14,8.3.1.13.15,9} +с
{1к；1нТ；14.8,14,8,3.1,13.15.9.7} +с
{±к；±hS; 14,8,14.8,3,1,13,15,9.7,2} алгоритм завершен, цепочка принята.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S => Т => EF => Е*Е => E*b => (S)*b n (TR)*b n (T+T)*b п (Т+Е)*Ь = (T+a)*b n (E+a)*b п (а+а)*Ь.
Дерево вывода, соответствующее этой цепочке, приведено на рис. 4.12.
Рис. 4.12. Пример дерева вывода для грамматики простого предшествования
Пример 3. Входная цепочка а+а*:
:.{а+d*丄к：丄н；0} +n
{+а*丄к；丄на；。} +c
{+a*丄к：丄нЕ； 14} +c
{+d*丄к：丄нТ;14,8} +n
{a*丄к；丄нТ+；14,8} +n
{*1к；±нТ+а；14,8} +c
{*1к；1нТ+Е;14,8.14} xi
S. {丄к；丄hT+E*：14,8,14} +
ошибка! (нет отношений предшествования между символами * и 丄к). Пример 4. Входная цепочка а+а)*Ь:
{a+d)*b丄к；丄н；0} +п
{+а)*Ь丄к；丄на；0} +с
{+а)*Ык：1нЕ；14} +с
{+а)*Ык；1нТ；14,8} +п
{d)*b丄к;丄нТ+; 14,8}
{)*Ык；1нТ+а；14,8} +с
{)*Ык;1нТ+Е;14.8.14} +с
{)*Ык：1нТ+Т;14,8.14.8} +с
{)*Ь丄к；丄hTR;14,8,14,8,3} +с
{)*Ык；1н5;14,8,14,8,3,1} ^п
И. {*Ык：1н5):14,8.14,8,3.1} +с
ошибка! (невозможно выбрать правило для свертки на этом шаге).
Грамматики простого предшествования являются удобным механизмом для лиза входных цепочек КС-языков. Распознаватель для этого класса грам\ строить легче, чем для рассмотренных выше LR-грамматик. Однако класс ков, заданных грамматиками простого предшествования, уже, чем класс яз; заданных LR-грамматиками. Отсюда ясно, что не всякий детерминирова> КС-язык может быть задан грамматикой простого предшествования, а еле. тельно, не для каждого детерминированного КС-языка можно построить р< знаватель по методу простого предшествования.
У грамматик простого предшествования есть еще один недостаток — при С шом количестве терминальных и нетерминальных символов в грамматике рица предшествования будет иметь значительный объем (при этом следует з тить, что значительная часть ее ячеек может оставаться пустой). Поиск в i< матрице может занять некоторое время, что существенно при работе распоз; теля — фактически время поиска линейно зависит от числа символов грамх ки, а объем матрицы — квадратично. Во избежание хранения и обработки 匸 матриц можно выполнить «линеаризацию матрицы предшествования». Т каждый раз, чтобы установить отношение предшествования между двумя си лами, будет выполняться не поиск по матрице, а вычисление некой спецп но организованной функции. Вопросы линеаризации матрицы предшествов^ здесь не рассматриваются, с применяемыми при этом методами можно озп миться в [3, 4, т. 1, 2, 17, 22].
Грамматики операторного предшествования
Операторной грамматикой называется КС-грамматика без Х-правил, в коте правые части всех правил не содержат смежных нетерминальных символов.. операторной грамматики отношения предшествования можно задать на мн( стве терминальных символов (включая символы 丄“ и 丄J.
Грамматикой операторного предшествования называется операторная КС-грам тика G(VN,VT,P,S), V = VTuVN, для которой выполняются следующие условкч
Для каждой упорядоченной пары терминальных символов выполняется более чем одно из трех отношений предшествования:
О а =• Ь, если и только если существует правило А — xabyeP или правил: А т хаСЬу, где a,beVT, A,CeVN, x,yeV";
О а <• b, если и только если существует правило А т хаСуеР и вывод С 二 *bz или вывод С => *Dbz, где a.beVT, A,C,DgVN, x.y.zeV*;
Q а •> Ь, если и только если существует правило А -» хСЬуеР и вывод С п *za или вывод С n *zaD, где a,beVT, A,C,DeVN, x.y.zeV*.1
Различные порождающие правила имеют разные правые части, Х-правила отсутствуют.
Отношения предшествования для грамматик операторного предшествования эпределены таким образом, что для них выполняется еще одна особенность — правила грамматики операторного предшествования не могут содержать двух смежных нетерминальных символов в правой части. То есть в грамматике операторного предшествования G(VN,VT,P,S), V = VTWN не может быть ни одного правила вида: А -> хВСу, где A,B,CeVN, x,yeV* (здесь х и у — это произвольные цепочки символов, которые могут быть и пустыми).
Для грамматик операторного предшествования также известны следующие свойства:
всякая грамматика операторного предшествования задает детерминированный КС-язык (но не всякая грамматика операторного предшествования при этом является однозначной!);
легко проверить, является или нет произвольная КС-грамматика грамматикой операторного предшествования (точно так же, как и для простого предшествования).
Как и для многих других классов грамматик, для грамматик операторного предшествования не существует алгоритма, который бы мог преобразовать произвольную КС-грамматику в грамматику операторного предшествования или доказать, что преобразование невозможно.
Принцип работы распознавателя для грамматики операторного предшествования аналогичен грамматике простого предшествования, но отношения операторного предшествования проверяются в процессе разбора только между терминальными символами.
Для грамматики данного вида на основе установленных отношений предшество- зания также строится матрица предшествования, но она содержит только терминальные символы грамматики.
Для построения этой матрицы удобно ввести множества крайних левых и крайних правых терминальных символов относительно нетерминального символа А — U(A) или Rt(A):
Ll(A) = {t I 3 А => *tz или 3 A => *Ctz }, где teVT, A,CeVN, zeV*;
Rt(A) = {t I 3 A => *zt или 3 A => *ztC }, где teVT, A,CeVN, zeV*.
Тогда определения отношений операторного предшествования будут выглядеть так:
а =• Ь, если 3 правило А т xaby еР или правило U -» хаСЬу, где a,beVT, A,CeVN, x,yeV;
В литературе отношения операторного предшествования иногда обозначают другими символами, отличными от «<•», «•>» и «=•», чтобы не путать их с отношениями простого предшествования. Например, встречаются обозначения «<?», «?>» и «=?». В данном пособии путаница исключена, поэтому будут использоваться одни и те же обозначения, хотя по сути отношения предшествования несколько различны.
□ а <• Ь, если 3 правило А -> хаСу еР и beU(C), где a,beVT, A,CeVN, x,yeV □ а •> b, если В правило А -> хСЬу еР и aeRl(C), где a,beVT, A,CeVN, x,yeV
В данных определениях цепочки символов х, у, z могут быть и пустыми цепочкахш.
Для нахождения множеств U(A) и Rf(A) предварительно необходимо выполнить построение множеств L(A) и R(A), как это было рассмотрено ранее. Далее для построения U(A) и R〈A) используется следующий алгоритм:
Шаг 1. VAeVN:
Rt()(A) = {t I А т ytB или А т yt, teVT, BeVN, yeV*},
Ll0(A) = {t I A -> Bty или А т ty, teVT, BeVN, yeV*}-
Для каждого нетерминального символа А ищем все правила, содержащие А в левой части. Во множество L(A) включаем самый левый терминальный символ из правой части правил, игнорируя нетерминальные символы, а во множество R(A)— самый крайний правый терминальный символ из правой части правил. Перс дим к шагу 2.
Шаг 2. VAeVN:
R\(A) = ЮИ(А)^И(В), DBe(R(A)cVN),
L*(A) = Lti(AM4i(B), DBe(L(A)cVN).
Для каждого нетерминального символа А: если множество L(A) содержит нетерминальные символы грамматики А', А",..., то его надо дополнить символами, входящими в соответствующие множества ЬГ(А'), U(A"),... и не входящими в Ll(A Ту же операцию надо выполнить для множеств R(A) и Ю(А).
Шаг 3. Если 3 AgVN: R\(A) н R%(A) или L*(A)工 L；［(A), то i := i + 1 и вернуться к шагу 2, иначе построение закончено: R(A) = R*(A) и L(A) = 3(А).
Если на предыдущем шаге хотя бы одно множество 1?(А) или Rt(A) для некоторого символа грамматики изменилось, то надо вернуться к шагу 2, иначе построение закончено.
Для практического использования матрицу предшествования дополняют символами 丄н и 丄к (начало и конец цепочки). Для них определены следующие отношения предшествования:
丄и <• a, VaeVT, если 3 S => *ах или 3 S => *Сах, где S,CeVN, xeV* или если awU(S);
丄к •> a, VaeVT, если 3 S => *ха или 3 S => *хаС, где S.CeVN, xeV* или если aeRt(S).
Здесь S — целевой символ грамматики.
Матрица предшествования служит основой для работы распознавателя языка, заданного грамматикой операторного предшествования. Поскольку она содержит только терминальные символы, то, следовательно, будет иметь меньший размер, чем аналогичная матрица для грамматики простого предшествования. Следует отметить, что напрямую сравнивать матрицы двух грамматик нельзя — не всякая грамматика простого предшествования является грамматикой операторного предшествования и наоборот. Например, рассмотренная далее в приме-
ре грамматика операторного предшествования не является грамматикой простого предшествования (читатели могут это проверить самостоятельно).
ПРИМЕЧАНИЕ
Размер матрицы для грамматики операторного предшествования всегда будет меньше, чем размер матрицы эквивалентной ей грамматики простого предшествования.
Все, что было сказано выше о способах хранения матриц для грамматик простого предшествования, в равной степени относится также и к грамматикам операторного предшествования, с той лишь разницей, что объем хранимой матрицы будет меньше.
Алгоритм «сдвиг-свертка» для грамматики операторного предшествования
Этот алгоритм в целом похож на алгоритм для грамматик простого предшествования, рассмотренный выше. Он также выполняется расширенным МП-авто- матом и имеет те же условия завершения и обнаружения ошибок. Основное этличие состоит в том, что при определении отношения предшествования этот алгоритм не принимает во внимание находящиеся в стеке нетерминальные символы и при сравнении ищет ближайший к верхушке стека терминальный символ. Однако после выполнения сравнения и определения границ основы при поиске правила в грамматике, безусловно, следует принимать во внимание нетерминальные символы.
Алгоритм состоит из следующих шагов:
Шаг 1. Поместить в верхушку стека символ 丄”，считывающую головку — в начало входной цепочки символов.
Шаг 2. Сравнить с помощью отношения предшествования терминальный символ, ближайший к вершине стека (левый символ отношения), с текущим символом входной цепочки, обозреваемым считывающей головкой (правый символ отношения). При этом из стека надо выбрать самый верхний терминальный символ, игнорируя все возможные нетерминальные символы.
Шаг 3. Если имеет место отношение <• или =•, то произвести сдвиг (перенос текущего символа из входной цепочки в стек и сдвиг считывающей головки на один шаг вправо) и вернуться к шагу 2. Иначе перейти к шагу 4.
Шаг 4. Если имеет место отношение •>, то произвести свертку. Для этого надо найти на вершине стека все терминальные символы, связанные отношением =• («основу»), а также все соседствующие с ними нетерминальные символы (при определении отношения нетерминальные символы игнорируются). Если терминальных символов, связанных отношением =•, на верхушке стека нет, то в качестве основы используется один, самый верхний в стеке терминальный символ стека. Все (и терминальные, и нетерминальные) символы, составляющие основу, надо удалить из стека, а затем выбрать из грамматики правило, имеющее правую часть, совпадающую с основой, и поместить в стек левую часть выбранного правила. Если правило, совпадающее с основой, найти не удалось, то необходимо
прервать выполнение алгоритма и сообщить об ошибке, иначе, если разбор не 2 一 кончен, то вернуться к шагу 2.
Шаг 5. Если не установлено ни одно отношение предшествования между текут, символом входной цепочки и самым верхним терминальным символом в сте- то надо прервать выполнение алгоритма и сообщить об ошибке.
Конечная конфигурация данного МП-автомата совпадает с конфигурацией п; распознавании цепочек грамматик простого предшествования.
Пример построения распознавателя для грамматики операторного предшествования
Рассмотрим в качестве примера грамматику для арифметических выражений символами а и b G({+,-./.*.a,b},{S.T,E},P.S):
Р:
S -> S+T I S-Т I т
Т -> Т*Е I T/E I Е
Е - (S) I a I b
Эта грамматика уже много раз использовалась в качестве примера для пост] ния распознавателей.1
Видно, что эта грамматика является грамматикой операторного предшествования Построим множества крайних левых и крайних правых символов L(A), R(A) относительно всех нетерминальных символов грамматики. Рассмотрим работу а.т- горитма построения этих множеств по шагам.
Шаг 7.
LO(S) = {S.T}. R0(S) = {Т},
L0(T) = {Т.Е}. R0(T) = {Е}.
LO(E) = {(.a.b}.R0(E) = {),a,b}, i = 1
Шаг 2.
LKS) = {S,T.E},R1(S) = {T},
LKT) = {T,E,(.a,b}. R1(T) = {E},
LKE) = {(.a.b},RKE) = {),a,b}
Шаг 3. Так как L0(S) к L(S), то 1 = 2, и возвращаемся к шагу 2.
Шаг 2.
L2(S) = {S,T.E.(.a,b}. R2(S) = {Т},-
L2(T) = {T.E.(.a.b}. R2(T) = {E},
L2(E) = {(.d.b},R2(E) = {).a,b}
Шаг 3. Так как L/S) ^ L2(S), to i = 3, и возвращаемся к шагу 2.
Шаг 2
L3(S) = {S,T,E.(.a.b}. R3(S) = {T}.
L3(T) = {T,E,(.a.b}. R3(T) = {E}.
L3(E) = {(,a,b}.R3(E) = {).a.b}
Построение закончено.
Получили результат:
L(S) = {S,T.E,(.a.b}. R(S) = {Т}.
L(T) = {T.E.(,a.b}.R(T) = {E}.
L(E) = {(.a.b}, R(E) = {)ab}
На основе полученных множеств построим множества крайних левых и крайних правых терминальных символов Lt(A), Rt(A) относительно всех нетерминальных символов грамматики. Рассмотрим работу алгоритма построения этих множеств по шагам.
Шаг 1.
LtO(S) = {+.-}• RtO(S) = {+,-}•
LtO(T) = {*./}. RtO(T) = {*./}.
LtO(E) = {(.a.b}. RtO(E) = {).a.b}. 1 = 1
Шаг 2.
Ltl(S) = {+.-.*./.(.a.b}. Rtl(S) = {+,-.*./},
Ltl(T) = {*./,(,a.b}. Rtl(T) = {*,/,),a.b},
Ltl(E) = {(.a.b}, Rtl(E) = {).a.b}
Шаг 3. Так как Ll0(S) к L8(S), то i = 2, и возвращаемся к шагу 2.
Шаг 2.
Lt2(S) = {+,-,*,/,(.a.b}, Rt2(S) = {+,-,*./,),a,b}.
Lt2(T) = {*./.(.a.b}. Rt2(T) = {*./.).a.b}.
Lt2(E) = {(.a.b}. Rt2(E) = {),a,b}
Шаг 3. Так как RS(S) ^ R^CS), to 1 = 3, и возвращаемся к шагу 2.
Шаг 2
Lt3(S) =/.(.a.b}, Rt3(S) = {+,-,*./,),a,b},
Lt3(T) = {*./.(,a.b}. Rt3(T) = {*./.),a.b},
Lt3(E) = {(.a.b}. Rt3(E) = {),a,b}
Построение закончено.
Получили результат:
Lt(S) = {+.-.*./.(.a.b}. Rt(S) = {+,-,*,/,),a,b}.
Lt(T) = {*,/,(,a.b}. Rt(T) = {*,/,),a.b},
Lt(E) = {(.a,b},Rt(E) = {).a,b}
На основе этих множеств и правил грамматики G построим матрицу предшествования грамматики (табл. 4.6).
Поясним, как заполняется матрица предшествования в таблице на примере символа +. В правиле грамматики S—S+T (правило 1) этот символ стоит слева от нетерминального символа Т. В множество Lt(T) входят символы: *, /, (, а, Ь. Ставим знак <• в клетках матрицы, соответствующих этим символам, в строке для символа +. В то же время в этом же правиле символ + стоит справа от нетерминального символа S. Во множество Rt(S) входят символы: +, -, *，/, ), а, Ь. Ставим знак •>
в клетках матрицы, соответствующих этим символам, в столбце для символа - Больше символ + ни в каком правиле не встречается, значит, заполнение матр; цы для него закончено, берем следующий символ и продолжаем заполнять ма: рицу таким же методом, пока не переберем все терминальные символы.
Таблица 4.6. Матрица предшествования грамматики
Символы
+
-
*
/
(
)
a
b
丄к
+
>
>
v・
v・
<.
・>
<•
<•
•>
-
>
>
<•
<.
<.
•>
<•
<.
•>
*
>
>
•>
•>
v・
•>
<.
<•
•>
/
>
>
•>
<•
•>
<•
<.
>
(
v・
<.
<.
<•
<
=■
<•
<.
)
>
•>
>
•>
・>
а
.>
•>
.>
>
>
.>
b
>
->
>
>
〉
<•
<.
<•
<.
<.
<.
Отдельно рассмотрим символы 丄н и 丄к. В строке символа 丄н ставим знак <• в клетках символов, входящих во множество Lt(S). Это символы +,-,*,/,(, а, Ь. В столбце символа 丄к ставим знак •> в клетках символов, входящих во множество Rt(S Это символы +, —, *,/,), а, Ь.
Еще можно отметить, что в клетке, соответствующей открывающей скобке (символ ()слева и закрывающей скобке (символ )) справа, помещается знак =• («составляют основу»). Так происходит, поскольку в грамматике присутствует правило Е-» (S), где эти символы стоят рядом (через нетерминальный символ) в его правой части. Следует отметить, что понятия «справа» и «слева» здесь имеют важное значение: в клетке, соответствующей закрывающей скобке (символ )) слева и открывающей скобке (символ () справа, знак отсутствует — такое сочетание символов недопустимо (отношение (=•) верно, а отношение )=•( — неверно). Алгоритм разбора цепочек грамматики операторного предшествования игнорирует нетерминальные символы. Поэтому имеет смысл преобразовать исходную грамматику таким образом, чтобы оставить в ней только один нетерминальный символ. Тогда получим следующий вид правил:
Р:
S тS+SIS-SIS (правила 1, 2и 3)
S тS*SIS/SIS (правила 4, 5и 6)
S ->(S)Ia Ib(правила 7, 8 и9)
Если теперь исключить бессмысленные правила вида S->S, то получим следующее множество правил (нумерацию правил сохраним в соответствии с исходной грамматикой):
Р:
S — S+S I S-S (правила 1, 2)
S — S*S I S/S (правила 4, 5)
S -> (S) I a I b (правила 7, 8 и 9)
Такое преобразование не ведет к созданию эквивалентной грамматики и выполняется только для упрощения работы алгоритма (который при выборе правил все равно игнорирует нетерминальные символы) после построения матрицы предшествования. Полученная в результате преобразования грамматика не является однозначной, но в алгоритм распознавания уже были заложены все необходимые данные о порядке применения правил при создании матрицы предшествования, поэтому распознаватель остается детерминированным. Построенная таким способом грамматика называется остовной грамматикой. Вывод, полученный при разборе на основе остовной грамматики, называют результатом остовного разбора, или остовным выводом [4, т. 1, 2].
По результатам остовного разбора можно построить соответствующий ему вывод на основе правил исходной грамматики. Однако эта задача не представляет практического интереса, поскольку остовный вывод отличается от вывода на основе исходной грамматики только тем, что в нем отсутствуют шаги, связанные с применением цепных правил, и не учитываются типы нетерминальных символов. Для компиляторов же распознавание цепочек входного языка заключается не в нахождении того или иного вывода, а в выявлении основных синтаксических конструкций исходной программы с целью построения на их основе цепочек языка результирующей программы. В этом смысле типы нетерминальных символов и цепные правила не несут никакой полезной информации, а, напротив, только усложняют обработку цепочки вывода. Поэтому для реального компилятора нахождение остовного вывода является даже более полезным, чем нахождение вывода на основе исходной грамматики. Найденный остовный вывод в дальнейших преобразованиях уже не нуждается1.
Рассмотрим работу алгоритма распознавания на примерах. Последовательность разбора будем записывать в виде последовательности конфигураций расширенного МП-автомата из трех составляющих:
не просмотренной автоматом части входной цепочки;
содержимого стека;
последовательности примененных правил грамматики.
Так как автомат имеет только одно состояние, то для определения его конфигурации достаточно двух составляющих — положения считывающей головки во входной цепочке и содержимого стека. Последовательность номеров правил несет дополнительную полезную информацию, по которой можно построить цепочку или дерево вывода.
Как и ранее, будем обозначать такт автомата: +п, если на данном такте выполнялся перенос, и +с, если выполнялась свертка.
Последовательности разбора цепочек входных символов будут, таким образом, иметь вид, приведенный ниже.
Из цепочки (и дерева) вывода удаляются цепные правила, которые, как будет показано далее, все равно не несут никакой полезной семантической (смысловой) нагрузки, а потому для компилятора являются бесполезными. Это положительное свойство распознавателя.
Пример 7. Входная цепочка а+а*Ь:
{а+а*Ь丄к；丄н；0}+п
{+а*Ь丄к；丄на；0}+с
{+а*Ь丄к;丄HS:8}+n
{a*b丄к:丄hS+:8}m
{*b丄к：丄HS+a：8}+c
{*blK：±HS+S;8.8}4-n
{b丄к;丄HS+S*;8,8}+n
{丄к：丄HS+S*b:8.8}+c
{丄к;丄hS+S*S;8,8.9}+c
{丄к;丄hS+S：8,8,9,4}+c
{±k：±hS:8,8,9,4.1} — разбор завершен, цепочка принята.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S => S+S => S+S*S n S+S*b => S+a*b => a+a*b.
Дерево вывода, соответствующее этой цепочке, приведено на рис. 4.13.
Рис. 4.13. Пример дерева вывода для грамматики операторного предшествования
Пример 2. Входная цепочка (а+а)*Ь:
{(а+а)*Ь丄к：丄н;0}+п
{а+а)*Ык；1н(；0}-гп
{+а)*Ь丄к：丄н(а：0}+с
{+а)*Ь丄к;丄H(S:8}+n
{a)*b丄к；丄H(S+:8}+n
{)*b±K；±H(S+a;8}H-c
{)*b丄к：丄h(S+S;8,8}+c
{)*b丄к：丄H(S;8,8」}+n
{*b丄к；丄h(S):8,8」}+c
{*Ык：1н5:8.8,1.7}4-п
".{b丄к：丄hS*;8aL7}+n
{丄к；丄HS*b:8,8,L7}+c
{丄к；丄hS*S;8,8,L7,9}+c
{丄к；丄hS:8,8,L7,9,4} — разбор завершен, цепочка принята.
Соответствующая цепочка вывода будет иметь вид (используется правосторонний вывод): S n S*S n S*b n (S)*b n (S+S)*b n (S+a)*b п (а+а)*Ь.
Дерево вывода, соответствующее этой цепочке, приведено на рис. 4.14.
Рис. 4.14. Пример дерева вывода для грамматики операторного предшествования
Пример 3. Входная цепочка а+а*:
{а+а*丄к；丄н：0}+п
{+а*丄к；丄на；0}+с
{+а*丄к；丄HS;8}+n
{а*丄к：丄hS+；8}xi
{*丄k；丄HS+a ：8}еС
{*±K；±HS+S：8.8}-e-n
{丄 к：丄 hS+S*;8,8}+c
ошибка! (нет правила для выполнения свертки на этом шаге).
Пример 4. Входная цепочка а+а)*Ь:
{а+а)*Ь丄к：丄н：0}+п
{+а)*Ь丄к；丄на:0}+с
{+а)*Ь丄к；丄hS;8}+d
{a)*b；丄hS+:7}+d
{)*b丄к：丄hS+h；8}+c
{)*blK；±HS+S:8,8}4-c
{)*b±K：lHS：8,8,l}
ошибка! (нет отношений предшествования между символами ±н и )).
Два первых примера наглядно демонстрируют, что приоритет операций, установленный в грамматике, влияет на последовательность разбора и последовательность применения правил несмотря на то, что нетерминальные символы распознавателем не учитываются.
Как было сказано выше, матрица для грамматики операторного предшествования всегда имеет меньший объем, чем матрица для эквивалентной ей граммапг ки простого предшествования. Кроме того, распознаватель грамматики операторного предшествования игнорирует нетерминальные символы в процессе разбора а значит, не учитывает цепные правила, делает меньше шагов и порождает более короткую цепочку вывода. Поэтому распознаватель для грамматики операторного предшествования всегда проще, чем распознаватель для эквивалентной ей грамматики простого предшествования.
Интересно, что поскольку распознаватель на основе грамматик операторной: предшествования не учитывает типы нетерминальных символов, то он может работать даже с неоднозначными грамматиками, в которых есть правила, различающиеся только типами нетерминальных символов. Примером такой грамматики может служить грамматика G"({a.b),{S.A.B}.P.S) с правилами:
Р：
S -» А I В
А -> aAb I ab
В —> зВЬ I ab
Как и для любой другой грамматики операторного предшествования, распознаватель для этой грамматики будет детерминированным. Остовная грамматика, построенная на ее основе, будет иметь только два правила вида: S->aSb | ab. Неоднозначность заключается в том, что каждому найденному остовному выводу будет соответствовать не один, а несколько выводов в исходной грамматике (в данном случае — всегда два вывода в зависимости от того, какое правило из S->A| В будет применено на первом шаге вывода).
ПРИМЕЧАНИЕ
Грамматики, содержащие правила, различающиеся только типами нетерминальных символов, практического значения не имеют, а потому интереса для компиляторов не представляют.
Хотя классы грамматик простого и операторного предшествования несопоставимы1, класс языков операторного предшествования уже, чем класс языков простого предшествования. Поэтому не всегда возможно для языка, заданного грамматикой простого предшествования, построить грамматику операторного предшествования. Поскольку класс языков, заданных грамматиками операторного предшествования, еще более узок, чем даже класс языков, заданных грамматиками простого предшествования, с помощью этих грамматик можно опреде-
В том, что эти два класса грамматик несопоставимы, можно убедится, рассмотрев два приведенных выше примера — в них взяты различные по своей сути и классам грамматики, хотя они и являются эквивалентными — задают один и тот же язык.
лить далеко не каждый детерминированный КС-язык. Грамматики операторного предшествования — это очень удобный инструмент для построения распознавателей, но они имеют ограниченную область применения.
Контрольные вопросы и задачи
Вопросы
Какие из следующих утверждений справедливы:
Q если язык задан КС-грамматикой, то он может быть задан с помощью МП- автомата;
Q если язык задан КС-грамматикой, то он может быть задан с помощью ДМП-автомата;
Q если язык задан ДМП-автоматом, то он может быть задан КС-граматикой;
О если язык задан однозначной КС-грамматикой, то он может быть задан с помощью ДМП-автомата;
О если язык задан расширенным МП-автоматом, то он может быть задан КС-грамматикой?
Алфавит магазинных символов МП-автомата включает в себя алфавит входных символов автомата. Почему?
Какие из приведенных ниже МП-автоматов являются детерминированными: Rl({ql,q2).{a.b},{a,b.A},31,ql,A,{q2}).51(ql.a.A) = {(ql,АА)},31(q2,a.А)= {(q2A)},31(ql,b.A) = {(q乙A)} Bl(q2,b.A) = {(q2,Aab)} ,31(ql A.a)= {(qlA)},31(qlA,b) = {(qL 入)}: R2({q}.{a.b},{a.b.A}.32.q.A.{q}).32(q,a,A) = {(q.AA)},52(q,b,A)= {(q,A)},52(qA,a) = {(qA)} ,32(q A.b) = {(qA)} ,32(q A.A) = {(q.A)}： R3({q}.{a.b}.{a.b.A}.53.q,A.{q}).53(q.a.A) = {(q.AA).(q.a).(qA)},53(q,b.A)= {(q.A)}.53(qA.a) = {(q.A)};
R4({q}.{a,b}.{a.b.A}.34,q.A.{q})t34(qta.A) = {(q.AAb)},34(q.b.A)= {(q,a)},54(qA,a) = {(qA)} ,54(q A.b) = {(q4)}
Почему синтаксические конструкции языков программирования могут быть распознаны с помощью ДМП-автоматов? Можно ли полностью проверить структуру входной программы с помощью ДМП-автоматов для большинства языков программирования? Если нет, то можно ли решить ту же задачу, используя МП-автоматы или расширенные МП-автоматы?
Если проблема однозначности неразрешима для произвольной КС-грамматики, то почему можно утверждать, что некоторые КС-грамматики являются однозначными? Всегда ли должны быть однозначными грамматики синтаксических конструкций языков программирования?,
Какой цели служит преобразование правил КС-грамматик? Всегда ли это преобразование ведет к упрощению правил?
Почему при преобразовании КС-грамматики к приведенному виду сначала необходимо удалить бесплодные символы, а потом — недостижимые символы?
Почему для языка, заданного грамматикой, содержащей Х-правила и циклы существуют трудности с моделированием работы расширенного МП-автом та, выполняющего восходящий разбор с правосторонним выводом? Что мол но сказать об обычном МП-автомате, выполняющем нисходящий разбор д二； цепочек, построенных с помощью таких грамматик?
Почему необходимо устранить именно левую рекурсию из правил грамматик! Для моделирования работы какого (восходящего или нисходящего) растюзн. вателя представляет сложность левая рекурсия? Можно ли полностью устр нить рекурсию из правил грамматики, записанных в форме Вэкуса—Наур.
Сравните восходящий и нисходящий распознаватели. Какими преимуществ- ми и недостатками обладает каждый из этих методов?
И. В чем главное преимущество линейных распознавателей для КС-языков m ред всеми другими видами распознавателей? Какие существуют сложност в построении линейных распознавателей для КС-языков?
На алгоритме какого распознавателя основан метод рекурсивного спускг. В чем заключается принципиальное изменение, внесенное в алгоритм? Веде ли это изменение к ограничению применимости данного алгоритма?
Какие преобразования возможно выполнить над грамматикой, чтобы к не был применим метод рекурсивного спуска? Можно ли формализовать и автч - матизировать выполнение этих преобразований? Можно ли реализовать распознаватель по методу расширенного рекурсивного спуска для грамматик! содержащей левую рекурсию?
За счет чего класс LL⑴-грамматик является более широким, чем класс КС- грамматик, для которых можно построить распознаватель по методу рекурсивного спуска?
На каком алгоритме основана работа распознавателя для ЬЬ(к)-грамматик1 Какие изменения внесены в алгоритм? Насколько они сузили применимое? данного алгоритма?
Почему класс языков, заданных LR-грамматиками, является более шнрокн、 чем класс языков, заданных LL-грамматиками?
На каком алгоритме основана работа распознавателя для ЬН(к)-грамматики Какие изменения внесены в алгоритм? Насколько они сузили применимост данного алгоритма?
Почему не существует языков, заданных ЬЬ(О)-грамматиками, но существ% - ют языки, заданные ЬИ(О)-грамматиками?
Почему можно утверждать, что любая LL-грамматика и любая LR-грамматика являются однозначными?
В чем особенности реализации алгоритма типа «сдвиг-свертка» для грамматик простого и операторного предшествования? Какие ограничения эти особенности накладывают на правила грамматики?
Почему в грамматике простого предшествования не могут присутствовать цепные правила, а в грамматике операторного предшествования — могут? Почему в обоих классах грамматик не могут присутствовать Х-правила?
!2. Распознаватели на основе грамматик операторного предшествования имеют массу преимуществ перед распознавателями на основе грамматик простого предшествования. Почему же, тем не менее, используются оба класса КС-грамматик?
!3. Класс языков, заданных LR( 1 )-грамматиками совпадает с классом детерминированных КС-языков. Зачем же тогда используются другие классы грамматик?
Задачи
Задана грамматика G({".", + , - ,0,1}. {<число>,<часть>,<цифра>,<осн>} ,Р,<число>)
Р:
<ЧИСЛО> -> +<ОСН> I -<ОСН> I <осн>
<осн.> -> <часть>.<часть> | <часть>. | <часть>
<часть> -> <цифра> | <часть><цифра>
<цифра> -> 0 I 1
Постройте для нее обычный и расширенный МП-автоматы.
Являются ли построенные автоматы детерминированными?
PSABCEDFGPSABCEDFGДана грамматика G({a,b.c},{A.B,C,D,E,F,G,S},P,S)
PSABCEDFG
PSABCEDFG
-> аАЬВ I Е
—> ВСа I а I А,
—АСЬ I b I 九
-> А I В IЬА IаВ IсСIаЕI ЬЕ
-» ЕаIEbIЕсIEDIFGIDG
-» с I Fb I Fa I 九
ВСIACIDCIЕС
-» GaIGbIGcIGD
Преобразуйте ее к приведенному виду.
Дана грамматика G(("о. г, а, n, d. t. b},{S. Т, Е. F}. Р, S)
Р:
S -> S or Т I Т
Т — Т and Е I Е
Е — not Е I F
F - (S) I b
О Преобразуйте ее к виду без цепных правил.
О Исключите левую рекурсию в правилах грамматики.
Постройте нисходящий распознаватель с возвратом для грамматики, заданной в задаче № 3. Выполните разбор цепочки символов «а or a and not a and (a or not not a)».
Постройте восходящий распознаватель с возвратом для грамматики, заданной в задаче № 3. Выполните разбор цепочки символов «а or a and not a and (a or not not a)»..
Постройте распознаватель, основанный на методе рекурсивного спуска для грамматики G({a,b,c}. {S,A,B,C} .P.S).
Р:
S -> aABb I ЬВАа | сСс
А — аА I ЬВ I сС
В — b I аАС
С -» аА I ЬА I сС
Выполните разбор цепочки символов aabbabbcabbb.
Постройте распознаватель, основанный на расширенном методе рекурсивного спуска для грамматики: G({a,<, = ,>. + ,-./,*}.{S,T,E}.P.S)
Р:
S г Т<Т I Т>Т I Т<=Т I т>=т
Т г Т+Е I Т-Е I Е
Е -> а*а I а/а | а
Выполните разбор цепочки символов а*а+а<а/а-а*а.
Дана грамматика G({(, ), + ,*,а}, {S.T.F} .P.S)
Р:
S г S+T I Т
Т Т*Е I F
F - (S) I а
Постройте для нее распознаватель на основе 8ЬН(1)-грамматики.
Дана грамматика G({(. а}, {S.T.E.F} .P.S)
Р:
S — ST I т
Т f Т&Е I Е
Е г ~Е I F
F г ⑸ I а
Постройте для нее распознаватель на основе грамматики операторного предшествования. Выполните разбор цепочки символов а人а&~а&(а^~~а).
Придумайте функцию линеаризации матрицы предшествования для грамматики, заданной в задаче № 8.
И. Дана грамматика: G({1f ,then,else,a.b} ,{S,T.E,F},P,S)
Р：
S г if b then T else S | if b then S | a
T r if b then T else S | a
Постройте для нее распознаватель на основе грамматики операторного предшествования, считая if, then и else едиными терминальными символами. Является ли данная грамматика однозначной? Выполните разбор цепочки символов if b then if b then if b then a else а. К первому или к последнему if будет отнесено else в этой цепочке? '
Перестройте правила грамматики, данной в задаче № 10 так, чтобы else всегда относилось к объемлющему 1 f, а не к ближайшему.
Придумайте функцию линеаризации матрицы предшествования для грамматики, заданной в задаче № 10.
Глава 5 Генерация и оптимизация кода
Семантический анализ и подготовка к генерации кода
Назначение семантического анализа
Здесь уже неоднократно упоминалось, что практически все языки программирования, строго говоря, не являются КС-языками. Поэтому полный разбор исходной программы компилятор не может выполнить в рамках КС-языков с помощью КС-грамматик и МП-автоматов. Полный распознаватель для большинства языков программирования может быть построен в рамках КЗ-языков, поскольку все реальные языки программирования контекстно-зависимы1.
Итак, полный распознаватель для языка программирования можно построить на основе распознавателя КЗ-языка. Однако известно, что такой распознаватель имеет экспоненциальную зависимость требуемых для выполнения разбора исходной программы вычислительных ресурсов от длины входной цепочки [4, т. 1, 15]. Компилятор, построенный на основе такого распознавателя, будет неэффективным с точки зрения скорости работы (либо объема необходимой памяти). Поэтому такие компиляторы практически не используются, а все реально существующие компиляторы выполняют анализ исходной программы в два этапа: первый — синтаксический анализ на основе распознавателя для одного из известных классов КС-языков; второй — семантический анализ.
Для проверки семантической правильности исходной программы необходимо иметь всю информацию о найденных лексических единицах языка. Эта инфор-
Примером контекстной зависимости, часто встречающейся во многих языках программирования, может служить необходимость предварительно описать идентификатор до его первого использования.
мация помещается в таблицу лексем на основе конструкций, найденных синтаксическим распознавателем. Примерами таких конструкций являются блоки описания констант и идентификаторов (если они предусмотрены семантикой языка) или операторы, где тот или иной идентификатор встречается впервые (если семантика языка предусматривает описание идентификатора по факту его первого использования). Поэтому семантический анализ входной программы может быть произведен только после завершения ее синтаксического анализа.
Таким образом, входными данными для семантического анализа служат:
таблица идентификаторов;
口 результаты разбора синтаксических конструкций входного языка.
Результаты выполнения синтаксического анализа могут быть представлены в одной из форм внутреннего представления программы в компиляторе. Как правило, на этапе семантического анализа используются различные варианты синтаксических деревьев, построенных в результате синтаксического разбора, поскольку семантический анализатор интересует прежде всего структура исходной программы. Семантический анализ обычно выполняется на двух этапах компиляции: на этапе синтаксического разбора и в начале этапа подготовки к генерации кода. В первом случае всякий раз по завершении анализа определенной синтаксической конструкции входного языка выполняется ее семантическая проверка на основе имеющихся в таблице идентификаторов данных (такими конструкциями, как правило, являются процедуры, функции и блоки операторов входного языка). Во втором случае, после завершения всей фазы синтаксического анализа, выполняется полный семантический анализ программы на основании данных в таблице идентификаторов (сюда попадает, например, поиск неописанных идентификаторов). Иногда семантический анализ выделяют в отдельный этап (фазу) компиляции.
В каждом компиляторе обычно присутствуют оба варианта семантического анализатора. Конкретная их реализация зависит от версии компилятора и семантики входного языка [4, т. 2, 31, 50, 52].
Этапы семантического анализа
Семантический анализатор выполняет следующие основные действия:
проверку соблюдения во входной программе семантических соглашений входного языка;
дополнение внутреннего представления программы в компиляторе операторами и действиями, неявно предусмотренными семантикой входного языка;
проверку элементарных семантических (смысловых) норм языков лрограм- мирования, напрямую не связанных со входным языком.
Проверка соблюдения во входной программе семантических соглашений
Эта проверка заключается в сопоставлении входных цепочек исходной программы с требованиями семантики входного языка программирования. Каждый язык
программирования имеет четко заданные и специфицированные семантические соглашения, которые не могут быть проверены на этапе синтаксического разбора. Именно их в первую очередь проверяет семантический анализатор.
Примерами таких соглашений являются следующие требования:
каждая метка, на которую есть ссылка, должна один раз присутствовать в программе;
каждый идентификатор должен быть описан один раз и ни один идентификатор не может быть описан более одного раза (с учетом блочной структуры описаний);
все операнды в выражениях и операциях должны иметь типы, допустимые для данного выражения или операции;
типы переменных в выражениях должны быть согласованы между собой;
при вызове процедур и функций число и типы фактических параметров должны быть согласованы с числом и типами формальных параметров.
Это только примерный перечень такого рода требований. Конкретный состав требований, которые должен проверять семантический анализатор, жестко связан с семантикой входного языка (например, некоторые языки допускают не описывать идентификаторы определенных типов). Варианты реализаций такого рода семантических анализаторов детально рассмотрены в [4, т. 2, 50].
Например, если мы возьмем оператор языка Pascal, имеющий вид:
а ：= b + с；
то с точки зрения синтаксического разбора это будет абсолютно правильный оператор. Однако нельзя сказать, является ли этот оператор правильным с точки зрения входного языка (Pascal), пока не будут проверены семантические требования для всех входящих в него лексических элементов. Такими элементами здесь являются идентификаторы а, b и с. Не зная, что они собой представляют, невозможно не только окончательно утверждать правильность приведенного выше оператора, но и понять его смысл. Фактически, необходимо знать описание этих идентификаторов.
В том случае, если хотя бы один из них не описан, имеет место явная ошибка. Если это числовые переменные и константы, то это оператор сложения, если же это строковые переменные и константы — оператор конкатенации строк. Кроме того, идентификатор а, например, ни в коем случае не может быть константой — иначе будет нарушена семантика оператора присваивания. Также невозможно, чтобы одни из идентификаторов были числами, а другие — строками или, скажем, идентификаторами массивов или структур — такое сочетание аргументов для операции сложения недопустимо. И это только некоторая часть соглашений, которые должен проверить компилятор с точки зрения семантики входного языка (в данном примере — Pascal).
ВНИМАНИЕ
Следует отметить, что от семантических соглашений зависит не только правильность оператора, но и его смысл.
Действительно, операции алгебраического сложения и конкатенации строк им ют различный смысл, хотя и обозначаются в рассмотренном примере одним зн_ ком операции — +. Следовательно, от семантического анализа зависит также кс 二 результирующей программы.
Если какое-либо из семантических требований входного языка не выполняете = то компилятор выдает сообщение об ошибке и процесс компиляции на этом, к「 правило, прекращается.
Дополнение внутреннего представления программы
Это дополнение внутреннего представления программы связано с добавление1- в него операторов и действий, неявно предусмотренных семантикой входное языка. Как правило, эти операторы и действия связаны с преобразованием типе: операндов в выражениях и при передаче параметров в процедуры и функции. Если вернуться к рассмотренному выше элементарному оператору языка Pascal а := b + с;
то можно отметить, что здесь выполняются две операции: одна операция сложения (или конкатенации, в зависимости от типов операндов) и одна операци.- присвоения результата. Соответствующим образом должен быть порожден и ко二 результирующей программы.
Однако не все так очевидно просто. Допустим, что где-то перед рассмотренных оператором мы имеем описание его операндов в виде:
var
а : double；
b ： Integer：
с : real ；
из этого описания следует, что с — вещественная переменная языка Pascal, b — целочисленная переменная, а — вещественная переменная с двойной точностью Тогда смысл рассмотренного оператора с точки зрения входной программы существенным образом меняется, поскольку в языке Pascal нельзя напрямую выполнять операции над операндами различных типов. Существуют правила преобразования типов, принятые для данного языка. Кто выполняет эти преобразования?
Это может сделать разработчик программы — но тогда преобразования типое в явном виде должны будут присутствовать в тексте входной программы. Для рассмотренного примера это выглядело бы примерно так:
а ：= double(real(Ь) + с);
В ряде случаев явное указание операций преобразования типов для входного языка является обязательным. Кроме того, разработчик исходной программы может использовать преобразования типов, отличные от предусмотренных входным языком по умолчанию, и в этом случае он также должен явно указать их. Например, оператор, описанный ниже:
а ：= double(b + trunc(c)):
выполняет целочисленное сложение, в отличие от ранее приведенного оператора, который выполнял сложение с плавающей точкой. При этом он использует преобразования типов, отличные от преобразований, предусмотренных языком Pascal. Результат выполнения операторов исходной программы может кардинально отличаться в зависимости от используемых преобразований типов. Например, если предположить, что перед выполнением рассматриваемого оператора его операнды будут иметь значения Ь = 1ис = 2.5, тов результате выполнения первого варианта оператора (операция сложения с плавающей точкой) переменная а получит значение 3.5, а в результате выполнения второго варианта оператора (целочисленное сложение) — 3.
Однако разработчик исходной программы может не указывать явно используемые преобразования типов. Тогда необходимые преобразования типов выполняет код, порождаемый компилятором, если эти преобразования предусмотрены семантическими соглашениями языка. Для этого в составе библиотек функций, доступных компилятору, должны быть функции преобразования типов (более подробно состав библиотек функций компилятора описан в главе 6 «Современные системы программирования»). Вызовы этих функций как раз и будут включены компилятором в текст результирующей программы для удовлетворения семантических соглашений о преобразованиях типов во входном языке, хотя в тексте исходной программы в явном виде они не присутствуют. Чтобы это произошло, эти функции должны быть встроены и во внутреннее представление программы в компиляторе. За это также отвечает семантический анализатор.
При отсутствии явно указанных преобразований типов в рассмотренном примере будет не две, а четыре операции: преобразование целочисленной переменной b в формат вещественных чисел; сложение двух вещественных чисел; преобразование результата в вещественное число с двойной точностью; присвоение результата переменной а. Количество операций возросло вдвое, причем добавились два вызова весьма нетривиальных функций преобразования типов. Разработчик программы должен помнить об этом, если хочет добиться высокой эффективности результирующего кода.
СОВЕТ
Явное указание преобразований типов, особенно для принципиально важных операторов, является хорошим стилем программирования и позволяет избежать трудно обнаруживаемых семантических ошибок.
Преобразование типов — это только один вариант операций, неявно добавляемых компилятором в код результирующей программы на основе семантических соглашений. Другим примером такого рода операций могут служить операции вычисления адреса, когда происходит обращение к элементам сложных структур данных. Существуют и другие варианты такого рода операций (преобразование типов — самый распространенный пример).
Таким образом, и в этом случае действия, выполняемые семантическим анализатором, существенным образом влияют на порождаемый компилятором код результирующей программы.
Проверка смысловых норм языков программирования
Проверка элементарных смысловых норм языков программирования, напрямук не связанных со входным языком, — это сервисная функция, которую предоставляют разработчикам большинство современных компиляторов. Эта функция обеспечивает проверку компилятором соглашений, выполнение которых связанс со смыслом как всей исходной программы в целом, так и отдельных ее фрагментов. Эти соглашения применимы к большинству современных языков программирования.
Примерами таких соглашений являются следующие требования:
каждая переменная или константа должна хотя бы один раз использоваться в программе;
каждая переменная должна быть определена до ее первого использования при любом ходе выполнения программы (первому использованию переменной должно всегда предшествовать присвоение ей какого-либо значения);
результат функции должен быть определен при любом ходе ее выполнения
каждый оператор в исходной программе должен иметь возможность хотя бы один раз выполниться;
операторы условия и выбора должны предусматривать возможность хода выполнения программы по каждой из своих ветвей;
операторы цикла должны предусматривать возможность завершения цикла. Конечно, это только примерный перечень основных соглашений. Конкретный состав проверяемых соглашений зависит от семантики языка.
ПРИМЕЧАНИЕ
В отличие от семантических требований языка, строго проверяемых семантическим анализатором, выполнение данных соглашений не является обязательным.
То, какие конкретно соглашения будут проверяться и как они будут обрабатываться, зависит от качества компилятора, от функций, заложенных в него разработчиками. Простейший компилятор вообще может не выполнять этот этап семантического анализа и не проверять ни одного такого соглашения1.
Необязательность соглашений такого типа накладывает еще одну особенность на их обработку в семантическом анализаторе: их несоблюдение не может трактоваться как ошибка. Даже если компилятор полностью уверен в своей «правоте», тот факт, что какое-то из указанных соглашений не соблюдается, не должен приводить к прекращению компиляции исходной программы. Обычно факт обнаружения несоблюдения такого рода соглашений трактуется компилятором как
Конечно, современные компиляторы, создаваемые известными фирмами-разработчиками стремятся выполнить проверку максимально возможного числа такого рода соглашений Эта функция обычно преподносится как одно из достоинств компилятора и способствует завоеванию им хороших позиций на рынке.
«предупреждение» (warning). Компилятор выдает пользователю сообщение об обнаружении несоблюдения одного из требований, не прерывая сам процесс компиляции, — то есть он просто обращает внимание пользователя на то или иное место в исходной программе. То, как реагировать на «предупреждение» (вносить изменения в исходную программу или проигнорировать этот факт)— это уже забота и ответственность разработчика исходной программы.
Необязательность указанных соглашений объясняется тем, о чем уже говорилось выше в главе 2 «Основные принципы построения трансляторов» — ни один компилятор не способен полностью понять и оценить смысл исходной программы. А поскольку смысл программы доступен только человеку (для плохо написанной программы — только ее разработчику), то он и должен нести ответственность за выполнение семантических соглашений1.
Задача проверки выполнения семантических соглашений входного языка во многом связана с проблемой верификации программ. Эта проблема детально рассмотрена в [1, И, 18, 30, 33, 36, 40].
Рассмотрим в качестве примера функцию, представляющую собой фрагмент входной программы на языке С:
Int f_test(1nt а) { Int b.c： b = О； с = О： if (b=l) { return a； } c = a + b：
}
Практически любой современный компилятор языка С обнаружит в данном месте входной программы массу «неточностей». Например, переменная с описана, ей присваивается значение, но она нигде не используется; значение переменной Ь, присвоенное в операторе b = 0;, тоже никак не используется; наконец, условный оператор лишен смысла, так как всегда предусматривает ход выполнения только по одной своей ветке, а значит, и оператор с=а+Ь: никогда выполнен не будет. Скорее всего, компилятор выдаст еще одно предупреждение, характерное именно для языка С — в операторе 1f(b=l) присвоение стоит в условии (это не запрещено ни синтаксисом, ни семантикой языка, но является очень распространенной семантической ошибкой в языке С). В принципе, смысл (а точ-
Обычно хорошим стилем считается построить программу так, чтобы она компилировалась «без предупреждений» — то есть так, чтобы компилятор не обнаруживал в ней ни одного несоблюдения соглашений о смысле операторов входного языка. В большинстве случаев это возможно. Тем не менее, практически все современные компиляторы позволяют отключить в процессе компиляции программы проверку того или иного соглашения, вплоть до полного исключения всех возможных вариантов такого рода проверки. Эти соглашения входят в состав «опций» компиляторов. Следует отметить, что отключать можно только необязательные соглашения — ни одну проверку семантических требований языка отключить невозможно.
нее, бессмысленность) этого фрагмента будет правильно воспринят и обработа? компилятором.'
Однако если взять аналогичный по смыслу, но синтаксически более сложны? фрагмент программы, то картина будет несколько иная:
Int f_test_add(1nt* а, Int* b) {-一
*a = 1：.
*b = 0;
return *a：
}
int f_test(1nt a)
{ Int b.c：
b = 0：
if (f_test(&b,&c) != 0) { return a； } c = a + b:
}
Здесь компилятор уже вряд ли сможет выяснить порядок изменения значени! переменных и выполнение условий в данном фрагменте из двух функций (ост они сами по себе независимо вполне осмысленны!). Единственное предупреждение, которое, скорее всего, получит в данном случае разработчик, — это то, чт: функция f_test не всегда корректно возвращает результат (отсутствует операто; return перед концом функции). И то это предупреждение на самом деле не буае- соответствовать истинному положению вещей!
ПРИМЕЧАНИЕ
Проверка выполнения дополнительных семантических соглашений является весьма полезной функцией компиляторов, но ответственность за смысл исходной прс- граммы по-прежнему остается на ее разработчике.
Идентификация лексических единиц языков программирования
Идентификация переменных, типов, процедур, функций и других лексически?, единиц языков программирования — это установление однозначного соответствия между лексическими единицами и их именами в тексте исходной программы. Идентификация лексических единиц языка чаще всего выполняется на этапе семантического анализа.
Как правило, большинство языков программирования требуют, чтобы в исходной программе имена лексических единиц не совпадали как между собой, та-; и с ключевыми словами синтаксических конструкций языка. Но чаще всегс этого бывает недостаточно, чтобы установить однозначное соответствие межд； лексическими единицами и их именами, поскольку существуют дополнительные смысловые (семантические) ограничения, накладываемые языком на употребление этих имен.
СОВЕТ
Существуют языки программирования (например, PL/1), которые допускают, чтобы имена идентификаторов совпадали с ключевыми словами языка. В таких языках возможны весьма интересные синтаксические конструкции. Однако такая возможность не предоставляет ничего хорошего, кроме лишних хлопот разработчикам компилятора. Даже если такая особенность присуща входному языку, пользоваться ею настоятельно не рекомендуется — читаемость программы будет сильно затруднена, что говорит о плохом стиле программирования.
Например, локальные переменные в большинстве языков программирования имеют так называемую «область видимости», которая ограничивает употребление имени переменной рамками того блока исходной программы, где эта переменная описана. Это значит, что, с одной стороны, такая переменная не может быть использована вне пределов своей области видимости. С другой стороны, имя переменной может быть не уникальным, поскольку в двух различных областях видимости допускается существование двух различных переменных с одинаковым именем (причем в большинстве языков программирования, допускающих блочные структуры, области видимости переменных могут перекрываться). Другой пример такого рода ограничений на уникальность имен — это тот факт, что в языке программирования С две разные функции или процедуры с различными аргументами могут иметь одно и то же имя.
Безусловно, полный перечень таких ограничений зависит от семантики языка программирования. Все они четко заданы в описании языка и не могут допускать неоднозначности в толковании, но они также не могут быть полностью определены на этапе лексического анализа, а потому требуют от компилятора дополнительных действий на этапах синтаксического разбора и семантического анализа. Общая направленность этих действий такова, чтобы дать каждой лексической единице языка уникальное имя в пределах всей исходной программы и потом использовать это имя при синтезе результирующей программы.
Можно дать примерный перечень действий компиляторов для идентификации переменных, констант, функций, процедур и других лексических единиц языка:
имена локальных переменных дополняются именами тех блоков (функций, процедур), в которых эти переменные описаны;
имена внутренних переменных и функций модулей исходной программы дополняются именами самих модулей (это касается только внутренних имен);
имена процедур и функций, принадлежащих объектам (классам) в объектноориентированных языках программирования дополняются наименованиями типов объектов (классов), которым они принадлежат;
имена процедур и функций модифицируются в зависимости от типов их формальных аргументов.
Конечно, это далеко не полный перечень возможных действий компилятора, каждая реализация компилятора может предполагать свой набор действий.
То, какие из них будут использоваться и как они будут реализованы на прак- ке, зависит от языка исходной программы и разработчиков компилятора.
Как правило, уникальные имена, которые компилятор присваивает лексичесь единицам языка, используются только во внутреннем представлении исходи программы, и разработчик исходной программы не сталкивается с ними. Но с?, могут потребоваться ему в некоторых случаях — например, при отладке програ' мы, при порождении текста результирующей программы на языке ассемблер или при использовании библиотеки, созданной на другом языке программироь- ния (или даже с помощью другой версии компилятора). Тогда разработчик дс - жен знать, по каким правилам компилятор порождает уникальные имена 二；• лексических единиц исходной программы1.
СОВЕТ
Правила, по которым происходит модификация имен, достаточно просты. Их мс > но выяснить для конкретной версии компилятора и использовать при разработ.- Однако лучше этого не делать, так как нет гарантии, что при переходе к другой ви сии компилятора эти правила не изменятся — тогда код станет неработоспособны • Правильным средством будет аккуратное использование механизма отключен именования лексических единиц, предоставляемое синтаксисом исходного язы?_
Во многих современных языках программирования предусмотрены специальные настройки и ключевые слова, которые позволяют отключить процесс порождения компилятором уникальных имен для лексических единиц языка. Эти сло&£ входят в специальные синтаксические конструкции языка (как правило, это конструкции, содержащие слова export или external). Если пользователь использует эти средства, то компилятор не применяет механизм порождения уникальны! имен для указанных лексических единиц. В этом случае разработчик программа сам отвечает за уникальность имени данной лексической единицы в пределах всей исходной программы или даже в пределах всего проекта (если используются несколько исходных модулей). Если требование уникальности не будет выполняться, могут возникнуть синтаксические или семантические ошибки на ст二 дии компиляции либо же другие ошибки на более поздних этапах разработк программного обеспечения (эти этапы описаны далее в главе 6 «Современны- системы программирования»).
Чаще всего эта проблема относится к именам процедур или функций в библиотеках. Если корректно описать их, то использование объектного кода библиотеки не будет зависеть от типа компилятора и даже от входного язык2 (тут важно еще учесть соглашения о передаче параметров, которые рассмотрены далее).
Очень часто бывает, что пользователь не может вызвать и использовать по имени функцию (или процедуру), которая содержится в некоторой библиотеке. Сообщения компилятора вида «Функция такая-то не найдена» вызывают немало удивления, особенна когда пользователь сам создал библиотеку и точно знает, что эта функция в ней есть Чаще всего проблема связана с наименованием функций — компилятор дает функции в библиотеке не совсем то имя, которое дал ей пользователь в исходном коде.
Распределение памяти
Принципы распределения памяти
Распределение памяти — это процесс, который ставит в соответствие лексическим единицам исходной программы адрес, размер и атрибуты области памяти, необходимой для этой лексической единицы. Область памяти — это блок ячеек памяти, выделяемый для данных, каким-то образом объединенных логически. Логика таких объединений задается семантикой исходного языка.
Распределение памяти работает с лексическими единицами языка — переменными, константами, функциями и т. п. — и с информацией об этих единицах, полученной на этапах лексического и синтаксического анализа. Как правило, исходными данными для процесса распределения памяти в компиляторе служат таблица идентификаторов, построенная лексическим анализатором, и декларативная часть программы (так называемая «область описаний»), полученная в результате синтаксического анализа. Не во всех языках программирования декларативная часть программы присутствует явно, некоторые языки предусматривают дополнительные семантические правила для описания констант и переменных; кроме того, перед распределением памяти надо выполнить идентификацию лексических единиц языка. Поэтому распределение памяти выполняется уже после семантического анализа текста исходной программы.
Процесс распределения памяти в современных компиляторах, как правило, работает с относительными, а не абсолютными адресами ячеек памяти (разница между абсолютными и относительными адресами описана в разделе «Трансляция адресов. Настраивающий загрузчик» в главе 6 «Современные системы программирования»). Распределение памяти выполняется перед генерацией кода результирующей программы, потому что его результаты должны быть использованы в процессе генерации кода.
Каждую область памяти можно классифицировать по двум параметрам: в зависимости от ее роли в результирующей программе и в зависимости от способа ее распределения в ходе выполнения результирующей программы.
По роли области памяти в результирующей программе она бывает глобальная или локальная.
По способам распределения область памяти бывает статическая или динамическая. Динамическая память, в свою очередь, может распределяться либо разработчиком исходной программы (по командам разработчика), либо компилятором (автоматически).
Классификация областей памяти представлена на рис. 5.1.
Далеко не все лексические единицы языка требуют для себя выделения памяти. То, под какие элементы языка нужно выделять области памяти, а под какие нет, определяется исключительно реализацией компилятора и архитектурой используемой вычислительной системы. Так, целочисленные константы можно разместить в статической памяти, а можно непосредственно в тексте результирующей программы (это позволяют практически все современные вычислительные системы), то же самое относится и к константам с плавающей точкой, но их размещение в тексте программы допустимо не всегда. Кроме того, в целях экономии
памяти, занимаемой результирующей программой, под различные элементы языка компилятор может выделить одни и те же ячейки памяти. Например, в одной и той же области памяти могут быть размещены одинаковые строковые ков- станты или две различные локальные переменные, которые никогда не испог зуются одновременно.
Роль в результирующей программе
Способ распределения
Рис. 5.1. Область памяти в зависимости от ее роли и способа распределения
Виды переменных и областей памяти
Распределение памяти для переменных скалярных типов
Во всех языках программирования существует понятие так называемых «баз. вых типов данных», которые также называют основными или скалярными тип2 ми). Размер области памяти, необходимый для лексической единицы скалярног типа, считается заранее известным. Он определяется семантикой языка и арх; тектурой целевой вычислительной системы, на которой должна выполнять:； созданная компилятором результирующая программа.
Идеальным вариантом для разработчиков программ был бы такой компилятс; у которого размер памяти для базовых типов зависел бы только от семантик, языка. Но чаще всего зависимость результирующей программы от архитектура целевой вычислительной системы полностью исключить не удается. Создатели компиляторов и языков программирования предлагают механизмы, позволяющие свести эту зависимость к минимуму.
СОВЕТ !
Размер области памяти каждого скалярного типа данных фиксирован и известе - для определенной целевой вычислительной системы. Однако не рекомендуется неп:- средственно использовать его в тексте исходной программы, так как это ограничивав- переносимость программы. Вместо этого нужно использовать функции определи ния размера памяти, предоставляемые входным языком программирования.
Например, в языке программирования С базовыми типами данных являются типы char, int, long Int и т. п. (реально этих типов, конечно, больше, чем три), а в языке программирования Pascal — типы byte, char, word, Integer и т. п. Размер базового типа int в языке С для архитектуры компьютера на базе 16-разрядных процессоров составляет 2 байта, а для 32-разрядных процессоров — 4 байта. Разработчики исходной программы на этом языке, конечно, могут узнать данную информацию, но если ее использовать в исходной программе напрямую, то такая программа будет жестко привязана к конкретной архитектуре целевой вычислительной системы. Чтобы исключить эту зависимость, лучше использовать механизм определения размера памяти для типа данных, предоставляемый языком программирования, — в языке С это функция slzeof.
Распределение памяти для сложных структур данных
Для более сложных структур данных используются правила распределения памяти, определяемые семантикой (смыслом) этих структур. Эти правила достаточно просты и, в принципе, одинаковы во всех языках программирования.
Вот правила распределения памяти под основные виды структур данных:
для массивов — произведение числа элементов в массиве на размер памяти для одного элемента (то же правило применимо и для строк, но во многих языках строки содержат еще и дополнительную служебную информацию фиксированного объема);
для структур (записей с именованными полями) — сумма размеров памяти по всем полям структуры;
для объединений (союзов, общих областей, записей с вариантами) — размер максимального поля в объединении;
для реализации объектов (классов) — размер памяти для структуры с такими же именованными полями плюс память под служебную информацию объектно-ориентированного языка (как правило, фиксированного объема).
Формулы для вычисления объема памяти можно записать следующим образом: для массивов: VMac = П._1п(т;) * Уэл, где
п — размерность массива, пщ — количество элементов i-й размерности, Уэл — объем памяти для одного элемента;
для структур: VCTp = %1 Ju。吗'
где'
п — общее количество полей в структуре, У11оля. — объем памяти для i-ro поля Структуры;'
для объединений: VCTp = тах,_11ПУполя.,
где
п — общее количество полей в объединении, V"。^ — объем памяти для i-ro поля объединения.
Для более сложных структур данных входного языка объем памяти, отводимой под эти структуры данных, вычисляется рекурсивно. Например, если имеется
массив структур, то при вычислении объема отводимой под этот массив намят? для вычисления объема памяти, необходимой для одного элемента массив三 будет вызвана процедура вычисления памяти структуры. Такой подход опреде ления объема занимаемой памяти очень удобен, если декларативная часть язы?. представлена в виде дерева типов. Тогда для вычисления объема памяти, зан; маемой типом из каждой вершины дерева, нужно вычислить объем памяти дл- всех потомков этой вершины, а потом применить формулу, связанную непс- средственно с самой вершиной (этот механизм подобен механизму СУ-переводз. применяемому при генерации кода). Как раз такого типа древовидные конструкции строит синтаксический анализатор для декларативной части языка.
Выравнивание границ областей памяти
Говоря об объеме памяти, занимаемой различными лексическими единицам:- и структурами данных языка, следует упомянуть еще один момент, связанны:- с выравниванием границ областей памяти, отводимых для различных лексических единиц. Архитектура многих современных вычислительных систем пред； сматривает, что обработка данных выполняется более эффективно, если адрес по которому выбираются данные, кратен определенному числу байтов (как правило, это 2, 4, 8 или 16 байтов)1. Современные компиляторы учитывают особенности целевых вычислительных систем. При распределении данных они мог)т размещать области памяти под лексические единицы наиболее оптимальным образом. Поскольку не всегда размер памяти, отводимой под лексическую единицу, кратен указанному числу байтов, то в общем объеме памяти, отводимой под результирующую программу, могут появляться неиспользуемые области.
Например, если мы имеем описание переменных на языке С:
static char cl, с2, сЗ;
то, зная, что под одну переменную типа char отводится 1 байт памяти, можем ожидать, что для описанных выше переменных потребуется всего 3 байта памяти. Однако если кратность адресов для доступа к памяти установлена 4 байта, тс под эти переменные будет отведено в целом 12 байт памяти, из которых 9 не будут использоваться.
Как правило, разработчику исходной программы не нужно знать, каким образом компилятор распределяет адреса под отводимые области памяти. Чаще всегс компилятор сам выбирает оптимальный метод, и, изменяя границы выделенных областей,-он всегда корректно осуществляет доступ к ним. Вопрос об этом может встать, если с данными программы, написанной на одном языке, работают программы, написанные на другом языке программирования (чаще всего на языке ассемблера), реже такие проблемы возникают при использовании двух различных компиляторов с одного и того же входного языка. Большинство компиляторов позволяют пользователю в этом случае самому указать, использовать или нет кратные адреса и какую границу кратности установить (если это вообще возможно с точки зрения архитектуры целевой вычислительной системы).
Некоторые вычислительные системы вообще не могут работать с адресами, не кратными определенному числу байтов.
Виды областей памяти. Статическое и динамическое связывание
Глобальная и локальная память
Глобальная область памяти — это область памяти, которая выделяется один раз при инициализации результирующей программы и действует все время выполнения результирующей программы.
Как правило, глобальная область памяти может быть доступна из любой части исходной программы, но многие языки программирования позволяют налагать синтаксические и семантические ограничения на доступность даже для глобальных областей памяти. При этом сами области памяти и связанные с ними лексические единицы остаются глобальными, ограничения налагаются только на возможность их использования в тексте исходной программы (и эти ограничения, в принципе, возможно обойти).
Локальная область памяти — это область памяти, которая выделяется в начале выполнения некоторого фрагмента результирующей программы (блока, функции, процедуры или оператора) и может быть освобождена по завершении выполнения данного фрагмента.
Доступ к локальной области памяти всегда запрещен за пределами того фрагмента программы, в котором она выделяется. Это определяется как синтаксическими и семантическими правилами языка, так и кодом результирующей программы. Даже если удастся обойти ограничения, налагаемые входным языком, использование таких областей памяти вне их области видимости приведет к катастрофическим последствиям для результирующей программы.
Распределение памяти на локальные и глобальные области целиком определяется семантикой языка исходной программы. Только зная смысл синтаксических конструкций исходного языка, можно четко сказать, какая из них будет отнесена в глобальную область памяти, а какая — в локальную. Иногда в исходном языке для некоторых конструкций нет четкого разграничения, тогда решение об их отнесении в ту или иную область памяти принимается разработчиками компилятора и может зависеть от используемой версии компилятора. При этом разработчики исходной программы не должны полагаться на тот факт, что один раз принятое решение будет неизменным во всех версиях компилятора.
Рассмотрим для примера фрагмент текста модуля программы на языке Pascal:
const
Global_l = 1;
Global_2 ： Integer = 2； var
Global_I ： Integer；
function Test (Param： integer)： pointer： const
Local 1 = 1：
Local_2 : integer = 2: var
Local_I : Integer： begin
end：
Согласно семантике языка Pascal, переменная Global_I является глобальной 匸二 ременной языка и размещается в глобальной области памяти, константа Globs'_ также является глобальной, но язык не требует, чтобы компилятор обязательн размещал ее в памяти — значение константы может быть непосредственно по二- ставлено в код результирующей программы там, где она используется. Типизированная константа Globa 1_2 является глобальной, но, в отличие от константа Global」，семантика языка предполагает, что эта константа обязательно буде размещена в памяти, а не в коде программы. Доступность идентификатор: Global_I, Global_2 и Global_l из других модулей зависит от того, где и как он описаны. Например, для компилятора Borland Pascal переменные и констант三 описанные в заголовке модулей, доступны из других модулей программы, а переменные и константы, описанные в теле модулей, недоступны, хотя и те и др\ - гие являются глобальными.
Параметр Param функции Test, переменная Local_I и константа Local_1 являют^ локальными элементами этой функции. Они не доступны вне пределов даннс функции и располагаются в локальной области памяти. Типизированная константа Local_2 представляет собой очень интересный элемент программы. С одной стороны, она не доступна вне пределов функции Test и потому является с локальным элементом. С другой стороны, как типизированная константа она 6} ■ дет располагаться в глобальной области памяти, хотя ниоткуда извне не може- быть доступна (аналогичными конструкциями языка С, например, являются лекальные переменные функций, описанные как static).
Семантические особенности языка должны учитывать создатели компилятс ра, когда разрабатывают модуль распределения памяти. Безусловно, это долже- знать и разработчик исходной программы, чтобы не допускать семантически, (смысловых) ошибок — этот тип ошибок сложнее всего поддается обнаружение Так, в приведенном выше примере в качестве результата функции Test може~ выступать адрес переменной Global_I или типизированной константы Globa 1_2 Результатом функции не может быть адрес констант Global_l или Local_l — этс запрещено семантикой языка. Гораздо сложнее вопрос с переменной Local_1 ил; параметром функции Param. Будучи элементами локальной области памяти функции Test, они никак не могут выступать в качестве результата функции, потом;- что он будет использован вне самой функции, когда область ее локальной памят; может уже не существовать. Но ни синтаксис, ни семантика языка не запрещают использовать адрес этих элементов в качестве результата функции (и далеко н匚 всегда компилятор способен хотя бы обнаружить факт такого использования адреса локальной переменной). Эти особенности языка должен учитывать разработчик программы. А вот адрес типизированной константы Local_2, в принципе, может быть результатом функции Test. Ведь хотя она и является локально;：
константой, но размещается в глобальной области памяти (другое дело, что этим пользоваться не рекомендуется, поскольку нет гарантии, что принцип размещения локальных типизированных констант не изменится с переходом к другой версии компилятора)1.
Статическая и динамическая память
Статическая область памяти — это область памяти, размер которой известен на этапе компиляции.
Поскольку для статической области памяти известен ее размер, компилятор всегда может выделить эту область памяти и связать ее с соответствующим элементом программы. Поэтому для статической области памяти компилятор порождает некоторый адрес (как правило, это относительный адрес в программе — см. подраздел «Трансляция адресов. Настраивающий загрузчик» в главе 6 «Современные системы программирования»).
Статические области памяти обрабатываются компилятором самым простейшим образом, поскольку напрямую связаны со своим адресом. В этом случае говорят о статическом связывании области памяти и лексической единицы входного языка.
Динамическая область памяти — это область памяти, размер которой на этапе компиляции программы не известен.
Размер динамической области памяти будет известен только в процессе выполнения результирующей программы. Поэтому для динамической области памяти компилятор не может непосредственно выделить адрес — для нее он порождает фрагмент кода, который отвечает за распределение памяти (ее выделение и освобождение). Как правило, с динамическими областями памяти связаны многие операции с указателями и с экземплярами объектов (классов) в объектно-ориентированных языках программирования. При использовании динамических областей памяти говорят о динамическом связывании области памяти и лексической единицы входного языка.
Динамические области памяти, в свою очередь, можно разделить на динамические области памяти, выделяемые пользователем, и динамические области памяти, выделяемые непосредственно компилятором.
Динамические области памяти, выделяемые пользователем, появляются в тех случаях, когда разработчик исходной программы явно использует в тексте программы функции, связанные с распределением памяти (примером таких функций являются New и Dispose в языке Pascal, mall ос и free в языке С, new и delete в языке C++ и другие). Функции распределения памяти могут использовать либо напрямую средства ОС, либо средства исходного языка (которые, в конце концов, все равно основаны на средствах ОС). В этом случае за своевременное выделение
Рассуждения о возможности или невозможности использования адресов тех или иных элементов программы в качестве результата функции в приведенном примере носят чисто теоретический характер. Вопрос о практическом использовании такого рода функций автор оставляет открытым, поскольку он касается проблем читаемости и наглядности исходного текста программ, а также стиля программирования. Эти проблемы представляют большой интерес, но выходят за рамки данного учебника.
и освобождение памяти отвечает сам разработчик, а не компилятор. Компилятс т должен только построить код вызова соответствующих функций и сохранена； результата — в принципе, для него работа с динамической памятью пользователя ничем не отличается от работы с любыми другими функциями и дополнительных сложностей не вызывает.
Другое дело — динамические области памяти, выделяемые компилятором. Он? появляются тогда, когда пользователь использует типы данных, операции над котс- рыми предполагают перераспределение памяти, не присутствующее в явном bi匸： в тексте исходной программы1. Примерами таких типов данных могут служите строки в некоторых языках программирования, динамические массивы и, конечно, многие операции над экземплярами объектов (классов) в объектно-ориенпг- рованных языках (наиболее характерный пример — тип данных string в версия Borland Delphi языка Object Pascal). В этом случае сам компилятор отвечает порождение кода, который будет всегда обеспечивать своевременное выделен; памяти под элементы программы и освобождать ее по мере использования.
Как статические, так и динамические области памяти сами по себе могут быт- глобальными или локальными.
Менеджеры памяти
Многие компиляторы объектно-ориентированных языков программирования используют для работы с динамической памятью специальный менеджер помят:. к которому обращаются как при выделении памяти по команде пользователя так и при выделении памяти самим компилятором. Менеджер памяти обеспечг - вает выполнение функций выделения и освобождения используемой оператнь- ной памяти и следит за ее наиболее рациональным использованием.
Как правило, роль менеджера памяти заключается в том, что при первом требе - вании на выделение оперативной памяти он запрашивает у ОС область памят. намного большего объема, чем это первоначально необходимо результирующее программе. Зато для всех последующих требований на выделение оперативно, памяти менеджер памяти стремится выделить фрагменты из уже имеющейся в его распоряжении области памяти, не обращаясь к функциям ОС до тех пор пока вся эта область памяти не будет исчерпана. Когда вся имеющаяся в его распоряжении память распределена, менеджер памяти вновь запрашивает у ОС область памяти заведомо большего размера, чем требуется результирующей программе. По мере выполнения результирующей программы менеджер памят; следит за использованием всех находящихся в его распоряжении областей памят; и их фрагментов. Если какая-то из запрошенных им областей памяти полностьь перестает использоваться, менеджер памяти освобождает ее с помощью функций ОС. В более сложных случаях менеджер памяти обладает также функциями перераспределения уже используемой памяти и сборки мусора — поиска в выде-
В принципе, в этом случае разработчик исходной программы может даже и не подозревать о том, что используемая им операция предполагает перераспределение памяти. Однакс это не лучшим образом будет сказываться на эффективности созданной разработчиком программы.
ленной памяти фрагментов, которые не освобождены, но в то же время уже не используются.
При создании менеджера памяти разработчики компилятора преследуют две основные цели:
сокращается количество обращений результирующей программы к системным функциям ОС, обеспечивающим выделение и освобождение оперативной памяти, а поскольку это довольно сложные функции, то в целом увеличивается быстродействие результирующей программы;
сокращается фрагментация оперативной памяти, характерная именно для объектно-ориентированных языков, поскольку менеджер памяти запрашивает у ОС оперативную память укрупненными фрагментами и освобождает ее также укрупненными фрагментами.
Главным недостатком при использовании менеджера памяти является тот факт, что результирующая программа всегда запрашивает у ОС оперативной памяти больше, чем необходимо для ее выполнения. Однако этот недостаток окупается за счет более рационального- использования в результирующей программе уже выделенной памяти.
Код менеджера памяти включается в текст результирующей программы или поставляется в виде отдельной динамически загружаемой библиотеки. Компилятор автоматически включает вызовы функций менеджера памяти в текст результирующей программы там, где это необходимо. В таких языках программирования, как Pascal или C++, менеджер памяти не является обязательной составляющей библиотеки функций компилятора, но, например, в языке Java, где не предусмотрена возможность выделения динамической памяти по запросам пользователя и вся память автоматически выделяется и освобождается компилятором, менеджер памяти необходим, и функции его достаточно сложны.
Дисплей памяти процедуры (функции). Стековая организация дисплея памяти
Понятие дисплея памяти процедуры (функции)
Дисплей памяти процедуры (функции) — это область данных, доступных для обработки в этой процедуре (функции).
Как правило, дисплей памяти процедуры включает следующие составляющие:
глобальные данные (переменные и константы) всей программы;
формальные аргументы процедуры;
локальные данные (переменные и константы) данной процедуры.
Также в дисплей памяти часто включают адрес возврата.
Адрес возврата — это адрес того фрагмента кода результирующей программы, куда должно быть передано управление после того, как завершится выполнение вызванной процедуры или функции. Фактически, адрес возврата — это адрес машинной команды, следующей за командой обращения (вызова) к процедуре или
функции. Адрес возврата никак не обрабатывается в процедуре или функции. ? должен быть сохранен на все время ее выполнения.
Процедура должна работать со своими данными однотипным образом вне завис мости от того, из какого места результирующей программы она была вызвана (от^ да произошло обращение к этой процедуре). Поэтому компилятор должен с(х - ветствующим образом организовать обращение к данным, доступным процедур»： С глобальными данными никаких проблем не возникает — их адреса известно они все устанавливаются на этапе распределения памяти. Даже если память е . _ эти данные распределяется динамически, компилятору однозначно известно, кз к этой памяти обратиться, и способ обращения одинаков для всей программа Поэтому он всегда может создать код для обращения к этим данным вне завис; мости от того, откуда это обращение происходит.
Сложнее с локальными параметрами и переменными процедуры. Они относят:； к локальной памяти процедуры и потому должны быть как-то связаны с нем Существует несколько вариантов связывания локальных переменных и пар^ метров с кодом соответствующей процедуры или функции [15]. Современны： вычислительные системы ориентированы, главным образом, на стековую организацию дисплея памяти процедуры (функции). Поэтому компиляторы при со;- дании результирующей программы используют именно этот вариант.
Стековая организация дисплея памяти процедуры (функции)
Стековая организация дисплея памяти процедуры (функции) основана на том что для хранения параметров (аргументов) процедур и функций, их локальны переменных, а также адреса возврата в результирующей программе выделяете - одна на всю программу специальная область памяти, организованная в виде стекз Этот стек называют стеком передачи параметров, или просто стеком параметроЕ При стековой организации дисплея памяти процедуры или функции в момент е； вызова все параметры и адрес возврата помещаются в стек параметров. При завершении выполнения процедуры или функции параметры извлекаются («выталкиваются») из стека, а управление передается по адресу возврата.
Внутри вызываемой процедуры или функции на верхушке стека может быть выделено место для хранения всех ее локальных переменных. Объектный код процедуры или функции адресуется к параметрам и своим локальным переменных, по смещениям относительно верхушки стека.
В этой схеме компилятор организует единый для всей программы стек параметров. Верхушка стека адресуется одним из регистров процессора — регистров стека. Для доступа к данным удобно использовать еще один регистр процессора, называемый базовым регистром. В начале выполнения результирующее программы стек пуст.
Тогда при вызове процедуры или функции необходимо выполнить следующие действия:
поместить в стек все параметры процедуры или функции;
ить в стеке адрес возврата и передать управление вызываемой процедуре.
В начале выполнения процедура или функция должна выполнить следующие действия:
запомнить в стеке значение базового регистра;
запомнить состояние регистра стека в базовом регистре;.
увеличить значение регистра стека на размер памяти, необходимый для хранения локальных переменных процедуры или функции.
После выполнения этих действий может выполняться код вызванной процедуры или функции. Доступ ко всем локальным переменным и параметрам (аргументам) при этом осуществляется через базовый регистр (параметры лежат в стеке ниже места, указанного базовым регистром, а локальные переменные и константы —выше места, указанного базовым регистром, но ниже места, указанного регистром стека).
При возврате из процедуры или функции необходимо выполнить следующие действия:
присвоить регистру стека значение базового регистра;
выбрать из стека значение базового регистра;
выбрать из стека адрес возврата;
передать управление по адресу возврата и выбрать из стека все параметры процедуры.
После этого можно продолжить выполнение кода результирующей программы, следующего за вызовом процедуры или функции.
Если происходит несколько вложенных вызовов процедур или функций, то их параметры и локальные переменные помещаются в стек последовательно, одни за другими. При этом локальные переменные и параметры процедур и функций, вызванных ранее, не мешают выполнению процедур и функций, вызванных позже. На рис. 5.2 показано, как изменяется содержание стека параметров при выполнении трех последовательных вызовов процедур: сначала процедуры А, затем процедуры В и снова процедуры А. При вызовах стек заполняется, а при возврате из кода процедур — освобождается в обратном порядке.
Из рис. 5.2 видно, что при рекурсивном вызове все локальные данные последовательно размещаются в стеке, и при этом каждая процедура работает только со своими данными. Более того, такая схема легко обеспечивает поддержку вызовов вложенных процедур, которые допустимы, например, в языке Pascal.
Стековая организация памяти получила широкое распространение в современных компиляторах. Практически все существующие ныне языки программирования предполагают именно такую схему организации памяти, ее также используют и в программах на языках ассемблера. Широкое распространение стековой организации дисплея памяти процедур и функций тесно связано также с тем, что большинство операций, выполняемых при вызове процедуры в этой схеме, реализованы в виде соответствующих машинных команд во многих современных вычислительных системах. Это, как правило, все операции со стеком параметров, а также команды вызова процедуры (с автоматическим сохранением адреса возврата в стеке) и возврата из вызванной процедуры (с выборкой адреса воз-
врата из стека). Такой подход значительно упрощает и ускоряет выполнение вз зовов при стековой организации дисплея памяти процедуры (функции).
Вызов 1 процедуры А
Содержимое стека:Локальные данные процедуры АЗначение базового регистра 1
Адрес возврата вызова 1Фактические параметрыпроцедуры А
Вызов 2 процедуры В
Содержимое стека:
Локальные данные процедуры В
Значение базового регистра 2
Адрес возврата внзова 2Фактические параметрыпроцедуры В
Локальные данные процедуры А
Значение базового регистра 1
Адрес возврата вызова 1Фактические параметрыпроцедуры А
J Регистр стека |
■] Вазовый регистр]
]Регистр стека I
<1 Базовый регистр]
Содержимое стека:
i] рогмстг^I
Локальные данные процедуры А
У[ г с! ИЬ1 р ЬI
Значение базового регистра 3
・[ОаоивЫИ pel ик/1 р 1
Адрес возврата вызова 3
Фактические параметры процедуры А
Локальные данные процедуры В
Значение базового регистра 2
Адрес возврата вызова 2
Фактические параметры процедуры В
Локальные данные процедуры А
Значение базового регистра 1
Адрес возврата вызова 1
Фактические параметры процедуры А
Вызов 3 процедуры А
Рис. 5.2. Содержание стека параметров при выполнении трехпоследовательных вызовов процедур
Стековая организация дисплея памяти процедуры позволяет организовать рекурсию вызовов. Однако у этой схемы есть один существенный недостаток — память, отводимая под стек параметров, используется неэффективно. Очевидно, что стек параметров должен иметь размер, достаточный для хранения всех параметров, локальных данных и адресов возврата при самом глубоком вложенном вызове процедуры в результирующей программе. Как правило, ни компилятор, ни разработчик программы не могут знать точно, какая максимальная глубина вложенных вызовов процедур возможна в программе. Следовательно, не известно заранее, какая глубина стека потребуется результирующей программе во время ее выполнения. Размер стека обычно выбирается разработчиком программы «с запасом»1, так, чтобы гарантированно обеспечить любую возможную глубину вложенных вызовов процедур и функций. С другой стороны, большую часть времени своей работы результирующая программа не использует значительную часть стека, а значит, выделенная для этой цели часть оперативной памяти компьютера не используется, так как стек параметров сам по себе не может быть использован для других целей.
Стековая организация дисплея памяти процедур и функций присутствует практически во всех современных компиляторах. Тем не менее, процедуры и функции, построенные с помощью одного входного языка высокого уровня, не всегда могут быть использованы в программах, написанных на другом языке. Дело в том, что стековая организация определяет основные принципы организации дисплея памяти процедуры, но не определяет точно механизм его реализации. В разных входных языках детали реализации этой схемы могут отличаться порядком помещения параметров процедуры в стек и извлечения из него. Эти вопросы определяются в соглашениях о вызове и передаче параметров, принятых в различных языках программирования.
Параметры могут помещаться в стек в прямом порядке (в порядке их следования в описании процедуры) или в обратном порядке. Извлекаться из стека они могут либо в момент возврата из процедуры (функции), либо непосредственно после возврата2. Кроме того, для повышения эффективности программ и увеличения скорости вызова процедур и функций компиляторы могут предусматривать передачу части параметров не через стек, а через свободные регистры процессора.
К сожалению, нет точных расчетных методов для определения требуемого размера стека. Разработчик обычно оценивает его приближенно, исходя из логики результирующей программы. Когда во время отладки программы возникают сообщения о недостатке объема стека (а в них имеется в виду именно стек параметров), то размер стремятся значительно увеличить. С другой стороны, очень большой объем необходимого стека параметров может говорить о невысоком качестве программы. Если объем доступной памяти под стек ограничен (например, в MS DOS — не более 64 Кбайт), это ведет к ограничению допустимой вложенности рекурсий, а бесконечная рекурсия всегда ведет к переполнению стека.
Существуют два общепринятых соглашения о вызове и передаче параметров: соглашение языка Pascal и соглашение языка С. В первом случае параметры помещаются в стек в прямом порядке и извлекаются из стека в момент выполнения возврата из процедуры (функции) — то есть внутри самой процедуры (функции); во втором случае параметры помещаются в стек в обратном порядке, а извлекаются из стека после выполнения возврата из функции — то есть непосредственно после выполнения вызова в вызывающем коде.
Обычно разработчику нет необходимости знать о том, какое соглашение о передаче параметров принято во входном языке программирования. При обработке вызовов внутри текста исходной программы компилятор сам корректно формирует код для выполнения вызовов процедур и функций. Наиболее развитые компиляторы могут варьировать код вызова в зависимости от типа и количества параметров процедуры (функции). Однако если разработчику необходимо использовать процедуры и функции, созданные на основе одного входного языка, в программ^ на другом входном языке, то компилятор не может знать заранее соглашение о передаче параметров, принятое для этих процедур и функций. Такие проблемь возникают чаще всего тогда, когда необходимо выполнить вызов процедур и функций из внешних библиотек. В этом случае разработчик должен сам позаботиться о том, чтобы соглашения о передаче параметров в двух языках были согласованы, поскольку несогласованность в передаче параметров может привести к полной неработоспособности результирующей программы.
СОВЕТ
Для того чтобы корректно выполнять вызовы процедур и функций из библиотек необходимо использовать специальные ключевые слова языка программирования которые позволяют разработчику явно указать, какое соглашение о передаче параметров будет использовано для той или иной процедуры (функции).
Еще одна проблема, которая может возникать при вызове функции, — это проблема возврата результата выполнения функции. Как правило, для этой цел?: компилятор использует определенный регистр процессора, чаще всего — регистр аккумулятора, если он существует в процессоре целевой вычислительной архитектуры. Если разные компиляторы используют разные регистры для этой цели могут возникнуть проблемы с передачей результата выполнения функции, вызванной из библиотеки, созданной другим компилятором. Однако разработчики компиляторов стараются соблюдать общепринятые соглашения о вызове, поэтому проблем с передачей результата выполнения функции при использовании известных компиляторов не возникает.
Исключительные ситуации и их обработка
Понятие исключительной ситуации
Понятие исключительной ситуации (exception) появилось в современных объектно-ориентированных языках программирования.
Проблема заключалась в том, что в таких языках есть специального вида функции —конструкторы (constructor) — и специального вида процедуры — деструкторы (destructor), которые выполняют действия по созданию объектов (классов) и уничтожению их соответственно. При создании объектов выделяется необходимая для этого область памяти, а при освобождении объектов эта область памяти должна освобождаться. Как и при выполнении любых процедур и функций, при выполнении этих специальных процедур и функций могут произойти нештатные ситуации, вызванные кодом результирующей программы или кодом вызывае-
мых ею библиотек ОС (например, ситуация недостатка оперативной памяти при ее выделении). Но в отличие от всех остальных процедур и функций, которые обычно возвращают в таких ситуациях предусмотренный код ошибки, конструктор и деструктор не могут вернуть код ошибки при возникновении нештатной ситуации, поскольку имеют строго определенный и неизменный смысл.
С другой стороны, разработчику желательно иметь средства обнаружения и обработки нештатных ситуаций и для этих двух специальных случаев — конструктора и деструктора.
В объектно-ориентированных языках программирования для этой цели был предложен механизм исключительных ситуаций и работа с ними. Идея оказалась удачной и затем была распространена не только на специальные, но и на все остальные функции языков программирования. В настоящее время все объектно-ориентированные языки программирования предоставляют разработчику механизм работы с исключительными ситуациями. Синтаксис и реализация этого механизма различаются в зависимости от используемого языка программирования, но его смысл (семантика) является общим для всех языков.
Исключительная ситуация — это нештатная ситуация, возникающая в ходе выполнения результирующей программы, предусматривающая, что в момент ее возникновения выполнение результирующей программы будет прервано в месте возникновения исключительной ситуации и управление будет передано обработчику исключительной ситуации. Может быть несколько типов (вариантов) исключительных ситуаций, возникающих в ходе выполнения результирующей программы. Каждый тип исключительной ситуации может предусматривать свой обработчик исключительной ситуации. Если для какого-то типа исключительной ситуации обработчик исключительной ситуации отсутствует, то в этом случае управление должно быть передано системному обработчику исключительной ситуации.
Исключительные ситуации могут возникать в следующих случаях:
при обнаружении ошибки в аппаратно-программных средствах вычислительного комплекса, на котором исполняется результирующая программа (примерами таких ошибок являются: деление на 0, доступ к закрытой области памяти, запись данных в файл, закрытый для записи, и т. п.);
при обнаружении на этапе выполнения результирующей программы действий, запрещенных семантикой входного языка (примерами таких ошибок являются: ошибка при динамическом преобразовании типов, вызов неопределенной виртуальной функции, доступ за границы массива или структуры данных и т. п.)；
по команде разработчика исходной программы, явно указывающей на необходимость порождения исключительной ситуации.
Причина возникновения исключительной ситуации влияет на то, какой программный код будет ответственным за порождение исключительной ситуации и вызов ее обработчика: в первом случае это должен сделать программный код ОС или входящих в ее состав библиотек, во втором и третьем случаях этот код должен входить в состав результирующей программы, но если во втором случае компилятор должен сам включить его в результирующую программу без явного
на то указания, то в последнем случае он должен сделать это по явному yi нию разработчика.
Таким образом, в механизме порождения и обработки исключительных снту, может быть задействован не только объектный код результирующей програ、 но и код других компонентов целевой вычислительной системы (ОС, систел библиотек, драйверов устройств), где выполняется результирующая програ、 Следовательно, обработка исключительных ситуаций зависит от типа целеЕ вычислительной системы. То есть компилятор должен включать в результир\ • щую программу код порождения и обработки исключительных ситуаций в зат симости от типа вычислительной системы, на которую она ориентирована.
Обработчики исключительных ситуаций
За обработку исключительных ситуаций отвечают специальные синтаксичес конструкции, предусмотренные в объектно-ориентированных языках прогр мирования. Примерами таких конструкций являются блоки типа try ... ехсер: и try ... final 1у ... в языке программирования Pascal, блоки типа throw ... cater в языке программирования C++ и др. Считается, что текст исходной программы, помещенный внутрь таких блоков, может вызвать возникновение исключительных ситуаций определенного типа. Текст исходной программы, помещенньи в синтаксически выделенную часть таких блоков, считается текстом обработчик* исключительных ситуаций, специальные синтаксические конструкции и семае- тические правила в каждом языке программирования служат для определение типа обрабатываемых исключительных ситуаций. Компилятор анализирует исходный текст таких блоков и порождает соответствующий объектный код результирующей программы.
Поскольку считается, что в результирующей программе может Ьроизойти люба^ исключительная ситуация вне зависимости от того, предусмотрел или нет ее возникновение разработчик программы, то весь код исходной программы как бы Находится внутри одного блока обработки исключительных ситуаций. Компилятор сам порождает код обработчика исключительных ситуаций для всей результирующей программы в целом — этот обработчик является системным обработчиком исключительных ситуаций. Он обрабатывает все типы исключительных ситуаций. Как правило, он получает управление в тех случаях, когда появляется исключительная ситуация, возникновение которой не предусмотрел разработчга результирующей программы. Обычно системный обработчик исключительных ситуаций формирует сообщение об ошибке, которое видит пользователь, но не прекращает выполнение результирующей программы.
На обработку исключительных ситуаций влияет модель дисплея памяти процедуры (функции), используемая данным компилятором, поскольку исключительная ситуация может произойти в момент выполнения любой процедуры или функции. Все современные компиляторы используют стековую модель дисплея памяти процедуры (функции) для обработки исключительных ситуаций.
С точки зрения компилятора важно построить объектный код обработчика исключительной ситуации таким образом, чтобы он, с одной стороны, корректне
вызывался при возникновении исключительной ситуации, а с другой стороны, не разрушал структуры данных результирующей программы — прежде всего, стек параметров..
Обработка исключительных ситуаций осложняется тем, что заранее не известно, в каком месте объектного кода и в какой момент выполнения результирующей программы может произойти исключительная ситуация. Вне зависимости от этого управление всегда должен получить обработчик данной исключительной ситуации, а если его нет — системный обработчик исключительных ситуаций.
При возникновении исключительной ситуации происходят следующие действия:
прерывается выполнение результирующей программы;
ищется адрес обработчика исключительной ситуации;
управление передается объектному коду обработчика исключительной ситуации, при этом должны быть выполнены следующие условия:
Q все локальные данные, помещенные в стек параметров, должны быть изъяты из него вне зависимости от глубины вложенности вызовов процедур и функций, где произошла исключительная ситуация (стек параметров должен быть приведен в состояние для той процедуры или функции, где находится обработчик исключительной ситуации);
Q для всех данных, для которых компилятором (не разработчиком!) были выделены динамические области памяти, эти области памяти должны быть освобождены;
обработчик исключительной ситуации проверяет, соответствует ли ему тип произошедшей исключительной ситуации, и если нет, то его выполнение прерывается и все начинается с самого начала;
начинает выполняться объектный код обработчика исключительной ситуации. Поскольку исключительная ситуация может произойти в любом месте и в любой момент выполнения результирующей программы, то адрес ее обработчика должен находиться в фиксированной заранее известной статической области памяти. Более того, поскольку исключительная ситуация может быть порождена не только непосредственно в коде результирующей программы, но и при ее обращении к системным функциям (ОС, драйверам, динамически загружаемым библиотекам), то область памяти для хранения адреса обработчика должна быть известна ОС — это должна быть системная область памяти.
В общем случае объектный код, порождаемый компилятором для обработки исключительных ситуаций, достаточно сложен. Но принцип, лежащий в его основе, может быть рассмотрен на самом тривиальном уровне.
В простейшем случае необходимо иметь одну системную ячейку памяти Е〔 для хранения адреса. В этой ячейке памяти хранится адрес регистра стека, указывающий на ячейку в стеке, хранящую адрес обработчика исключительных ситуаций. Тогда для начала блока обработки исключительных ситуаций компилятор должен порождать объектный код, который выполняет следующее:
запоминает в стеке параметров текущее значение базового регистра;
запоминает в стеке параметров адрес обработчика исключительной ситуации для данного блока;
запоминает в стеке параметров текущий адрес, хранящийся в ячейке Et;
помещает в ячейку Е〔 текущее значение регистра стека.
Для конца блока обработки исключительных ситуаций (если исключительная ситуация не произошла) компилятор доложен порождать объектный код, который выполняет следующее:
извлекает из стека предыдущий адрес, хранившийся в ячейке Еь и помещает его в ячейку Ej；
извлекает из стека два адреса (адрес обработчика для данного блока и базовый регистр), далее они уже не понадобятся.
При возникновении исключительной ситуации происходит следующее:
текущий адрес из ячейки Е( помещается в регистр стека;
из стека извлекается предыдущий адрес, хранившийся в ячейке Еь и записывается в ячейку Е(;
из стека извлекается адрес обработчика исключительной ситуации и ему передается управление;
получив управление, обработчик исключительной ситуации извлекает из стека базовый регистр — теперь значение регистра стека и базового регистра соответствует уровню вложенности процедуры или функции, в которой находится код обработчика исключительной ситуации;
если опять произойдет исключительная ситуация (или если произошедшая ситуация не относится к данному обработчику) — необходимый адрес регистра стека уже находится в ячейке Et, и все действия опять повторятся.
Такой механизм позволяет организовать как бы стек обработчиков исключительных ситуаций, построенный на основе ссылок внутри стека параметров. Общая схема ссылок при использовании простейшего механизма обработки исключительных ситуаций приведена на рис. 5.3.
Как уже было сказано выше, реальный механизм обработки исключительных ситуаций гораздо сложнее и может зависеть от типа ОС. Но схема, приведенная на рис. 5.3, в общем виде отражает технологию, используемую системами программирования для порождения объектного кода обработки исключительных ситуаций.
Такая схема обработки исключительных ситуаций обеспечивает корректное изменение содержимого стека параметров при возникновении исключительной ситуации на любой глубине вложенности вызовов процедур и функций. Однако она никак не учитывает необходимость освобождать области памяти, динамически выделенные для структур данных компилятором. Чаще всего эта проблема решается следующим образом: для каждого блока, содержащего динамические области памяти, выделяемые компилятором, компилятор автоматически организует блок обработки исключительных ситуаций, в котором обработчик исключитель-
ных ситуаций выполняет действия по освобождению выделенных компилятором динамических областей памяти для всех типов исключительных ситуаций.
Код результирующейпро「раммь1Процедура СКод результирующейпро「раммь1Процедура ССтек параметроврезультирующей программ*Значение регистра стека (В)Адрес обработчика 3Значение базового регистраСтек параметроврезультирующей программ*Значение регистра стека (В)Адрес обработчика 3Значение базового регистраОбработчик исключительныхситуаций 3Обработчик исключительныхситуаций 3Возврат из процедуры СПроцедура ВВозврат из процедуры СПроцедура ВЗначение регистра стека (А)Адрес обработчика 2Значение базового регистраЗначение регистра стека (А)Адрес обработчика 2Значение базового регистраВызов процедуры СВызов процедуры СОбработчик исключительныхситуаций 2Обработчик исключительныхситуаций 2Значние регистра стека (...)Адрес обработчика 1Значение базового регистраЗначние регистра стека (...)Адрес обработчика 1Значение базового регистраВозврат из процедуры ВПроцедура АВозврат из процедуры ВПроцедура АВызов процедуры ВВызов процедуры ВСистемная ячейка уазателя—обработчика исключительныхситуаций
Код результирующейпро「раммь1
Процедура С
Код результирующейпро「раммь1
Процедура С
Стек параметроврезультирующей программ*
Значение регистра стека (В)
Адрес обработчика 3Значение базового регистра
Стек параметроврезультирующей программ*
Значение регистра стека (В)
Адрес обработчика 3Значение базового регистра
Обработчик исключительныхситуаций 3
Обработчик исключительныхситуаций 3
Возврат из процедуры СПроцедура В
Возврат из процедуры СПроцедура В
Значение регистра стека (А)Адрес обработчика 2
Значение базового регистра
Значение регистра стека (А)Адрес обработчика 2
Значение базового регистра
Вызов процедуры С
Вызов процедуры С
Обработчик исключительныхситуаций 2
Обработчик исключительныхситуаций 2
Значние регистра стека (...)Адрес обработчика 1Значение базового регистра
Значние регистра стека (...)Адрес обработчика 1Значение базового регистра
Возврат из процедуры ВПроцедура А
Возврат из процедуры ВПроцедура А
Вызов процедуры В
Вызов процедуры В
Обработчик исключительныхситуаций 1
Возврат из процедуры А
Рис, 5.3. Простейший механизм обработки исключительных ситуаций через стек параметров
Например, в языке Object Pascal область памяти для типа данных string автоматически выделяется и освобождается компилятором. Поэтому два блока описания процедуры на этом языке, приведенные ниже, в принципе, эквивалентны:
procedure А； van s： string；beginprocedure А； van s： string；begin{код проиедурн} end：{код проиедурн} end：procedure A；var s： string： begintryprocedure A；var s： string： begintry{код процедуры) finally s 'end;{try}end；{код процедуры) finally s 'end;{try}end；
procedure А； van s： string；
begin
procedure А； van s： string；
begin
{код проиедурн} end：
{код проиедурн} end：
procedure A；
var s： string： begin
try
procedure A；
var s： string： begin
try
{код процедуры) finally s '
end;{try}
end；
{код процедуры) finally s '
end;{try}
end；
ВНИМАНИЕ
Следует помнить, что компилятор не порождает автоматических обработчиков исключительных ситуаций для освобождения динамических областей памяти, выделяемой разработчиком. Разработчик результирующей профам мы сам должен позаботиться об этом!
Не все нештатные ситуации, возникающие в ходе выполнения результирующей программы, обрабатываются как исключительные ситуации. Некоторые аппаратные ошибки и ошибки по защите памяти, возникающие в ходе выполнения, обрабатываются ОС и результирующей программе не сообщаются. Также невозможна обработка исключительных ситуаций в тех случаях, когда повреждены данные, хранящиеся в стеке параметров (например адрес обработчика исключительной ситуации). В этих случаях управление получает специальный код ОС, предназначенный для обработки исключений (прерываний). Как правило, в таких ситуациях пользователю выдается системное сообщение об ошибке и выполнение результирующей программы прекращается.
Разработчикам следует помнить, что для порождения и обработки исключительных ситуаций компилятор порождает достаточно сложный объектный код, который, кроме всего прочего, должен взаимодействовать с функциями ОС. Поэтому не рекомендуется пользоваться исключительными ситуациями там, где в этом нет необходимости. Кроме того, не стоит применять обработку исключительных ситуаций в тех случаях, когда надо найти и исправить логическую ошибку в исходной программе (например если возникает непредвиденная исключительная ситуация защиты памяти или выхода за границы области данных).
СОВЕТ
Рекомендуется использовать механизм исключительных ситуаций в исходной программе только тогда, когда нет других средств обнаружить и обработать нештатную ситуацию.
Например, два фрагмента исходной программы на языке Object Pascal, приведенные ниже, выполняют практически одни и те же действия:
if 1 <> 0 then f ：= к / 1 try
elsef := к / i:
beginexcept
...on EZeroOivide do
{код обработкиbegin
нештатной ситуации}...
end；{код обработки
нештатной ситуации}
end：end；{try}
Но для первого из приведенных фрагментов компилятор построит более эффективный объектный код, чем для второго. Кроме того, логика выполнения и наглядность у первого фрагмента лучше, чем у второго.
Память для типов данных (RTTI-информация)
В ранее существовавших языках программирования все вызовы процедур и функций исходной программы в результирующей программе транслировались в команду вызова подпрограммы с известным адресом. Адрес вызываемой процедуры или функции был известен на этапе компиляции. Этот вариант вызова получил название «раннее связывание» и оставался единственным вариантом до появления объектно-ориентированных языков программирования.
В объектно-ориентированных языках программирования существует понятие виртуальных (virtual) функций (или процедур). При обращении к таким функциям или процедурам адрес вызываемой функции или процедуры становится известным только в момент выполнения результирующей программы. Такой вариант вызова носит название «позднее связывание». Поскольку адрес вызываемой процедуры или функции зависит от того типа данных, для которого она вызывается, в современных компиляторах для объектно-ориентированных языков программирования предусмотрены специальные структуры данных для организации таких вызовов [2, 6, 15, 25, 26, 27, 34, 42, 43, 51]. Эти структуры данных напрямую не доступны разработчику исходной программы, но должны обрабатываться компилятором.
Современные компиляторы с объектно-ориентированных языков программирования предусматривают, что результирующая программа может обрабатывать не только переменные, константы и другие структуры данных, но и информацию о типах данных, описанных в исходной программе. Эта информация получила название RTTI — Run Time Type Information — «информация о типах во время выполнения».
Состав RTTI-информации определяется семантикой входного языка и реализацией компилятора. Как правило, для каждого типа данных в объектно-ориентированном языке программирования создается уникальный идентификатор типа данных, который используется для сопоставления типов. Для него может храниться наименование типа, а также другая служебная информация, которая используется компилятором в коде результирующей программы. Вся эта информация может быть в той или иной мере доступна пользователю. Еще одна цель хранения RTTI-информации — обеспечить корректный механизм вызова виртуальных процедур и функций (так называемое «позднее связывание»), предусмотренный во всех объектно-ориентированных языках программирования [25, 26, 27, 34, 42, 43, 51].
RTTI-информация хранится в результирующей программе в виде RTTI-таблицы. RTTI-таблица представляет собой глобальную статическую структуру данных, которая создается и заполняется в момент начала выполнения результирующей программы. Компилятор с объектно-ориентированного входного языка отвечает за порождение в результирующей программе кода, ответственного за заполнение RTTI-таблицы.
Каждому типу данных в RTTI-таблице соответствует своя область данных, в которой хранится вся необходимая информация об этом типе данных, его взаимо-
связи с другими типами данных в общей иерархии типов данных программы, а также все указатели на код виртуальных процедур и функций, связанных с этим типом. Всю эту информацию и указатели для каждого типа данных в RTTI-таблице размещает код, автоматически порождаемый компилятором.
В принципе, всю эту информацию можно было бы разместить непосредственно в памяти, статически или динамически отводимой для каждого экземпляра объекта (класса) того или иного типа. Но поскольку данная информация для всех объектов одного и того же типа совпадает, то это привело бы к нерациональному использованию оперативной памяти. Поэтому компилятор размещает всю информацию по типу данных в одном месте, а каждому экземпляру объекта (класса) при выделении памяти для него добавляет только небольшой объем служебной информации, связывающей этот объект с соответствующим ему типом данных (как правило, эта служебная информация является указателем на нужную область данных в RTTI-таблице). При статическом распределении памяти под экземпляры объектов (классов) компилятор сам помещает в нее необходимую служебную информацию, при динамическом распределении — порождает код, который заполнит эту информацию во время выполнения программы (поскольку RTTI-таблица является статической областью данных, адрес ее известен и фиксирован).
На рис. 5.4 приведена схема, иллюстрирующая построение RTTI-таблицы и ее связь с экземплярами объектов в результирующей программе.
Компилятор автоматически строит код, ответственный в результирующей программе за создание и заполнение RTTI-таблицы и за ее взаимосвязь с экземплярами объектов (классов) различных типов. Разработчику не надо заботиться об этом, тем более что он, как правило, не может воздействовать на служебную информацию, помещаемую компилятором в RTTI-таблицу.
Проблемы могут появиться в том случае, когда некоторая программа взаимодействует с динамически загружаемой библиотекой. При этом могут возникнуть ситуации, вызванные несоответствием типов данных в программе и библиотеке, хотя и та и другая могут быть построены на одном и том же входном языке с помощью одного и того же компилятора. Дело в том, что код инициализации программы, порождаемый компилятором, ответствен за создание и заполнение своей RTTI-таблицы, а код инициализации библиотеки, порождаемый тем же компилятором, —своей RTTI-таблицы. Если программа и динамически загружаемая библиотека работают с одними и теми же типами данных, то эти RTTI-таблицы будут полностью совпадать, но при этом они не будут одной и той же таблицей. Это уже должен учитывать разработчик программы при проверке соответствия типов данных.
Еще большие сложности могут возникнуть, если программа, построенная на основе входного объектно-ориентированного языка программирования, будет взаимодействовать с библиотекой или программой, построенной на основе другого объектно-ориентированного языка (или даже построенной на том же языке, но с помощью другого компилятора). Поскольку формат RTTI-таблиц и состав хранимой в них служебной информации не специфицированы для всех языков программирования, то они полностью зависят от используемой версии компилятора.
Соответствующим образом различается и порождаемый компилятором код результирующей программы. В общем случае организовать такого рода взаимодействие между двумя фрагментами кода, порожденного двумя различными компиляторами, напрямую практически невозможно (о других возможностях такого рода взаимодействия см. в главе 6 «Современные системы программирования»).
Экземпляр объекта типа «Т1»
Рис. 5.4. Взаимосвязь RTTI-таблицы с экземплярами объектов в результирующей программе
Генерация кода.
Методы генерации кода
Общие принципы генерации кода
Генерация объектного кода — это перевод компилятором внутреннего представления исходной программы в цепочку символов выходного языка.
Генерация объектного кода порождает результирующую объектную программу на языке ассемблера или непосредственно на машинном языке (в машинных кодах). Внутреннее представление программы может иметь любую структуру в зависимости от реализации компилятора, в то время как результирующая программа всегда представляет собой линейную последовательность команд. Поэтому генерация объектного кода (объектной программы) в любом случае должна выполнять действия, связанные с преобразованием сложных синтаксических структур в линейные цепочки.
Генерацию кода можно считать функцией, определенной на синтаксическом дереве, построенном в результате синтаксического анализа, и на информации, содержащейся в таблице идентификаторов. Поэтому генерация объектного кода
выполняется после того, как выполнены синтаксический анализ программы и все необходимые действия по подготовке к генерации кода: распределено адресное пространство под функции и переменные, проверено соответствие имен и типов переменных, констант и функций в синтаксических конструкциях исходной программы и т. д. Характер отображения входной программы в последовательность команд, выполняемую генерацией, зависит от входного языка, архитектуры вычислительной системы, на которую ориентирована результирующая программа, а также от качества желаемого объектного кода.
В идеале компилятор должен выполнить синтаксический анализ всей входной программы, затем провести ее семантический анализ, после чего приступать к подготовке генерации и непосредственно к генерации кода. Однако такая схема работы компилятора практически почти никогда не применяется. Дело в том, что в общем случае ни один семантический анализатор и ни один компилятор не способны проанализировать и оценить смысл всей исходной программы в целом. Формальные методы анализа семантики применимы только к очень незначительной части возможных исходных программ. Поэтому у компилятора нет практической возможности порождать эквивалентную результирующую программу на основе всей исходной программы.
Как правило, компилятор выполняет генерацию результирующего кода поэтапно, на основе законченных синтаксических конструкций входной программы. Компилятор выделяет законченную синтаксическую конструкцию из текста исходной программы, порождает для нее фрагмент результирующего кода и помещает его в текст результирующей программы. Затем он переходит к следующей синтаксической конструкции. Так продолжается до тех пор, пока не будет разобрана вся исходная программа. В качестве анализируемых законченных синтаксических конструкций выступают операторы, блоки операторов, описания процедур и функций. Их конкретный состав зависит от входного языка и реализации компилятора.
Смысл (семантику) каждой такой синтаксической конструкции входного языка можно определить исходя из ее типа, а тип определяется синтаксическим анализатором на основании грамматики входного языка. Примерами типов синтаксических конструкций могут служить операторы цикла, условные операторы, операторы выбора и т. д. Одни и те же типы синтаксических конструкций характерны для различных языков программирования, при этом они различаются синтаксисом (который задается грамматикой языка), но имеют схожий смысл (который определяется семантикой). В зависимости от типа синтаксической конструкции выполняется генерация кода результирующей программы, соответствующего данной синтаксической конструкции. Для семантически схожих конструкций различных входных языков программирования может порождаться типовой результирующий код.
Синтаксически управляемый перевод
Чтобы компилятор мог построить код результирующей программы для синтаксической конструкции входного языка, часто используется метод, называемый синтаксически управляемым переводом — СУ-переводом.
Идея СУ-перевода основана на том, что синтаксис и семантика языка взаимосвязаны. Это значит, что смысл предложения языка зависит от синтаксической структуры этого предложения. Теория синтаксически управляемого перевода была предложена американским лингвистом Ноамом Хомским1. Она справедлива как для формальных языков, так и для языков естественного общения — например, смысл предложения русского языка зависит от входящих в него частей речи (подлежащего, сказуемого, дополнений и др.) и от взаимосвязи между ними. Однако естественные языки допускают неоднозначности в грамматиках — отсюда происходят различные двусмысленные фразы, значение которых человек обычно понимает из того контекста, в котором эти фразы встречаются (и то он не всегда может это сделать). В языках программирования неоднозначности в грамматиках исключены, поэтому любое предложение языка имеет четко определенную структуру и однозначный смысл, напрямую связанный с этой структурой.
Входной язык компилятора имеет бесконечное множество допустимых предложений, поэтому невозможно задать смысл каждого предложения. Но все входные предложения строятся на основе конечного множества правил грамматики, которые всегда можно найти. Так как этих правил конечное число, то для каждого правила можно определить его семантику (значение). То, как это выполняется для входного языка компилятора, было рассмотрено выше в главах, посвященным лексическому и синтаксическому анализу.
Но абсолютно то же самое можно утверждать и для выходного языка компилятора вне зависимости от того, является ли этот язык языком ассемблера, языком машинных кодов или другим языком низкого уровня. Выходной язык содержит бесконечное множество допустимых предложений, но все они строятся на основе конечного множества известных правил, каждое из которых имеет определенную семантику (смысл). Если по отношению к исходной программе компилятор выступает в роли распознавателя, то для результирующей программы он является генератором предложений выходного языка. Задача заключается в том, чтобы найти порядок правил выходного языка, по которым необходимо выполнить генерацию.
Грубо говоря, идея СУ-перевода заключается в том, что каждому правилу входного языка компилятора сопоставляется одно или несколько (или ни одного) правил выходного языка в соответствии с семантикой входных и выходных правил. То есть при сопоставлении надо выбирать правила выходного языка, которые несут тот же смысл, что и правила входного языка.
СУ-перевод — это основной метод порождения кода результирующей программы на основании результатов синтаксического анализа. Для удобства понимания сути метода можно считать, что результат синтаксического анализа представлен в виде дерева синтаксического анализа, хотя в реальных компиляторах это не всегда так.
Суть принципа СУ-перевода заключается в следующем: с каждой вершиной дерева синтаксического разбора N связывается цепочка некоторого промежуточного кода C(N). Код для вершины N строится путем сцепления (конкатенации)
Фамилия этого известного лингвиста уже встречалась, когда речь шла о типах языков и грамматик и их классификации.
в фиксированном порядке последовательности кода C(N) и последовательностей кодов, связанных со всеми вершинами, являющимися прямыми потомками N. В свою очередь, для построения последовательностей кода прямых потомков вершины N потребуется найти последовательности кода для их потомков — потомков второго уровня вершины N — и т. д. Процесс перевода идет, таким образом, снизу вверх в строго установленном порядке, определяемом структурой дерева. Для того чтобы построить СУ-перевод по заданному дереву синтаксического разбора, необходимо найти последовательность кода для корня дерева. Поэтому для каждой вершины дерева порождаемую цепочку кода надо выбирать таким образом, чтобы код, приписываемый корню дерева, оказался искомым кодом для всего оператора, представленного этим деревом. В общем случае необходимо иметь единообразную интерпретацию кода C(N), которая бы встречалась во всех ситуациях, где присутствует вершина N. В принципе, эта задача может оказаться нетривиальной, так как требует оценки смысла (семантики) каждой вершины дерева. При применении СУ-перевода задача интерпретации кода для каждой вершины дерева решается только разработчиком компилятора.
Возможна модель компилятора, в которой синтаксический анализ исходной программы и генерация кода результирующей программы объединены в одну фазу. Такую модель можно представить в виде компилятора, у которого операции генерации кода совмещены с операциями выполнения синтаксического разбора. Для описания компиляторов такого типа часто используется термин «СУ-компиляция» (синтаксически управляемая компиляция).
Схему СУ-компиляции можно реализовать не для всякого входного языка программирования. Если принцип СУ-перевода применим ко всем входным КС-языкам, то применить СУ-компиляцию оказывается не всегда возможно. Однако известно, что схемы перевода на основе СУ-компиляции можно построить для многих из широко распространенных классов КС-языков, в частности для LR и LL языков [4, т. 1, 2].
В процессе СУ-перевода и СУ-компиляции не только вырабатываются цепочки текста выходного языка, но и совершаются некоторые дополнительные действия, выполняемые самим компилятором. В общем случае схемы СУ-перевода могут предусматривать выполнение следующих действий:
помещение в выходной поток данных машинных кодов или команд ассемблера, представляющих собой результат работы (выход) компилятора;
выдачу пользователю сообщений об обнаруженных ошибках и предупреждениях (которые должны помещаться в выходной поток, отличный от потока, используемого для команд результирующей программы);
порождение и выполнение команд, указывающих, что некоторые действия должны быть произведены самим компилятором (например, операции, выполняемые над данными, размещенными в таблице идентификаторов).
Ниже рассмотрены основные технические вопросы, позволяющие реализовать схемы СУ-перевода и СУ-компиляции. Но прежде чем рассматривать их, необходимо разобраться со способами внутреннего представления программы в компиляторе. От того как исходная программа представляется внутри компилятора, во многом зависят методы, используемые для обработки команд этой программы.
Способы внутреннего представления программ
Виды внутреннего представления программы
Результатом работы синтаксического анализатора на основе КС-грамматики входного языка является последовательность правил грамматики, примененных для построения входной цепочки. По найденной последовательности, зная тип распознавателя, можно построить цепочку вывода или дерево вывода. В этом случае дерево вывода выступает в качестве дерева синтаксического анализа и представляет собой результат работы синтаксического анализатора в компиляторе.
Однако ни цепочка вывода, ни дерево синтаксического разбора не являются целью работы компилятора. Дерево вывода содержит массу избыточной информации, которая для дальнейшей работы компилятора не требуется. Эта информация включает в себя все нетерминальные символы, содержащиеся в узлах дерева,— после того как дерево построено, они не несут никакой смысловой нагрузки и не представляют интереса.
Для полного представления о типе и структуре найденной и разобранной синтаксической конструкции входного языка, в принципе, достаточно знать последовательность номеров правил грамматики, примененных для ее построения. Однако форма представления этой достаточной информации может быть различной в зависимости как от реализации самого компилятора, так и от фазы компиляции. Эта форма называется внутренним представлением программы (иногда используются также термины «промежуточное представление» и «промежуточная программа»).
Все внутренние представления программы обычно содержат в себе две принципиально различные вещи — операторы и операнды. Различия между формами внутреннего представления заключаются лишь в том, как операторы и операнды соединяются между собой. Также операторы и операнды должны отличаться друг от друга, вне зависимости от того, в каком порядке они встречаются во внутреннем представлении программы. За различение операндов и операторов, как уже было сказано выше, отвечает разработчик компилятора, который руководствуется семантикой входного языка.
Известны следующие формы внутреннего представления программ1:
связные списочные структуры, представляющие синтаксические деревья;
многоадресный код с явно именуемым результатом (тетрады);
многоадресный код с неявно именуемым результатом (триады);
1 Существуют три формы записи выражений — префиксная, инфиксная и постфиксная. При префиксной записи операция записывается перед своими операндами, при инфиксной —между операндами, а при постфиксной — после операндов. Общепринятая запись арифметических выражений является примером инфиксной записи. Запись математических функций и функций в языках программирования является префиксной (другие примеры префиксной записи — команды ассемблера, триады и тетрады, в том виде, как они рассмотрены далее). Постфиксная запись в повседневной жизни встречается редко. С нею сталкиваются разве что пользователи стековых калькуляторов и программисты на языке Forth.
обратная (постфиксная) польская запись операций;
ассемблерный код или машинные команды.
В каждом конкретном компиляторе может использоваться одна из этих форм, выбранная разработчиками. Но чаще всего компилятор не ограничивается использованием только одной формы для внутреннего представления программы. На различных фазах компиляции могут использоваться различные формы, которые по мере выполнения проходов компилятора преобразуются одна в другую. Не все из перечисленных форм широко используются в современных компиляторах, и об этом будет сказано по мере их рассмотрения.
Некоторые компиляторы, незначительно оптимизирующие результирующий код, генерируют объектный код по мере разбора исходной программы. В этом случае применяется схема СУ-компиляции, когда фазы синтаксического разбора, семантического анализа, подготовки и генерации объектного кода совмещены в одном проходе компилятора. Тогда внутреннее представление программы существует только условно в виде последовательности шагов алгоритма разбора. В любом случае компилятор всегда будет работать с представлением программы в форме машинных команд — иначе он не сможет построить результирующую программу. Далее будут рассмотрены различные формы внутреннего представления программы, начиная от связных списочных структур.
Синтаксические деревья. Преобразование дерева разбора в дерево операций
Связные списочные структуры, представляющие синтаксические деревья, наиболее просто и эффективно строить на этапе синтаксического анализа, руководствуясь правилами и типом вывода, порожденного синтаксическим распознавателем.
В синтаксическом дереве внутренние узлы (вершины) соответствуют операциям, а листья представляют собой операнды. Как правило, листья синтаксического дерева связаны с записями в таблице идентификаторов. Структура синтаксического дерева отражает синтаксис языка программирования, на котором написана исходная программа.
Синтаксические деревья могут быть построены компилятором для любой части исходной программы. Не всегда синтаксическому дереву должен соответствовать фрагмент кода результирующей программы — например, возможно построение синтаксических деревьев для декларативной части языка. В этом случае операции, имеющиеся в дереве, не требуют порождения объектного кода, но несут информацию о действиях, которые должен выполнить сам компилятор над соответствующими элементами. В том случае, когда синтаксическому дереву соответствует некоторая последовательность операций, влекущая порождение фрагмента объектного кода, говорят о дереве операций.
Дерево операций можно непосредственно построить из дерева вывода, порожденного синтаксическим анализатором. Для этого достаточно исключить из дерева вывода цепочки нетерминальных символов, а также узлы, не несущие семантической (смысловой) нагрузки при генерации кода. Примером таких узлов могут служить различные скобки, которые меняют порядок выполнения операций и one-
раторов, но после построения дерева никакой смысловой нагрузки не несут, так как им не соответствует никакой объектный код.
То, какой узел в дереве является операцией, а какой — операндом, никак невозможно определить из грамматики, описывающей синтаксис входного языка. Также ниоткуда не следует, каким операциям должен соответствовать объектный код в результирующей программе, а каким — нет. Все это определяется только исходя из семантики — «смысла» — языка входной программы. Поэтому только разработчик компилятора может четко определить, как при построении дерева операций должны различаться операнды и сами операции, а также то, какие операции являются семантически незначащими для порождения объектного кода.
Алгоритм преобразования дерева семантического разбора в дерево операций можно представить следующим образом:
Шаг 1. Если в дереве больше не содержится узлов, помеченных нетерминальными символами, то выполнение алгоритма завершено; иначе перейти к шагу 2.
Шаг 2. Выбрать крайний левый узел дерева, помеченный нетерминальным символом грамматики, и сделать его текущим. Перейти к шагу 3.
Шаг 3. Если текущий узел имеет только один нижележащий узел, то текущий узел необходимо удалить из дерева, а связанный с ним узел присоединить к узлу вышележащего уровня (исключить из дерева цепочку) и вернуться к шагу 1; иначе перейти к шагу 4.
Шаг 4. Если текущий узел имеет нижележащий узел (лист дерева), помеченный терминальным символом, который не несет семантической нагрузки, тогда этот лист нужно удалить из дерева и вернуться к шагу 3; иначе перейти к шагу 5.
Шаг 5. Если текущий узел имеет один нижележащий узел (лист дерева), помеченный терминальным символом, обозначающим знак операции, а остальные узлы помечены как операнды, то лист, помеченный знаком операции, надо удалить из дерева, текущий узел пометить этим знаком операции и перейти к шагу 1; иначе перейти к шагу 6.
Шаг 6. Если среди нижележащих узлов для текущего узла есть узлы, помеченные нетерминальными символами грамматики, то необходимо выбрать крайний левый среди этих узлов, сделать его текущим узлом и перейти к шагу 3; иначе выполнение алгоритма завершено.
Если семантика языка задана корректно, то в результате работы алгоритма из дерева будут исключены все нетерминальные символы.
Возьмем в качестве примеров синтаксические деревья, построенные для цепочки (а+а)*Ь из языка, заданного различными вариантами грамматики арифметических выражений. Эти деревья приведены выше в качестве примеров на рис. 4.6, 4.12 и 4.14. Семантически незначащими символами в этой грамматике являются скобки (они задают порядок операций и влияют на синтаксический разбор, но не порождают результирующий код) и пустые строки. Знаки операций заданы символами +, -, / и *, остальные символы (а и Ь) являются операндами.
В результате применения алгоритма преобразования деревьев синтаксического разбора в дерево операций к деревьям, представленным на рис. 4.6, 4.12 и 4.14,
получим дерево операций, представленное на рис. 5.5. Причем несмотря на то что исходные синтаксические деревья имели различную структуру, зависящую от используемой грамматики, результирующее дерево операций в итоге всегда имеет одну и ту же структуру, зависящую только от семантики входного языка.
Рис. 5.5. Пример дерева операций для языка арифметических выражений
Дерево операций является формой внутреннего представления программы, которой удобно пользоваться на этапах синтаксического и семантического анализа, а также подготовки к генерации кода, когда еще нет необходимости работать непосредственно с кодами команд результирующей программы. Дерево операций четко отражает связь всех операций между собой, поэтому его удобно использовать также для преобразований, связанных с перестановкой и переупорядочива- нием операций без изменения конечного результата (таких, как арифметические преобразования). Более подробно эти вопросы рассмотрены в [4, 15].
Недостаток синтаксических деревьев заключается в том, что они представляют собой сложные связные структуры, а потому не могут быть тривиальным образом преобразованы в линейную последовательность команд результирующей программы.
Синтаксические деревья могут быть преобразованы в другие формы внутреннего представления программы, представляющие собой линейные списки, с учетом семантики входного языка. Алгоритмы такого рода преобразований рассмотрены далее. Эти преобразования выполняются на основе принципов СУ-компиляции.
Многоадресный код с явно именуемым результатом (тетрады)
Тетрады представляют собой запись операций в форме из четырех составляющих: операции, двух операндов и результатов операции. Например, тетрады могут выглядеть так: <операция>(<операнд1>,<операнд2>.<результат>).
Тетрады представляют собой линейную последовательность команд. При вычислении выражения, записанного в форме тетрад, они вычисляются одна за другой последовательно. Каждая тетрада в последовательности вычисляется так: операция, заданная тетрадой, выполняется над операндами и результат ее выполнения помещается в переменную, заданную результатом тетрады. Если какой-то из операндов (или оба операнда) в тетраде отсутствует (например если тетрада представляет собой унарную операцию), то он может быть опущен или заменен пустым операндом (в зависимости от принятой формы записи и ее реализации).
Результат вычисления тетрады никогда не может быть опущен, иначе тетрада полностью теряет смысл. Порядок вычисления тетрад может быть изменен, но только если допустить наличие тетрад, целенаправленно изменяющих этот порядок (например тетрады, вызывающие переход на несколько шагов вперед или назад при каком-то условии).
Тетрады представляют собой линейную последовательность, а потому для них несложно написать тривиальный алгоритм, который будет преобразовывать последовательность тетрад в последовательность команд результирующей программы (либо последовательность команд ассемблера). В этом их преимущество перед синтаксическими деревьями. А в отличие от команд ассемблера, тетрады не зависят от архитектуры вычислительной системы, на которую ориентирована результирующая программа. Поэтому они представляют собой машинно-независимую форму внутреннего представления программы.
Тетрады требуют больше памяти для своего представления, чем триады, они также не отражают явно взаимосвязь операций между собой. Кроме того, есть сложности с преобразованием тетрад в машинный код, так как они плохо отображаются в команды ассемблера и машинные коды, поскольку в наборах команд большинства современных компьютеров редко встречаются операции с тремя операндами.
Например, выражение А ：= В * С + D - В * 10, записанное в виде тетрад, будет иметь вид:
* (В, С. Т1)
+ (Т1, D, Т2)
* (В, 10, ТЗ)
- (Т2. ТЗ. Т4)
:= (Т4. 0, А)
Здесь все операции обозначены соответствующими знаками (при этом присвоение также является операцией). Идентификаторы Т1, ..., Т4 обозначают временные переменные, используемые для хранения результатов вычисления тетрад. Следует обратить внимание, что в последней тетраде (присвоение), которая требует только одного операнда, в качестве второго операнда выступает незначащий операнд 0.
Многоадресный код с неявно именуемым результатом (триады)
Триады представляют собой запись операций в форме из трех составляющих: операции и двух операндов. Например, триады могут иметь вид: <операция> (<операнд1>,<операнд2>). Особенностью триад является то, что один или оба операнда могут быть ссылками на другую триаду в том случае, если в качестве операнда данной триады выступает результат выполнения другой триады. Поэтому триады при записи последовательно нумеруют для удобства указания ссылок одних триад на другие (в реализации компилятора в качестве ссылок можно использовать не номера триад, а непосредственно ссылки в виде указателей —
тогда при изменении нумерации и порядка следования триад менять ссылки не требуется).
Триады представляют собой линейную последовательность команд. При вычислении выражения, записанного в форме триад, они вычисляются одна за другой последовательно. Каждая триада в последовательности вычисляется так: операция, заданная триадой, выполняется над операндами, а если в качестве одного из операндов (или обоих операндов) выступает ссылка на другую триаду, то берется результат вычисления той триады. Результат вычисления триады нужно сохранять во временной памяти, так как он может быть затребован последующими триадами. Если какой-то из операндов в триаде отсутствует (например если триада представляет собой унарную операцию), то он может быть опущен или заменен пустым операндом (в зависимости от принятой формы записи и ее реализации). Порядок вычисления триад, как и тетрад, может быть изменен, но только если допустить наличие триад, целенаправленно изменяющих этот порядок (например, триады, вызывающие переход на несколько шагов вперед или назад при каком-то условии).
Триады представляют собой линейную последовательность, а потому для них несложно написать тривиальный алгоритм, который будет преобразовывать последовательность триад в последовательность команд результирующей программы (либо последовательность команд ассемблера). В этом их преимущество перед синтаксическими деревьями. Однако здесь требуется также и алгоритм, отвечающий за распределение памяти, необходимой для хранения промежуточных результатов вычисления, так как временные переменные для этой цели не используются. В этом отличие триад от тетрад.
Так же как и тетрады, триады не зависят от архитектуры вычислительной системы, на которую ориентирована результирующая программа. Поэтому они представляют собой машинно-независимую форму внутреннего представления программы. Триады требуют меньше памяти для своего представления, чем тетрады, они также явно отражают взаимосвязь операций между собой, что делает их применение удобным. Необходимость иметь алгоритм, отвечающий за распределение памяти для хранения промежуточных результатов, не является недостатком, так как удобно распределять результаты не только по доступным ячейкам временной памяти, но и по имеющимся регистрам процессора. Это дает определенные преимущества. Триады ближе к двухадресным машинным командам, чем тетрады, а именно эти команды более всего распространены в наборах команд большинства современных компьютеров.
Например, выражение А ：= В * С + D - В * 10, записанное в виде триад, будет иметь вид:
* (В, С)
+ (Al, D)
* (В. 10)
- Г2,人3)
:= (А「4)
Здесь операции обозначены соответствующим знаком (при этом присвоение также является операцией), а знак 人 означает ссылку операнда одной триады на результат другой.
Обратная польская запись операций
Обратная (постфиксная) польская запись — очень удобная для вычисления выражений форма записи операций и операндов. Эта форма предусматривает, что знаки операций записываются после операндов.
Более подробно обратная польская запись рассмотрена далее в разделе «Обратная польская запись операций».
Ассемблерный код и машинные команды
Машинные команды удобны тем, что при их использовании внутреннее представление программы полностью соответствует объектному коду, и сложные преобразования не требуются. Команды ассемблера представляют собой лишь форму записи машинных команд (см. раздел «Трансляторы, компиляторы и интерпретаторы —общая схема работы»), а потому в качестве формы внутреннего представления программы практически ничем не отличаются от них.
Однако использование команд ассемблера или машинных команд для внутреннего представления программы требует дополнительных структур для отображения взаимосвязи операций. Очевидно, что в этом случае внутреннее представление программы получается зависимым от архитектуры вычислительной системы, на которую ориентирован результирующий код. Значит, при ориентации компилятора на другой результирующий код потребуется перестраивать как само внутреннее представление программы, так и методы его обработки (при использовании триад или тетрад этого не требуется).
Тем не менее, машинные команды — это язык, на котором должна быть записана результирующая программа. Поэтому компилятор так или иначе должен работать с ними. Кроме того, только обрабатывая машинные команды (или их представление в форме команд ассемблера), можно добиться наиболее эффективной результирующей программы (см. далее раздел «Оптимизация кода. Основные методы оптимизации» главы 2). Отсюда следует, что любой компилятор работает с представлением результирующей программы в форме машинных команд, однако их обработка происходит, как правило, на завершающих этапах фазы генерации кода.
Обратная польская запись операций
Обратная польская запись — это постфиксная запись операций. Она была предложена польским математиком Я. Лукашевичем, откуда и происходит ее название [4, т. 2, 17, 52]1.
Ошибочно думать, что польская запись выражений используется для записи арифметических выражений в Польше — это не так. В Польше, как и во многих других странах мира, пользуются привычной всем инфиксной формой записи, когда знаки математических операций ставятся между операндами.
В этой записи знаки операций записываются непосредственно за операндами. По сравнению с обычной (инфиксной) записью операций в польской записи операнды следуют в том же порядке, а знаки операций — строго в порядке их выполнения. Тот факт, что в этой форме записи все операции выполняются в том порядке, в котором они записаны, делает ее чрезвычайно удобной для вычисления выражений на компьютере. Польская запись не требует учитывать приоритет операций, в ней не употребляются скобки, и в этом ее основное преимущество.
Она чрезвычайно эффективна в тех случаях, когда для вычислений используется стек. Ниже будет рассмотрен алгоритм вычисления выражений в форме обратной польской записи с использованием стека.
Главный недостаток обратной польской записи также проистекает из метода вычисления выражений в ней: поскольку используется стек, то для работы с ним всегда доступна только верхушка стека, а это делает крайне затруднительной оптимизацию выражений в форме обратной польской записи. Выражения в форме обратной польской записи почти не поддаются оптимизации.
Но там, где оптимизация вычисления выражений не требуется или не имеет большого значения, обратная польская запись оказывается очень удобным методом внутреннего представления программы.
Обратная польская запись была предложена первоначально для записи арифметических выражений. Однако этим ее применение не ограничивается. В компиляторе можно порождать код в форме обратной польской записи для вычисления практически любых выражений1. Для этого достаточно ввести знаки, предусматривающие вычисление соответствующих операций. В том числе, возможно ввести операции условного и безусловного перехода, предполагающие изменение последовательности хода вычислений и перемещение вперед или назад на некоторое количество шагов в зависимости от результата на верхушке стека [4, т. 2, 50, 52]. Такой подход позволяет очень широко применять форму обратной польской записи.
Преимущества и недостатки обратной польской записи определяют и сферу ее применения. Так, она очень широко используется для вычисления выражений в интерпретаторах и командных процессорах, где оптимизация вычислений либо отсутствует вовсе, либо не имеет существенного значения.
Вычисление выражений с помощью обратной польской записи
Вычисление выражений в обратной польской записи выполняется элементарно просто с помощью стека. Для этого выражение просматривается в порядке слева направо, и встречающиеся в нем элементы обрабатываются по следующим правилам: 1. если встречается операнд, то он помещается в стек (попадает на верхушку стека);.
если встречается знак унарной операции (операции, требующей одного операнда), то операнд выбирается с верхушки стека, операция выполняется, и результат помещается в стек (попадает на верхушку стека);
Язык программирования Forth является хорошим примером языка, где для вычисления любых выражений явно используются стек и обратная польская запись операций.
если встречается знак бинарной операции (операции, требующей двух операндов), то два операнда выбираются с верхушки стека, операция выполняется, и результат помещается в стек (попадает на верхушку стека).
Вычисление выражения заканчивается, когда достигается конец записи выражения. Результат вычисления при этом всегда находится на верхушке стека.
Очевидно, что данный алгоритм можно легко расширить и для более сложных операций, требующих трех и более операндов.
На рис. 5.6 рассмотрены примеры вычисления выражений в обратной польской записи.
Вычисление выражения 6+7+10*4=53
Рис. 5.6. Вычисление выражений в обратной польской записи с использованием стека
Схема СУ-компиляции для перевода выражений в обратную польскую запись
Существует множество алгоритмов, которые позволяют преобразовывать выражения из обычной (инфиксной) формы записи в обратную польскую запись.
Далее рассмотрен алгоритм, построенный на основе схемы СУ-компиляции для языка арифметических выражений с операциями +, -, * и /. В качестве основы алгоритма выбрана грамматика арифметических выражений, которая уже многократно рассматривалась ранее в качестве примера.
Эта грамматика приведена далее:
G({+.a.b},{S,T,E},P.S):
Р:
S -> S+T I S-Т I т
Т - Т*Е I Т/Е I Е Е т (S) I a I b
Схему СУ-компиляции будем строить из расчета, что имеется выходная цепочка символов R и известно текущее положение указателя в этой цепочке р. Распознаватель, выполняя свертку или подбор альтернативы по правилу грамматики, может записывать символы в выходную цепочку и менять текущее положение указателя в ней.
Построенная таким образом схема СУ-компиляции для преобразования арифметических выражений в форму обратной польской записи оказывается исключительно простой [4, т. 1, 2]. Она приведена ниже. В ней с каждым правилом грамматики связаны некоторые действия, которые записаны через ; (точку с запятой) сразу за правой частью каждого правила. Если никаких действий выполнять не нужно, в записи следует пустая цепочка (入)：
S тS+T;R(p)= "+". p=p+1
S -S-T;R(p)=p=p+1
S T;入
T -T*E;R(p)=p=p+1.
T тT/E:R(p)=p=p+1
T т E;入
E т (S);入
E t a; R(p) = "a", p = p + 1
E -> b; R(p) = "b", p = p + 1
Эту схему СУ-компиляции можно использовать для любого распознавателя без возвратов, допускающего разбор входных цепочек на основе правил данной грамматики (например, для распознавателя на основе грамматики операторного предшествования, рассмотренного в разделе «Восходящие распознаватели КС-языков без возвратов»). Тогда, в соответствии с принципом СУ-перевода, каждый раз выполняя свертку на основе некоторого правила распознаватель будет выполнять также и действия, связанные с этим правилом. В результате его работы будет построена цепочка R, содержащая представление исходного выражения в форме обратной польской записи (строго говоря, в данном случае автомат будет представлять собой уже не только КС-распознаватель, но и КС-преобразователь цепочек [4, т. 1, 2]). Представленная схема СУ-компиляции, с одной стороны, иллюстрирует, насколько просто выполнить преобразование выражения в форму обратной польской записи, а с другой стороны, демонстрирует, как на практике работает сам принцип СУ-компиляции.
Схемы СУ-перевода
Выше был описан принцип СУ-перевода, позволяющий получить линейную последовательность команд результирующей программы или внутреннего пред-
ставления программы в компиляторе на основе результатов синтаксического анализа. Теперь построим вариант алгоритма генерации кода, который получает на входе дерево операций и создает по нему фрагмент объектного кода для линейного участка результирующей программы. Рассмотрим примеры схем СУ-перевода для арифметических операций. Эти схемы достаточно просты, и на их основе можно проиллюстрировать, как выполняется СУ-перевод в компиляторе при генерации кода.' 、
В качестве формы представления результатов синтаксического разбора возьмем дерево операций (метод построения дерева операций рассмотрен выше). Для построения внутреннего представления объектного кода (в дальнейшем — просто кода) по дереву операций может использоваться простейшая рекурсивная процедура обхода дерева. Можно использовать и другие методы обхода дерева — важно, чтобы соблюдался принцип, что нижележащие операции в дереве всегда выполняются перед вышележащими операциями (порядок выполнения операций одного уровня не важен, он не влияет на результат и зависит от порядка обхода вершин дерева).
Процедура генерации кода по дереву операций, прежде всего, должна определить тип узла дерева. Он соответствует типу операции, символом которой помечен узел дерева. После определения типа узла процедура строит код для узла дерева в соответствии с типом операции. Если все узлы следующего уровня для текущего узла есть листья дерева, то в код включаются операнды, соответствующие этим листьям, и получившийся код становится результатом выполнения процедуры. Иначе процедура должна рекурсивно вызвать сама себя для генерации кода нижележащих узлов дерева и результат выполнения включить в свой порожденный код. Фактически, процедура генерации кода должна для каждого узла дерева выполнить конкатенацию цепочек команд, связанных с текущим узлом и с нижележащими узлами. Конкатенация цепочек выполняется таким образом, чтобы операции, связанные с нижележащими узлами, выполнялись до выполнения операции, связанной с текущим узлом.
Поэтому для построения внутреннего представления объектного кода по дереву вывода в первую очередь необходимо разработать формы представления объектного кода для четырех случаев, соответствующих видам текущего узла дерева вывода:
口 оба нижележащих узла дерева — листья, помеченные операндами;
口 только левый нижележащий узел является листом дерева;
口 только правый нижележащий узел является листом дерева;
□ оба нижележащих узла нё являются листьями дерева.
Рассмотрим построение двух видов внутреннего представления по дереву вывода:
построение списка триад по дереву вывода;
построение ассемблерного кода по дереву вывода.
Далее рассматриваются две функции, реализующие схемы СУ-перевода для каждого их этих случаев.
Пример схемы СУ-перевода дерева операций на язык ассемблера
В качестве языка ассемблера возьмем язык ассемблера процессоров типа Intel 80x86. При этом будем считать, что операнды могут быть помещены в 16-разряд- ные регистры процессора, и в коде результирующей объектной программы могут использоваться регистры АХ (аккумулятор) и DX (регистр данных), а также стек для хранения промежуточных результатов.
Функцию, реализующую перевод узла дерева в последовательность команд ассемблера, назовем Code. Входными данными функции должна быть информация об узле дерева операций. В ее реализации на каком-либо языке программирования эти данные можно представить в виде указателя на соответствующий узел дерева операций. Выходными данными является последовательность команд языка ассемблера. Будем считать, что она передается в виде строки, возвращаемой в качестве результата функции.
Code (Узел 2) push ахCode (Узел 3) mov dx, ахCode (Узел 2) push ахCode (Узел 3) mov dx, ахpop ах , act ах, dxpop ах , act ах, dxТогда четырем формам текущего узла дерева для каждой арифметической операции будут соответствовать фрагменты кода на языке ассемблера, приведенные в табл. 5.1. /
Code (Узел 2) push ах
Code (Узел 3) mov dx, ах
Code (Узел 2) push ах
Code (Узел 3) mov dx, ах
pop ах , act ах, dx
pop ах , act ах, dx
Таблица 5.1. Преобразование узлов дерева вывода в код на языке ассемблера для арифметических операций
Вид узла дерева
Результирующий код Примечание
I орег1
act
oper2
movax,operlact — команда
actax.oper2соответствующей
,операции
operl, oper2 — операнды (листья дерева)
орег1
act I
1 Узел 2 J
Code (Узел 2)Узел 2 — нижележащий
movdx.ахузел (не лист!) дерева
1 movах,operlCode (Узел 2) — код,
.порождаемый процедурой
аСах, *для нижележащего узла
Узел 2
I
I act
oper2
Code (Узел 2)Code (Узел 2) — код,
act ах орег2порождаемый процедурой
для нижележащего узла
Code (Узел 2) — код, порождаемый процедурой для нижележащего узла Code (Узел 3) — код, порождаемый процедурой для нижележащего узла push и pop — команды сохранения результатов в стеке и извлечения результатов из стека
Каждой допустимой арифметической операции будет соответствовать своя команда на языке ассемблера. Если взять в качестве примера операции сложения (+), вычитания (-), умножения (*) и деления (/), то им будут соответствовать команды add, sub, mul и div. Причем в ассемблере Intel 80x86 от типа операции зависит не только тип, но и синтаксис команды (операции mul и d1v в качестве первого операнда всегда предполагают регистр процессора АХ, который не нужно указывать в команде). Соответствующая команда должна записываться вместо act при порождении кода в зависимости от типа узла дерева.
Код, порождаемый для операции присвоения результата, будет отличаться от кода, порождаемого для арифметических операций. Кроме того, семантика языка требует, чтобы в левой части операции присвоения всегда был операнд, поэтому для нее возможны только два типа узлов дерева, влекущие порождение кода (два других типа узлов должны приводить к сообщению об ошибке, которая в компиляторе обнаруживается синтаксическим анализатором). Фрагменты кода для этой операции приведены ниже в табл. 5.2.
Таблица 5.2. Преобразование узлов дерева вывода в код на языке ассемблера для операции присвоения
Вид узла дереваРезультирующий код Ирнмечанне
~ Imov ах, oper2operl, орег2 — операнды
С mov operl, ax(листья дерева)
Code (Узел 2) mov operl. ахCode (Узел 2) mov operl. ахУзел 2Узел 2operloper2
Code (Узел 2) mov operl. ах
Code (Узел 2) mov operl. ах
Узел 2
Узел 2
Узел 2 — нижележащий узел (не лист!) дерева Code(Узeл 2) — код, порождаемый процедурой для нижележащего узла
Теперь последовательность порождаемого кода определена для всех возможных типов узлов дерева.
Рассмотрим в качестве примера выражение А := В * С + D - В * 10. Соответствующее ему дерево вывода приведено на рис. 5.7.
Рис. 5.7. Дерево операций для арифметического выражения «А := В * С + D - В * 10»Рис. 5.7. Дерево операций для арифметического выражения «А := В * С + D - В * 10»
Рис. 5.7. Дерево операций для арифметического выражения «А := В * С + D - В * 10»
Рис. 5.7. Дерево операций для арифметического выражения «А := В * С + D - В * 10»
Построим последовательность команд языка ассемблера, соответствующую дереву операций на рис. 5.7. Согласно принципу СУ-перевода, построение начинается от корня дерева. Для удобства иллюстрации рекурсивного построения последовательности команд все узлы дерева помечены от 1)1 до U5. Рассмотрим последовательность построения цепочки команд языка ассемблера по шагам рекурсии. Эта последовательность приведена ниже.
Шаг 1：Code(U2) mov А, ах
Шаг 2：Code(U3) push ах Code(U5) mov dx. ax pop ax sub ax, dx mov A, ax
Шаг 3：Code(U4), add ax, D push ax Code(U5) mov dx, ax pop ax sub ax, dx mov A.ax
Шаг 4：mov ax, В mul C add ax, D push ax Code(U5) mov dx. ax pop ax sub ax, dx mov A, ax
Шаг 5： mov ax, В mul C add ax, D
pusf
1 ax
mov
dx.
в
mul
10
mov
dx,
ax
pop
ax
sub
dX,
dx
mov A, ax
Полученный объектный код на языке ассемблера, очевидно, может быть оптимизирован. Вопросы оптимизации результирующего кода рассмотрены далее в разделе «Оптимизация кода. Основные методы оптимизации».
В рассмотренном примере при порождении кода преднамеренно не были приняты во внимание многие вопросы, возникающие при построении реальных компиляторов. Это было сделано для упрощения примера. Например, фрагменты кода, соответствующие различным узлам дерева, принимают во внимание тип операции, но никак не учитывают тип операндов. А в языке ассемблера операндам различных типов соответствуют существенно отличающиеся команды, могут использоваться различные регистры (например, если сравнить операции с целыми числами и числами с плавающей точкой). Некоторые типы операндов (например, строки) не могут быть обработаны одной командой языка, а требуют целой последовательности команд. Такую последовательность разумнее оформить в виде функции библиотеки языка, тогда выполнение операции будет представлять собой вызов этой функции.
Кроме того, ориентация на определенный язык ассемблера, очевидно, сводит на нет универсальность метода. Каждый тип операций жестко связывается с последовательностью определенных команд, ориентированных на некоторую архитектуру вычислительной системы.
Все эти требования ведут к тому, что в реальном компиляторе при генерации кода надо принимать во внимание очень многие особенности, зависящие как от семантики входного языка, так и от архитектуры целевой вычислительной системы, на которой будет выполняться результирующая программа. В результате увеличится число различных типов узлов дерева, каждому из которых будет соответствовать своя последовательность команд. Это может осложнить алгоритм генерации кода, что особенно нежелательно в том случае, если порождаемый код не является окончательным и требует дальнейшей обработки.
Указанных проблем можно избежать, если порождать код не в виде цепочки команд ассемблера, а в виде последовательности команд машинно-независимого метода внутреннего представления программы — например, тетрад или триад. ,
Пример схемы СУ-перевода дерева операций в последовательность триад
Как и в случае с порождением команд ассемблера, функцию, реализующую перевод узла дерева в последовательность триад, назовем Code. Входные и выходные данные у этой функции будут те же, что и при работе с командами ассемблера. Триады являются машинно-независимой формой внутреннего представления в компиляторе результирующей объектной программы, а потому не требуют оговорки дополнительных условий при генерации кода. Триады взаимосвязаны между собой, поэтому для установки корректной взаимосвязи функция генерации кода должна учитывать также текущий номер очередной триады (i).
Будем рассматривать те же варианты узлов дерева, что и для команд ассемблера. Тогда четырем формам текущего узла дерева будут соответствовать последовательности триад объектного кода, приведенные в табл. 5.3.
Таблица 5.3. Преобразование типовых узлов дерева вывода в
последовательность триад
Вид узла дерева
Результирующий код
Примечание
I act
i) act (operl,oper2)
act — тип триады
operl, орег2 — операнды
1 operl I
I орег2 I
(листья дерева вывода)
1) Code (Узел 2, 1) 1+j) act (operl, >+j-l)
Узел 2 — нижележащий узел дерева вывода Code (Узел 2, i)— последовательность
орег!орег!1) Code (Узел 2. i) i+j) act C+j-L oper2)1) Code (Узел 2. i) i+j) act C+j-L oper2)1) Code (Узел 2. 1) i+j) Code (Узел 3. i+j)1+j+k) act (一+j-L Г+j+k-l)1) Code (Узел 2. 1) i+j) Code (Узел 3. i+j)1+j+k) act (一+j-L Г+j+k-l)триад, порождаемая для Узла 2, начиная с триады с номером i, j — количество триад, порождаемых для Узла 2
орег!
орег!
1) Code (Узел 2. i) i+j) act C+j-L oper2)
1) Code (Узел 2. i) i+j) act C+j-L oper2)
1) Code (Узел 2. 1) i+j) Code (Узел 3. i+j)
1+j+k) act (一+j-L Г+j+k-l)
1) Code (Узел 2. 1) i+j) Code (Узел 3. i+j)
1+j+k) act (一+j-L Г+j+k-l)
Узел 2 — нижележащий узел дерева вывода
Code (Узел 2, i)— последовательность
триад, порождаемая для Узла 2, начиная с триады с номером i, j — количество триад, порождаемых для Узла 2
Узел 2, Узел 3 — нижележащие узлы дерева вывода Code (Узел 2, i)— последовательность триад, порождаемая для Узла 2, начиная с триады с номером i, j — количество триад, порождаемых для Узла 2 Code (Узел 3, i+j)— последовательность триад, порождаемая для Узла 3, начиная с триады с номером i+j, к — количество триад, порождаемых для Узла 3
Для триад не требуется учитывать операцию присваивания как отдельный тип узла дерева. Она преобразуется в триаду обычного вида.
Рассмотрим в качестве примера то же самое выражение/А ：= В * С + D - В * 10.
Соответствующее ему дерево вывода уже было приведено на рис. 5.7.
Построим последовательность триад, соответствующую дереву операций на рис. 5.7.
Согласно принципу СУ-перевода, построение начинается от корня дерева.
Шаг 1:1)1)Шаг 2:1)J) 1-1) 1)Шаг 3：1)к) J) 1-1) 1)Шаг 4：1)2) 3) 1-1) 1)Шаг 5:1)2) 3) 4) 5)Шаг 1:1)1)Шаг 2:1)J) 1-1) 1)Шаг 3：1)к) J) 1-1) 1)Шаг 4：1)2) 3) 1-1) 1)Шаг 5:1)2) 3) 4) 5)Code (U2, 1) :=(А, Л1-1) Code (U3. 1) Code (U5, j) -(个-L牛2) :=(A. x1-l) Code (U4, 1) + Гк-L D) Code (U5. j) -("j-l, "1-2) :=(A. xi-l) * (B. C) + (T, D) Code (U5, 3)：=(A, AI-1) * (B. C) +「L D) * (B, 10) -「2「3) :=(A「4)Code (U2, 1) :=(А, Л1-1) Code (U3. 1) Code (U5, j) -(个-L牛2) :=(A. x1-l) Code (U4, 1) + Гк-L D) Code (U5. j) -("j-l, "1-2) :=(A. xi-l) * (B. C) + (T, D) Code (U5, 3)：=(A, AI-1) * (B. C) +「L D) * (B, 10) -「2「3) :=(A「4)
Шаг 1:1)
1)
Шаг 2:1)
J) 1-1) 1)
Шаг 3：1)
к) J) 1-1) 1)
Шаг 4：1)
2) 3) 1-1) 1)
Шаг 5:1)
2) 3) 4) 5)
Шаг 1:1)
1)
Шаг 2:1)
J) 1-1) 1)
Шаг 3：1)
к) J) 1-1) 1)
Шаг 4：1)
2) 3) 1-1) 1)
Шаг 5:1)
2) 3) 4) 5)
Code (U2, 1) :=(А, Л1-1) Code (U3. 1) Code (U5, j) -(个-L牛2) :=(A. x1-l) Code (U4, 1) + Гк-L D) Code (U5. j) -("j-l, "1-2) :=(A. xi-l) * (B. C) + (T, D) Code (U5, 3)
：=(A, AI-1) * (B. C) +「L D) * (B, 10) -「2「3) :=(A「4)
Code (U2, 1) :=(А, Л1-1) Code (U3. 1) Code (U5, j) -(个-L牛2) :=(A. x1-l) Code (U4, 1) + Гк-L D) Code (U5. j) -("j-l, "1-2) :=(A. xi-l) * (B. C) + (T, D) Code (U5, 3)
：=(A, AI-1) * (B. C) +「L D) * (B, 10) -「2「3) :=(A「4)
Следует обратить внимание, что в данном алгоритме последовательные номера триад (а следовательно, и ссылки на них) устанавливаются не сразу. Это не имеет значения при рекурсивной организации процедуры, но если используется другой способ обхода дерева операций, при реализации генерации кода лучше увязывать триады между собой именно по ссылке (указателю), а не по порядковому номеру. Использование триад позволяет сократить количество рассматриваемых вариантов узлов дерева операций. В этом случае не требуется принимать во внимание типы операндов и ориентироваться на архитектуру целевой вычислительной системы. Все эти аспекты необходимо будет принимать во внимание уже на этапе преобразования триад в последовательность команд ассемблера или непосредственно в последовательность машинных команд результирующей программы.
Как и последовательность команд ассемблера, последовательность триад можно оптимизировать. Для триад разработаны универсальные (машинно-независимые) алгоритмы оптимизации кода. Уже после их выполнения (оптимизации внутреннего представления) триады могут быть преобразованы в команды на языке ассемблера.
Оптимизация кода. Основные методы оптимизации
Общие принципы оптимизации кода
Как уже говорилось выше, в подавляющем большинстве случаев генерация кода выполняется компилятором не для всей исходной программы в целом, а последовательно для отдельных ее конструкций. Полученные для каждой синтаксиче-
ской конструкции входной программы фрагменты результирующего кода также последовательно объединяются в общий текст результирующей программы. При этом связи между различными фрагментами результирующего кода в полной мере не учитываются.
В свою очередь, для построения результирующего кода различных синтаксических конструкций входного языка используется метод СУ-перевода. Он также объединяет цепочки построенного кода по структуре дерева без учета их взаимосвязей (что видно из примеров, приведенных выше).
Построенный таким образом код результирующей программы может содержать лишние команды и данные. Это снижает эффективность выполнения результирующей программы. В принципе, компилятор может завершить на этом генерацию кода, поскольку результирующая программа построена, и она является эквивалентной по смыслу (семантике) программе на входном языке. Однако эффективность результирующей программы важна для ее разработчика, поэтому большинство современных компиляторов выполняют еще один этап компиляции —оптимизацию результирующей программы (или просто «оптимизацию»), чтобы повысить ее эффективность насколько это возможно.
Важно отметить два момента: во-первых, выделение оптимизации в отдельный этап генерации кода — это вынужденный шаг. Компилятор вынужден производить оптимизацию построенного кода, поскольку он не может выполнить семантический анализ всей входной программы в целом, оценить ее смысл и, исходя из него, построить результирующую программу. Оптимизация нужна, поскольку результирующая программа строится не вся сразу, а поэтапно. Во-вторых, оптимизация —это необязательный этап компиляции. Компилятор может вообще не выполнять оптимизацию, и при этом результирующая программа будет правильной, а сам компилятор будет полностью выполнять свои функции. Однако практически все компиляторы так или иначе выполняют оптимизацию, поскольку их разработчики стремятся завоевать хорошие позиции на рынке средств разработки программного обеспечения. Оптимизация, которая существенно влияет на эффективность результирующей программы, является здесь немаловажным фактором. Теперь дадим определение понятию «оптимизация».
Оптимизация программы — это обработка, связанная с переупорядочиванием и изменением операций в компилируемой программе с целью получения более эффективной результирующей объектной программы. Оптимизация выполняется на этапах подготовки к генерации и непосредственно при генерации объектного кода. В качестве показателей эффективности результирующей программы можно использовать два критерия: объем памяти, необходимый для выполнения результирующей программы (для хранения всех ее данных и кода), и скорость выполнения (быстродействие) программы. Далеко не всегда удается выполнить оптимизацию так, чтобы удовлетворить обоим этим критериям. Зачастую сокращение необходимого программе объема данных ведет к уменьшению ее быстродействия и наоборот. Поэтому для оптимизации обычно выбирается либо один из упомянутых критериев, либо некий комплексный критерий, основанный на них. Выбор
критерия оптимизации обычно выполняет непосредственно пользователь в настройках компилятора.
Но, даже выбрав критерий оптимизации, в общем случае практически невозможно построить код результирующей программы, который бы являлся самым коротким или самым быстрым кодом, соответствующим входной программе. Дело в том, что нет алгоритмического способа нахождения самой короткой или самой быстрой результирующей программы, эквивалентной заданной исходной программе. Эта задача в принципе неразрешима. Существуют алгоритмы, которые можно ускорять сколь угодно много раз для большого числа возможных входных данных, и при этом для других наборов входных данных они окажутся неоптимальными [4, т. 2]. К тому же компилятор обладает весьма ограниченными средствами анализа семантики всей входной программы в целом. Все, что можно сделать на этапе оптимизации — это выполнить над заданной программой последовательность преобразований в надежде сделать ее более эффективной.
Чтобы оценить эффективность результирующей программы, полученной с помощью того или иного компилятора, часто прибегают к сравнению ее с эквивалентной программой (программой, реализующей тот же алгоритм), полученной из исходной программы, написанной на языке ассемблера. Лучшие оптимизирующие компиляторы могут получать результирующие объектные программы из сложных исходных программ, написанных на языках высокого уровня, почти не уступающие по качеству программам на языке ассемблера. Обычно соотношение эффективности программ, построенных с помощью компиляторов с языков высокого уровня, и эффективности программ, построенных с помощью ассемблера, составляет 1,1-1,3. То есть объектная программа, построенная с помощью компилятора с языка высокого уровня, обычно содержит на 10-30% больше команд, чем эквивалентная ей объектная программа, построенная с помощью ассемблера, а также выполняется на 10-30% медленнее1.
Это очень неплохие результаты, достигнутые компиляторами с языков высокого уровня, если сравнить трудозатраты на разработку программ на языке ассемблера и языке высокого уровня. Далеко не каждую программу можно реализовать на языке ассемблера в приемлемые сроки (а значит, и выполнить напрямую приведенное выше сравнение можно только для узкого круга программ).
Оптимизацию можно выполнять на любой стадии генерации кода, начиная от завершения синтаксического разбора и вплоть до последнего этапа, когда порождается код результирующей программы. Если компилятор использует несколько различных форм внутреннего представления программы, то каждая из них может быть подвергнута оптимизации, причем различные формы внутреннего представления ориентированы на различные методы оптимизации [4, т. 2, 50, 52]. Таким образом, оптимизация в компиляторе может выполняться несколько раз на этапе генерации кода.
Обычно такое сравнение выполняют для специальных тестовых программ, для которых код на языке ассемблера уже заранее известен. Полученные результаты распространяют на все множество входных программ, поэтому их можно считать очень усредненными.
Принципиально различаются два основных вида оптимизирующих преобразований:
преобразования исходной программы (в форме ее внутреннего представления в компиляторе), не зависящие от результирующего объектного языка;
преобразования результирующей объектной программы.
Первый вид преобразований не зависит от архитектуры целевой вычислительной системы, на которой будет выполняться результирующая программа. Обычно он основан на выполнении хорошо известных и обоснованных математических и логических преобразований, производимых над внутренним представлением программы (некоторые из них будут рассмотрены ниже).
Второй вид преобразований может зависеть не только от свойств объектного языка (что очевидно), но и от архитектуры вычислительной системы, на которой будет выполняться результирующая программа. Так, например, при оптимизации могут учитываться объем кэш-памяти и методы организации конвейерных операций центрального процессора. В большинстве случаев эти преобразования сильно зависят от реализации компилятора и являются «ноу-хау» производителей компилятора. Именно этот тип оптимизирующих преобразований позволяет существенно повысить эффективность результирующего кода.
Используемые методы оптимизации ни при каких условиях не должны приводить к изменению «смысла» исходной программы (то есть к таким ситуациям, когда результат выполнения программы изменяется после ее оптимизации). Для преобразований первого вида проблем обычно не возникает. Преобразования второго вида могут вызывать сложности, поскольку не все методы оптимизации, используемые создателями компиляторов, могут быть теоретически обоснованы и доказаны для всех возможных видов исходных программ. Именно эти преобразования могут повлиять на «смысл» исходной программы. Поэтому большинство компиляторов предусматривают возможность отключать те или иные из возможных методов оптимизации.
Нередко оптимизация ведет к тому, что смысл программы оказывается не совсем таким, каким его ожидал увидеть разработчик программы, но не по причине наличия ошибки в оптимизирующей части компилятора, а потому, что пользователь не принимал во внимание некоторые аспекты программы, связанные с оптимизацией. Например, компилятор может исключить из программы вызов некоторой функции с заранее известным результатом, но если эта функция имела «побочный эффект» — изменяла некоторые значения в глобальной памяти — смысл программы может измениться. Чаще всего это говорит о плохом стиле программирования исходной программы. Такие ошибки трудноуловимы, для их нахождения следует обратить внимание на предупреждения разработчику программы, выдаваемые семантическим анализом, или отключить оптимизацию. Применение оптимизации также нецелесообразно в процессе отладки исходной программы. У современных компиляторов существуют возможности выбора не только общего критерия оптимизации, но и отдельных методов, которые будут использоваться при выполнении оптимизации. ' •
Методы преобразования программы зависят от типов синтаксических конструкций исходного языка. Теоретически разработаны методы оптимизации для многих типовых конструкций языков программирования.
Оптимизация может выполняться для следующих типовых синтаксических конструкций:
линейных участков программы;
логических выражений;
циклов;
вызовов процедур и функций;
других конструкций входного языка.
Во всех случаях могут использоваться как машинно-зависимые, так и машиннонезависимые методы оптимизации.
Далее будут рассмотрены только некоторые машинно-независимые методы оптимизации, касающиеся в первую очередь линейных участков программы. Перечень их здесь далеко не полный. С остальными машинно-независимыми методами можно более подробно ознакомиться в [4, т. 2]. Что касается машинно-зависимых методов, то они, как правило, редко упоминаются в литературе. Некоторые из них рассматриваются в технических описаниях компиляторов. Здесь эти методы будут рассмотрены только в самом общем виде.
Оптимизация линейных участков программы
Принципы оптимизации линейных участков
Линейный участок программы — это выполняемая по порядку последовательность операций, имеющая один вход и один выход. Чаще всего линейный участок содержит последовательность вычислений, состоящих из арифметических операций и операторов присвоения значений переменным.
Любая программа предусматривает выполнение вычислений и присваивания значений, поэтому линейные участки встречаются в любой программе. В реальных программах они составляют существенную часть программного кода. Поэтому для линейных участков разработан широкий спектр методов оптимизации кода. Кроме того, характерной особенностью любого линейного участка является последовательный порядок выполнения операций, входящих в его состав. Ни одна операция в составе линейного участка программы не может быть пропущена, ни одна операция не может быть выполнена большее число раз, чем соседние с нею операции (иначе этот фрагмент программы просто не будет линейным участком). Это существенно упрощает задачу оптимизации линейных участков программ. Поскольку все операции линейного участка выполняются последовательно, их можно пронумеровать в порядке выполнения.
Для операций, составляющих линейный участок программы, могут применяться следующие виды оптимизирующих преобразований:
удаление бесполезных присваиваний;
исключение избыточных вычислений (лишних операций);
свертка операций объектного кода;
перестановка операций;
арифметические преобразования.
Удаление бесполезных присваиваний заключается в том, что если в составе линейного участка программы имеется операция присваивания значения некоторой произвольной переменной А с номером 1, а также операция присваивания значения той же переменной А с номером j, i<j, и ни в одной операции между i и j не используется значение переменной А, то операция присваивания значения с номером i является бесполезной. Фактически, бесполезная операция присваивания значения дает переменной значение, которое нигде не используется. Такая операция может быть исключена без ущерба для смысла программы.
В общем случае бесполезными могут оказаться не только операции присвоения, но и любые другие операции линейного участка, результат выполнения которых нигде не используется.
Например, во фрагменте программы:
А := В * С D := В + С А := D * С
операция присваивания А ：= В * С: является бесполезной и может быть удалена. Вместе с удалением операции присвоения здесь может быть удалена и операция умножения, которая в результате также окажется бесполезной.
Обнаружение бесполезных операций присваивания далеко не всегда столь очевидно, как было показано в примере выше. Проблемы могут возникнуть, если между двумя операциями присваивания в линейном участке выполняются действия над указателями (адресами памяти) или вызовы функций, имеющих так называемый «побочный эффект».
Например, в следующем фрагменте программы:
Р := @А;
А := В * С;
D := РА + С:
А := D * С;
операция присваивания А := В * С: уже не является бесполезной, хотя это и не столь очевидно. В этом случае неверно следовать простому принципу, заключающемуся в том, что если переменная, которой присвоено значение в операции с номером 1, не встречается ни в одной операции между 1 и j, то операция присваивания с номером i является бесполезной.
Не всегда удается установить, используется или нет присвоенное переменной значение, только на основании факта упоминания переменной в операциях. Тогда устранение лишних присваиваний становится достаточно сложной задачей, требующей учета операций с адресами памяти и ссылками.
Исключение избыточных вычислений (лишних операций) заключается в нахождении и удалении из объектного кода операций, которые повторно обрабатыва-
ют одни и те же операнды. Операция линейного участка с порядковым номером i считается лишней, если существует идентичная ей операция с порядковым номером j, j<i, и никакой операнд, обрабатываемый этой операцией, не изменялся никакой операцией, имеющей порядковый номер между i и j.
Свертка объектного кода — это выполнение во время компиляции тех операций исходной программы, для которых значения операндов уже известны. Тривиальным примером свертки является вычисление выражений, все операнды которых являются константами. Более сложные варианты алгоритма свертки принимают во внимание также и переменные, и функции, значения для которых уже известны. Не всегда компилятору удается выполнить свертку, даже если выражение допускает ее выполнение. Например, выражение А ：=2*В*С*3; может быть преобразовано к виду А ：=6*В*С:,но при порядке вычислений А:=2*(В*(С*3)): это не столь очевидно. Для более эффективного выполнения свертки объектного кода возможно совместить ее выполнение с другим методом — перестановкой операций.
Хорошим стилем программирования является объединение вместе операций, производимых над константами, чтобы облегчить компилятору выполнение свертки. Например, если имеется константа PI = 3.14, представляющая соответствующую математическую постоянную, то операцию b = sin(2兀а): лучше записать в виде В := sin(2 * PI * А) ； или даже В := sin((2 * PI) * А) ：, чем в виде В ：= sin(2 * А * PI);. Перестановка операций заключается в изменении порядка следования операций, которое может повысить эффективность программы, но не будет влиять на конечный результат вычислений.
Например, операции умножения в выражении А ：=2*В*3*С; можно переставить без изменения конечного результата и выполнить в порядке А ：= (2*3) * (В * С);. Тогда представляется возможным выполнить свертку и сократить количество операций.
Другое выражение А ：= (В + С) + (D + Е) ： может потребовать, как минимум, одной ячейки памяти (или регистра процессора) для хранения промежуточного результата. Но при вычислении его в порядке A:=B+(C+(D + E))： можно обойтись одним регистром, в то время как результат будет тем же.
Особое значение перестановка операций приобретает в тех случаях, когда порядок их выполнения влияет на эффективность программы в зависимости от архитектурных особенностей целевой вычислительной системы (таких, как использование регистров процессора, конвейеров обработки данных и т. п.). Эти особенности рассмотрены далее в подразделе, посвященном машинно-зависимым методам оптимизации.
Арифметические преобразования представляют собой выполнение изменения характера и порядка следования операций на основании известных алгебраических и логических тождеств.
Например, выражение A :=B*C + B*D; может быть заменено на А ：= В * (С + D);. Конечный результат при этом не изменится, но объектный код будет содержать на одну операцию умножения меньше.
К арифметическим преобразованиям можно отнести и такие действия, как замена возведения в степень на умножение; а целочисленного умножения на константы,
кратные 2, — на выполнение операций сдвига. В обоих случаях удается повысить быстродействие программы заменой сложных операций более простыми.
Далее подробно рассмотрены два метода: свертка объектного кода и исключение лишних операций.
Свертка объектного кода
Свертка объектного кода — это выполнение во время компиляции тех операций исходной программы, для которых значения операндов уже известны. Нет необходимости многократно выполнять эти операции в результирующей программе — вполне достаточно один раз выполнить их при компиляции программы.
Простейший вариант свертки — выполнение в компиляторе операций, операндами которых являются константы. Несколько более сложен процесс определения тех операций, значения которых могут быть известны в результате выполнения других операций. Для этой цели при оптимизации линейных участков программы используется специальный алгоритм свертки объектного кода.
Алгоритм свертки для линейного участка программы работает со специальной таблицей Т, которая содержит пары (<переменная>,<константа>) для всех переменных, значения которых уже известны. Кроме того, алгоритм свертки помечает те операции во внутреннем представлении программы, для которых в результате свертки уже не требуется генерация кода. Так как при выполнении алгоритма свертки учитывается взаимосвязь операций, то удобной формой представления для него являются триады, так как в других формах представления операций (таких как тетрады или команды ассемблера) требуются дополнительные структуры, чтобы отразить связь результатов одних операций с операндами других.
Рассмотрим выполнение алгоритма свертки объектного кода для триад. Для пометки операций, не требующих порождения объектного кода, будем использовать триады специального вида С(К.О).
Алгоритм свертки триад последовательно просматривает триады линейного участка и для каждой триады делает следующее:
если операнд есть переменная, которая содержится в таблице Т, то операнд заменяется соответствующим значением константы;
если операнд есть ссылка на особую триаду типа С(К.О), то операнд заменяется значением константы К;
если все операнды триады являются константами, то триада может быть свернута. Тогда данная триада выполняется, и вместо нее помещается особая триада вида С(К.О), где К — константа, являющаяся результатом выполнения свернутой триады (при генерации кода для особой триады объектный код не порождается, а потому она в дальнейшем может быть просто исключена);
если триада является присваиванием типа А := В, тогда:
Q если В — константа, то А со значением константы заносится в таблицу Т (есл; там уже было старое значение для А, то это старое значение исключается);
Q если В — не константа, то А вообще исключается из таблицы Т, если онс там есть.
Рассмотрим пример выполнения алгоритма.
Пусть фрагмент исходной программы (записанной на языке типа Pascal) имеет вид:
I := 1 + 1;
I := 3:
J := 6*1+1:
Ее внутреннее представление в форме триад будет иметь вид:
+ (1.1)
：= (1/1)
:= (1.3)
* (6.1)■
+「4,1)
:=(『5)
Процесс выполнения алгоритма свертки показан в табл. 5.4.
Таблица 5.4. Пример работы алгоритма свертки
Триада Шаг 1Шаг 2Шаг 3
Шаг 4Шаг 5Шаг 6
1С(2, 0)С(2,0)С (2, 0)
2:=(1,Л1):=(I, 2):= (I, 2)
3：=(1,3):=(1,3):= (1,3)
4*(6, I)*(6,I)* (6, I)
5+(л4, I)+ (л4,1)+「4, I)
6：= U. л5) 尸 CJ, л5) 尸(J, л5)
С (2, 0) С (2, 0) С (2, 0) 尸(I, 2) := (I, 2) := (I, 2) ：=(I, 3) := (I, 3) := (I, 3)
С (18, 0) С (18, 0) С (18, 0) + (л4, I) С (21,0) С (21, 0) ：=CJ,入5) := U- л5) ：= U-21)
Т(,)(1,2)(1,3)
(I, 3)(I, 3)(I, 3)
0, 21)
Если исключить особые триады типа С(К,О) (которые не порождают объектного кода), то в результате выполнения свертки получим следующую последовательность триад:
:= (1.2)
:= (1.3)
:= (J.21)
Алгоритм свертки объектного кода позволяет исключить из линейного участка программы операции, для которых на этапе компиляции уже известен результат. За счет этого сокращается время выполнения1, а также объем кода результирующей программы.
Даже если принять во внимание, что время на выполнение операции будет потрачено компилятором при порождении результирующей программы, то все равно мы имеем выигрыш во времени. Во-первых, любая результирующая программа создается (а значит, и компилируется окончательно) только один раз, а выполняется многократно; во-вторых, оптимизируемый линейный участок может входить в состав оператора цикла или вызова функции, и тогда выигрыш очевиден.
Свертка объектного кода, в принципе, может выполняться не только для линейных участков программы. Когда операндами являются константы, логика выполнения программы значения не имеет — свертка может быть выполнена в любом случае. Если же необходимо учитывать известные значения переменных, то нужно принимать во внимание и логику выполнения результирующей программы. Поэтому для нелинейных участков программы (ветвлений и циклов) алгоритм будет более сложным, чем последовательный просмртр линейного списка триад.
Исключение лишних операций
Алгоритм исключения лишних операций просматривает операции в порядке их следования. Так же как и алгоритму свертки, алгоритму исключения лишних операций проще всего работать с триадами, потому что они полностью отражают взаимосвязь операций.
Рассмотрим алгоритм исключения лишних операций для триад.
Чтобы следить за внутренней зависимостью переменных и триад, алгоритм присваивает им некоторые значения, называемые числами зависимости, по следующим правилам:
изначально для каждой переменной ее число зависимости равно 0, так как в начале работы программы значение переменной не зависит ни от какой триады;
после обработки i-й триады, в которой переменной А присваивается некоторое значение, число зависимости A (dep(A)) получает значение 1, так как значение А теперь зависит от данной i-й триады;
при обработке i-й триады ее число зависимости (dep(1)) принимается равным значению 1+(максимальное из чисел зависимости операндов).
Таким образом, при использовании чисел зависимости триад и переменных можно утверждать, что если i-я триада идентична j-й триаде (j<1), то i-я триада считается лишней в том и только в том случае, когда dep(i )=dep(j).
Алгоритм исключения лишних операций использует в своей работе триады особого вида SAME (j, 0). Если такая триада встречается в позиции с номером 1, то это означает, что в исходной последовательности триад некоторая триада 1 идентична триаде j.
Алгоритм исключения лишних операций последовательно просматривает триады линейного участка. Он состоит из следующих шагов, выполняемых для каждой триады:
если какой-то операнд триады ссылается на особую триаду вида SAME(j.0), то он заменяется на ссылку на триаду с номером j (人j);
вычисляется число зависимости текущей триады с номером i исходя из чисел зависимости ее операндов;
если в просмотренной части списка триад существует идентичная j-я триада, причем j<i и dep(i )=dep( j), то текущая триада i заменяется на триаду особого вида SAME(j.O);
если текущая триада есть присвоение, то вычисляется число зависимости соответствующей переменной.'
Рассмотрим работу алгоритма на примере:
D := D + С*В;
А := D + С*В：
С := D + С*В;
Этому фрагменту программы будет соответствовать следующая последовательность триад:
* (С,В)
+ (DC)
:= (D/2)
* (С.В)
+ (D「4)
:= (А；5)
* (С.В)
+ (D/7)
:= (С「8)
Видно, что в данном примере некоторые операции вычисляются дважды над одними и теми же операндами, а значит, они являются лишними и могут быть исключены. Работа алгоритма исключения лишних операций отражена в табл. 5.5.
Таблица 5.5. Пример работы алгоритма исключения лишних операций
Обрабатываемая триада i
Числа зависимостиЧисла зависимости Триады, полученные
переменныхтриадпосле выполнения
А ВС D dep(i) ■алгоритма
* (С, В)
+ (D,*)
:= (D, Л2)
* (С, В)
+ (D, Л4) 6):= (А,⑸
* (С, В)
+ (DJ7)
:= (С, *)
000011)* (С, В)
000022)+ (D,Л1)
000333):= (D,л2)
000314)SAME (1,0)
000345)+ (D,л1)
600356):= (А,л5)
600317)SAME (1,0)
600348)SAME (5,0)
609359):= (С,А5)
Теперь, если исключить триады особого вида SAME( j,0), то в результате выполнения алгоритма получим следующую последовательность триад: 1. * (С,В) 2. + (DC) 3. ：= (D/2) 4. + (D「l)
:= (А/4)
:= (С「4)
Обратите внимание, что в итоговой последовательности изменилась нумерация триад и номера в ссылках одних триад на другие. Если в компиляторе в качестве ссылок использовать не номера триад, а непосредственно указатели на них, то изменение ссылок в таком варианте не потребуется.
Алгоритм исключения лишних операций позволяет избежать повторного выполнения одних и тех же операций над одними и теми же операндами. В результате оптимизации по этому алгоритму сокращается и время выполнения, и объем кода результирующей программы.
Другие методы оптимизации программ
Оптимизация вычисления логических выражений
Особенность оптимизации логических выражений заключается в том, что не всегда необходимо полностью выполнять вычисление всего выражения для того, чтобы знать его результат. Иногда по результату первой операции или даже по значению одного операнда можно заранее определить результат вычисления всего выражения.
Операция называется предопределенной для некоторого значения операнда, если ее результат зависит только от этого операнда и остается неизменным (инвариантным) относительно значений других операндов.
Операция логического сложения (or) является предопределенной для логического значения «истина» (true), а операция логического умножения (and) — предопределена для логического значения «ложь» (false).
Эти факты могут быть использованы для оптимизации логических выражений. Действительно, получив значение «истина» в последовательности логических сложений или значение «ложь» в последовательности логических умножений, нет никакой необходимости далее производить вычисления — результат уже определен и известен.
Например, выражение A or В or С or D не имеет смысла вычислять, если известно, что значение переменной А есть True («истина»).
Компиляторы строят объектный код вычисления логических выражений таким образом, что вычисление выражения прекращается сразу же, как только его значение становится предопределенным. Это позволяет ускорить вычисления при выполнении результирующей программы. В сочетании с преобразованиями логических выражений на основе тождеств булевой алгебры и перестановкой операций эффективность данного метода может быть несколько увеличена.
Не всегда такие преобразования инвариантны к смыслу программы. Например, при вычислении выражения A or F(B) or G(C) функции F и G не будут вызваны и выполнены, если значением переменной А является True. Это не важно, если результатом этих функций является только возвращаемое ими значение, но если они обладают «побочным эффектом» (о котором было сказано выше в замечаниях), то семантика программы может измениться.
В большинстве случаев современные компиляторы позволяют исключить такого рода оптимизацию, и тогда все логические выражения будут вычисляться до конца, без учета предопределенности результата. Однако лучше избегать такого рода «побочных эффектов», которые, как правило, говорят о плохом стиле программирования.
Хорошим стилем считается также принимать во внимание эту особенность вычисления логических выражений. Тогда операнды в логических выражениях следует стремиться располагать таким образом, чтобы в первую очередь вычислялись те из них, которые чаще определяют все значение выражения. Кроме того, значения функций лучше вычислять в конце, а не в начале логического выражения, чтобы избежать лишних обращений к ним. Так, рассмотренное выше выражение лучше записывать и вычислять в порядке A or F(B) or G(C), чем в порядке F(B) or G(C) or A.
He только логические операции могут иметь предопределенный результат. Некоторые математические операции и функции также обладают этим свойством. Например, умножение на 0 не имеет смысла выполнять.
Другой пример такого рода преобразований — это исключение вычислений для инвариантных операндов.
Операция называется инвариантной относительно некоторого значения операнда, если ее результат не зависит от этого значения операнда и определяется другими операндами.
Например, логическое сложение (or) инвариантно относительно значения «ложь» (false), логическое умножение (and) — относительно значения «истина» (true); алгебраическое сложение инвариантно относительно 0, а алгебраическое умножение —относительно 1.
Выполнение такого рода операций можно исключить из текста программы, если известен инвариантный для них операнд. Этот метод оптимизации имеет смысл в сочетании с методом свертки операций.
Оптимизация передачи параметров в процедуры и функции
Выше рассмотрен метод передачи параметров в процедуры и функции через стек. Этот метод применим к большинству языков программирования и используется практически во всех современных компиляторах для различных архитектур целевых вычислительных систем (на которых выполняется результирующая программа). Данный метод прост в реализации и имеет хорошую аппаратную поддержку во многих архитектурах. Однако он является неэффективным в том случае, если процедура или функция выполняет несложные вычисления над небольшим количеством параметров. Тогда всякий раз при вызове процедуры или функции компилятор будет создавать объектный код для размещения ее фактических параметров в стеке, а при выходе из нее — код для освобождения ячеек, занятых параметрами. При выполнении результирующей программы этот код будет задействован. Если процедура или функция выполняет небольшие по объему вычисления, код для размещения параметров в стеке и доступа к ним может составлять существенную часть относительно всего кода, созданного для этой процедуры
или функции. А если эта функция вызывается многократно, то этот код будет заметно снижать эффективность ее выполнения.
Существуют методы, позволяющие снизить затраты кода и времени выполнения на передачу параметров в процедуры и функции и повысить в результате эффективность результирующей программы:
передача параметров через регистры процессора;
подстановка кода функции в вызывающий объектный код.
Метод передачи параметров через регистры процессора позволяет разместить все или часть параметров, передаваемых в процедуру или функцию, непосредственно в регистрах процессора, а не в стеке. Это позволяет ускорить обработку параметров функции, поскольку работа с регистрами процессора всегда выполняется быстрее, чем с ячейками оперативной памяти, где располагается стек. Если все параметры удается разместить в регистрах, то сокращается также и объем кода, поскольку исключаются все операции со стеком при размещении в нем параметров.
Понятно, что регистры процессора, используемые для передачи параметров в процедуру или функцию, не могут быть задействованы напрямую для вычислений внутри этой процедуры или функции. Поскольку программно доступных регистров процессора всегда ограниченное количество, то при выполнении сложных вычислений могут возникнуть проблемы с их распределением. Тогда компилятор должен выбрать: либо использовать регистры для передачи параметров и снизить эффективность вычислений (часть промежуточных результатов, возможно, потребуется размещать в оперативной памяти или в том же стеке), либо использовать свободные регистры для вычислений и снизить эффективность передачи параметров. Поэтому реализация данного метода зависит от количества программно доступных регистров процессора в целевой вычислительной системе и от используемого в компиляторе алгоритма распределения регистров. В современных процессорах число программно доступных регистров постоянно увеличивается с разработкой все новых и новых их вариантов, поэтому и значение этого метода постоянно возрастает.
Этот метод имеет ряд недостатков. Во-первых, очевидно, он зависит от архитектуры целевой вычислительной системы. Во-вторых, процедуры и функции, оптимизированные таким методом, не могут быть использованы в качестве процедур или функций библиотек подпрограмм ни в каком виде. Это вызвано тем, что методы передачи параметров через регистры процессора не стандартизованы (в отличие от методов передачи параметров через стек) и зависят от реализации компилятора. Наконец, этот метод не может быть использован, если где бы то ни было в процедуре или функции требуется выполнить операции с адресами (указателями) на параметры.
В большинстве современных компиляторов метод передачи параметров в процедуры и функции выбирается самим компилятором автоматически в процессе генерации кода для каждой процедуры и функции. Однако разработчик имеет, как правило, возможность запретить передачу параметров через регистры процессора либо для определенных функций (для этого используются специальные ключевые слова входного языка), либо для всех функций в программе (для этого используются настройки компилятора).
Некоторые языки программирования (такие, например, как С и C++) позволяют разработчику исходной программы явно указать, какие параметры или локальные переменные процедуры он желал бы разместить в регистрах процессора. Тогда компилятор стремится распределить свободные регистры, в первую очередь, именно для этих параметров и переменных.
Метод подстановки кода функции в вызывающий объектный код (так называемая inline-подстановка) основан на том, что объектный код функции непосредственно включается в вызывающий объектный код всякий раз в месте вызова функции.
Для разработчика исходной программы такая функция (называемая inline-функцией) ничем не отличается от любой другой функции, но для вызова ее в результирующей программе используется принципиально другой механизм. По сути, вызов функции в результирующем объектном коде вовсе не выполняется — просто все вычисления, производимые функцией, выполняются непосредственно в самом вызывающем коде в месте ее вызова.
Очевидно, что в общем случае такой метод оптимизации ведет не только к увеличению скорости выполнения программы, но и к увеличению объема объектного кода. Скорость увеличивается за счет отказа от всех операций, связанных с вызовом функции, — это не только сама команда вызова, но и все действия, связанные с передачей параметров. Вычисления при этом идут непосредственно с фактическими параметрами функции. Объем кода растет, так как приходится всякий раз включать код функции в место ее вызова. Тем не менее, если функция очень проста и включает в себя лишь несколько машинных команд, то можно даже добиться сокращения кода результирующей программы, так как при включении кода самой функции в место ее вызова оттуда исключаются операции, связанные с передачей ей параметров.
Как правило, этот метод применим к очень простым функциям или процедурам, иначе объем результирующего кода может существенно возрасти. Кроме того, он применим только к функциям, вызываемым непосредственно по адресу, без применения косвенной адресации через таблицы RTTI (см. раздел «Семантический анализ и подготовка к генерации кода» главы 5). Некоторые компиляторы допускают его применение только к функциям, предполагающим последовательные вычисления и не содержащим циклов.
Ряд языков программирования (например, C++) позволяют разработчику явно указать, для каких функций он желает использовать inline-подстановку. В C++, например, для этой цели служит ключевое слово входного языка inline.
Оптимизация циклов
Циклом в программе называется любая последовательность участков программы, которая может выполняться повторно.
Циклы присущи подавляющему большинству программ. Во многих программах есть циклы, выполняемые многократно. Большинство языков программирования имеют синтаксические конструкции, специально ориентированные на организацию циклов. Очевидно, такие циклы легко обнаруживаются на этапе синтаксического разбора.
Однако понятие цикла с точки зрения объектной программы, определенной выше, является более общим. Оно включает в себя не только циклы, явно описанные в синтаксисе языка. Циклы могут быть организованы в исходной программе с помощью любых конструкций, допускающих передачу управления (прежде всего, с помощью условных операторов и операторов безусловного перехода). Для результирующей объектной программы не имеет значения, с помощью каких конструкций организован цикл в исходной программе.
Чтобы обнаружить все циклы в исходной программе, используются методы, основанные на построении графа управления программы [4, т. 2, 21].
Циклы обычно содержат в себе один или несколько линейных участков, где производятся вычисления. Поэтому методы оптимизации линейных участков позволяют повысить также и эффективность выполнения циклов, причем они оказываются тем более эффективными, чем больше кратность выполнения цикла. Но есть методы оптимизации программ, специально ориентированные на оптимизацию циклов.
Для оптимизации циклов используются следующие методы:
вынесение инвариантных вычислений из циклов;
замена операций с индуктивными переменными;
слияние и развертывание циклов..
Вынесение инвариантных вычислений из циклов заключается в вынесении за пределы циклов тех операций, операнды которых не изменяются в процессе выполнения цикла. Очевидно, что такие операции могут быть выполнены один раз до начала цикла, а полученные результаты потом могут использоваться в теле цикла. Например, цикл1 for 1：=1 to 10 do begin'
A[i] ：= В * С * А[1]:
end:
может быть заменен последовательностью операций
D := В * С;'
for 1:=1 to 10 do begin А[” ：= D * A[i]:
end:
если значения В и С не изменяются нигде в теле цикла. При этом операция умножения В * С будет выполнена только один раз, в то время как в первом варианте она выполнялась 10 раз над одними и теми же операндами.
Конечно, во внутреннем представлении компилятора циклы не могут быть записаны в таком виде, но для наглядности здесь мы их будем представлять в синтаксической записи входного языка (в данном случае — языка Pascal, как и во всех примерах далее). На суть выполняемых операций оптимизации это никак не влияет.
Неизменность операндов в теле цикла может оказаться не столь очевидной. Отсутствие присвоения значений переменным не может служить достоверным признаком их неизменности. В общем случае компилятору придется принимать во внимание все операции, которые так или иначе могут повлиять на инвариантность переменных. Такими операциями являются операции над указателями, вызовы функций (даже если сами переменные не передаются в функцию в качестве параметров, она может изменять их значения через «побочные эффекты»). Поскольку невозможно отследить все изменения указателей (адресов) и все «побочные эффекты» на этапе компиляции, компилятор вынужден отказаться от вынесения из цикла инвариантных переменных всякий раз, когда в теле цикла появляются «подозрительные» операции, которые могут поставить под сомнение инвариантность той или иной переменной.
Замена операций с индуктивными переменными заключается в изменении сложных операций с индуктивными переменными в теле цикла на более простые операции. Как правило, выполняется замена умножения на сложение.
Переменная называется индуктивной в цикле, если ее значения в процессе выполнения цикла образуют арифметическую прогрессию. Таких переменных в цикле может быть несколько, тогда в теле цикла их иногда можно заменить одной- единственной переменной, а реальные значения для каждой переменной будут вычисляться с помощью соответствующих коэффициентов соотношения (всем переменным должны быть за пределами цикла присвоены значения, если, конечно, они используются).
Простейшей индуктивной переменной является переменная-счетчик цикла с перечислением значений (цикл типа for, который встречается в синтаксисе многих современных языков программирования). Более сложные случаи присутствия индуктивных переменных в цикле требуют специального анализа тела цикла. Не всегда выявление таких переменных является тривиальной задачей.
После того как индуктивные переменные выявлены, необходимо проанализировать те операции в теле цикла, где они используются. Часть таких операций может быть упрощена. Как правило, речь идет о замене умножения на сложение [4, т. 2, 21, 52].
Например, цикл
S := 10;
for 1：=1 to N do А[1] ：= 1*S;
может быть заменен последовательностью операций
S := 10;
Т := S; 1 := 1; while 1 <= 10 do begin
А[1] ：= T； T := Т + 10; 1 ：= I + 1;
end；
Здесь использован синтаксис языка Pascal, а Т — это некоторая новая временная переменная (использовать для той же цели уже существующую переменную S не
вполне корректно, так как ее значение может быть использовано и после завершения этого цикла). В итоге удалось отказаться от выполнения N операций умножения, выполнив вместо них N операций сложения (которые обычно выполняются быстрее). Индуктивной переменной в первом варианте цикла являлась а во втором варианте — 1 и Т.
В другом примере
S := 10;
for i:=l to N do R := R + F(S): S := S + 10:
две индуктивных переменных — 1 и S. Если их заменить одной, то выяснится, что переменная 1 вовсе не имеет смысла, тогда этот цикл можно заменить на последовательность операций
S := 10: М := 10 + N*10:
while S <= М do begin R ：= R + F(S); S := S + 10: end;
Здесь удалось исключить N операций сложения для переменной i за счет добавления новой временной переменной М (как и в предыдущем примере, использован синтаксис языка Pascal).
В современных реальных компиляторах такие преобразования используются достаточно редко, поскольку они требуют достаточно сложного анализа программы, в то время как достигаемый выигрыш невелик — разница в скорости выполнения сложения и умножения, равно как и многих других операций, в современных вычислительных системах не столь существенна. Кроме того, существуют варианты циклов, для которых эффективность указанных методов преобразования является спорной [4, т. 2, 21].
Слияние и развертывание циклов предусматривает два различных варианта преобразований: слияния двух вложенных циклов в один и замена цикла на линейную последовательность операций.
Слияние двух циклов можно проиллюстрировать на примере циклов
for 1：=1 to N do
for j:=1 to M do A[i,j] := 0:
Здесь происходит инициализация двумерного массива. Но в объектном коде двумерный массив — это всего лишь область памяти размером N * М, поэтому (с точки зрения объектного кода, но не входного языка!) эту операцию можно представить так:
К := N*M;'
for 1:=1 to К do A[i] := 0:
Развертывание циклов можно выполнить для циклов, кратность выполнения которых известна уже на этапе компиляции. Тогда цикл кратностью N можно заменить линейной последовательностью из N операций, содержащих тело цикла. Например, цикл
for 1:=1 to 3 do A[i] ：= i:
можно заменить операциями
А[1] := 1:
А[2] := 2;
А[3] := 3:
Незначительный выигрыш в скорости достигается за счет исключения всех операций с индуктивной переменной, однако объем программы может существенно возрасти.
Машинно-зависимые методы оптимизации
Машинно-зависимые методы оптимизации ориентированы на конкретную архитектуру целевой вычислительной системы, на которой будет выполняться результирующая программа. Как правило, каждый компилятор ориентирован на одну определенную архитектуру целевой вычислительной системы. Иногда возможно в настройках компилятора явно указать одну из допустимых целевых архитектур. В любом случае результирующая программа всегда порождается для четко заданной целевой архитектуры.
Архитектура вычислительной системы есть представление аппаратной и программной составляющих частей системы и взаимосвязи между ними с точки зрения системы как единого целого. Понятие «архитектура» включает в себя особенности и аппаратных, и программных средств целевой вычислительной системы. При выполнении машинно-зависимой оптимизации компилятор может принимать во внимание те или иные ее составляющие. То, какие конкретно особенности архитектуры будут приняты во внимание, зависит от реализации компилятора и определяется его разработчиками.
Количество существующих архитектур вычислительных систем к настоящему времени очень велико. Поэтому не представляется возможным рассмотреть все ориентированные на них методы оптимизации даже в форме краткого обзора. Интересующиеся этим вопросом могут обратиться к специализированной литературе [4, т. 2, 31, 50, 52]. Далее будут рассмотрены только два основных аспекта машинно-зависимой оптимизации: распределение регистров процессора и порождение кода для параллельных вычислений.
Распределение регистров процессора
Процессоры, на базе которых строятся современные вычислительные системы, имеют, как правило, несколько программно-доступных регистров. Часть из них может быть предназначена для выполнения каких-либо определенных целей (например, регистр-указатель стека или регистр-счетчик команд), другие могут быть использованы практически произвольным образом при выполнении различных операций (так называемые «регистры общего назначения»).
Использование регистров общего назначения для хранения значений операндов и результатов вычислений позволяет добиться увеличения быстродействия программы, так как действия над регистрами процессора всегда выполняются быстрее, чем над ячейками памяти. Кроме того, в ряде процессоров не все операции
могут быть выполнены над ячейками памяти, а потому часто требуется предварительная загрузка операнда в регистр. Результат выполнения операции чаще всего тоже оказывается в регистре, и если необходимо, его надо выгрузить (записать) в ячейку памяти.
Программно доступных регистров процессора всегда ограниченное количество. Поэтому встает вопрос об их распределении при выполнении вычислений. Этим занимается алгоритм распределения регистров, который присутствует практически в каждом современном компиляторе в части генерации кода результирующей программы.
При распределении регистров под хранение промежуточных и окончательных результатов вычислений может возникнуть ситуация, когда значение той или иной переменной (связанной с нею ячейки памяти) необходимо загрузить в регистр для дальнейших вычислений, а все имеющиеся доступные регистры уже заняты. Тогда компилятору перед созданием кода по загрузке переменной в регистр необходимо сгенерировать код для выгрузки одного из значений из регистра в ячейку памяти (чтобы освободить регистр). Причем выгружаемое значение затем, возможно, придется снова загружать в регистр. Встает вопрос о выборе того регистра, значение которого нужно выгрузить в память.
При этом возникает необходимость выработки стратегии замещения регистров процессора. Она чем-то сродни стратегиям замещения процессов и страниц в памяти компьютера, которые используются в операционных системах. Однако разница состоит в том, что, в отличие от диспетчера памяти в ОС, компилятор может проанализировать код и выяснить, какое из выгружаемых значений ему понадобится для дальнейших вычислений и когда (следует помнить, что компилятор сам вычислений не производит — он только порождает код для них, иное дело — интерпретатор). Как правило, стратегии замещения регистров процессора предусматривают, что выгружается тот регистр, значение которого будет использовано в последующих операциях позже всех (хотя не всегда эта стратегия является оптимальной).
Кроме общего распределения регистров, могут использоваться алгоритмы распределения регистров специального характера. Например, во многих процессорах есть регистр-аккумулятор, который ориентирован на выполнение различных арифметических операций (операции с ним выполняются либо быстрее, либо имеют более короткую запись). Поэтому в него стремятся всякий раз загрузить чаще всего используемые операнды; он же используется, как правило, при передаче результатов функций и отдельных операторов. Могут быть также регистры, ориентированные на хранение счетчиков циклов, базовых указателей и т. п. Тогда компилятор должен стремиться распределить их именно для тех целей, на выполнение которых они ориентированы. '
Оптимизация кода для процессоров, допускающих распараллеливание вычислений
Многие современные процессоры допускают возможность параллельного выполнения нескольких операнд访.Как правило, речь идет об арифметических операциях.
Тогда компилятор может порождать объектный код таким образом, чтобы в нем содержалось максимально возможное количество соседних операций, все операнды которых не зависят друг от друга. Решение такой задачи в глобальном объеме для всей программы в целом не представляется возможным, но для конкретного оператора оно, как правило, заключается в порядке выполнения операций. В этом случае нахождение оптимального варианта сводится к выполнению перестановки операций (если она возможна, конечно). Причем оптимальный вариант зависит как от характера операции, так и от количества имеющихся в процессоре конвейеров для выполнения параллельных вычислений.
Например, операцию A + B + C+D + Е + Ена процессоре с одним потоком обработки данных лучше выполнять в порядке ((((A+B)+C) + D) + E)+F. Тогда потребуется меньше ячеек для хранения промежуточных результатов, а скорость выполнения от порядка операций в данном случае не зависит.
Та же операция на процессоре с двумя потоками обработки данных в целях увеличения скорости выполнения может быть обработана в порядке ((А + В) + С) + + ((D + Е) + F). Тогда, по крайней мере, операции A + BhD + E, а также сложение с их результатами могут быть обработаны в параллельном режиме. Конкретный порядок команд, а также распределение регистров для хранения промежуточных результатов будут зависеть от типа процессора.
На процессоре с тремя потоками обработки данных ту же операцию можно уже разбить на части в виде (А + В) + (С + D) + (Е + F). Теперь уже три операции А + В, С + D и Е + F могут быть выполнены параллельно. Правда, их результаты уже должны быть обработаны последовательно, но тут уже следует принять во внимание соседние операции для нахождения наиболее оптимального варианта.
Контрольные вопросы и задачи
Вопросы
Справедливы ли следующие утверждения:
Q любой язык программирования является контекстно-свободным языком;
Q синтаксис любого языка программирования может быть описан с помощью контекстно-свободной грамматики;
Q любой язык программирования является контекстно-зависимым языком;
Q семантика любого языка программирования может быть описана с помощью контекстно-свободной грамматики?
Какие задачи в компиляторе решает семантический анализ? Можно ли построить компилятор без семантического анализатора? Если да, то какие условия должны при этом выполняться?
Цепочка символов, принадлежащая любому языку программирования, может быть распознана с помощью распознавателя для контекстно-зависимых языков. При этом не будет требоваться дополнительный семантический анализ цепочки. Почему такой подход не применяется в компиляторах на практике?
На языке С описаны переменные:
int i,j,k； /* целочисленные переменные */ doiihlp x.v.z: /* вещественные переменные */
Объясните, есть ли различия в объектном коде, порождаемом компилятором для перечисленных ниже пар операторов, и если есть, то в чем они заключаются:
Q i = х / у Q i = х / у О 1 = j / к Q z = х / у О z = j / к О z = j / кQ i = х / у Q i = х / у О 1 = j / к Q z = х / у О z = j / к О z = j / кi = (int)(x / у)；
Q i = х / у Q i = х / у О 1 = j / к Q z = х / у О z = j / к О z = j / к
Q i = х / у Q i = х / у О 1 = j / к Q z = х / у О z = j / к О z = j / к
i = ((int)x) / ((int)y);
1 = ((double)j) / (double)k)： z=((int)x) / ((int)y)：
z = (doub1e)(j / к)；
z = ((double)j) / ( (double)k)；
Объясните, какие функции по преобразованию типов должен будет включить в объектный код компилятор в каждом из перечисленных случаев. В каких случаях выполняется неявное преобразование типов?
Функция ftest, описанная в исходной программе на языке C++ как void ftestdnt 1), помещается в библиотеку. В объектном коде библиотеки она получит имя, присвоенное компилятором. Это имя может иметь вид, подобный ftest@i@v. Если разработчик пользуется одним и тем же компилятором, то имя функции будет присваиваться одно и то же. Почему, тем не менее, не стоит вызывать функцию из библиотеки по этому имени? Что должен предпринять разработчик, чтобы функция в библиотеке имела имя ftest?
Почему распределение памяти не может быть выполнено до выполнения семантического анализа? Как работает процесс распределения памяти с таблицей идентификаторов?
Может ли компилятор для языков С и Pascal использовать статическую схему организации дисплея памяти процедуры (функции)? А динамическую схему?
Синтаксис языка Pascal предусматривает возможность вложения процедур и функций. Как это должно отразиться на организации дисплея памяти, если учесть, что, согласно семантике языка, вложенные процедуры и функции могут работать с локальными данными объемлющих процедур и функций? Требуются ли какие-либо изменения в стековой организации дисплея памяти в таком случае?
От чего зависит состав информации, хранящейся в таблице RTTI? Регламентируется ли состав информации в этой таблице синтаксисом или семантикой исходного языка программирования? Зависит ли информация в таблице RTTI от архитектуры целевой вычислительной системы?
Почему в большинстве компиляторов помимо генерации результирующего объектного кода выполняется еще и оптимизация его? Можно ли построить компилятор, исключив фазу оптимизации кода?
И. От чего зависит эффективность объектного кода, построенного компилятором? Влияют ли на эффективность результирующего кода синтаксис и семантика исходного языка программирования?
В чем заключается основной принцип СУ-перевода? Является ли СУ-перевод наиболее эффективным методом порождения результирующего кода?
Сравните между собой основные способы внутреннего представления программы. На каких этапах компиляции лучше всего использовать каждый из этих способов? Какие (или какой) из способов внутреннего представления программы обязательно должен уметь обрабатывать компилятор?
Почему имеются трудности с оптимизацией выражений, представленных в форме обратной польской записи?
От чего зависит код, порождаемый процедурой СУ-перевода для каждого узла дерева операций? Должна ли процедура СУ-перевода обращаться к таблице идентификаторов? Должна ли процедура СУ-перевода учитывать тип операндов? Как зависят действия этой процедуры от типа порождаемого ею внутреннего представления программы?
Какой из двух основных методов оптимизации, машинно-зависимый или машинно-независимый, может порождать более эффективный результирующий код? Как сочетаются эти два метода оптимизации в компиляторе?
Почему линейные участки легче поддаются оптимизации, чем все другие части внутреннего представления программы и объектного кода?
Почему можно утверждать, что исключение из исходного языка операций с указателями и адресами значительно усиливает возможности компилятора по оптимизации кода?
Массив А содержит 10 элементов (индексы от 0 до 9). Будет ли условный оператор языка Pascal if (i<10) and (A[1]=0) then ... правильным с точки зрения порождаемого компилятором объектного кода? Будет ли правильным с этой же точки зрения оператор If (1<=0) or (i>=10) or (А[1]=0) then ...? Что можно сказать об объектном коде, порождаемом компилятором для каждого из этих операторов, если компилятор не будет выполнять оптимизацию логических выражений?
Какое значение будет иметь переменная i после выполнения следующего оператора языка С:
if (++1>10 11 i++>20 && i ++<50 11 i++<0) 1：
если переменная i имеет перед его выполнением следующие значения:
О 9
О И
О 21
О 0
О -2?
Как изменится значение переменной при выполнении этого оператора, если предположить, что при порождении объектного кода компилятор не выполняет оптимизацию логических выражений?
Какие варианты распараллеливания выполнения операций может использовать компилятор при порождении объектного кода, необходимого для вычисления выражения A*B*C + A*D/E-B/E-F?
Задачи
Даны две грамматики (см. задачи к предыдущей главе):
Gl({a},{S.R.T.G.E }.Р1. S)
Р1:
S -> TR
R -> 九 I Т I TR
Т -> EG
G -> 九 I &Е I &EG
Е -> ~Е I ⑸ I а•
G2({(,a}.{S,T,E}.P2.S)
Р2:
S -> S*T I т
T -> T&E I E
E -> ~E I (S) I a.
Постройте для каждой из них цепочку вывода для цепочки символов: а人а&~а&(а人~~а), постройте деревья вывода для каждой из полученных цепочек символов. Преобразуйте полученные деревья вывода в дерево операций. Проделайте то же самое для других цепочек, допустимых в языке, заданном этими грамматиками.
Функции описаны на языке Pascal следующим образом:
procedure А(1 : integer； j： integer);
var t： float：
begin
end：
procedure B：
var a.b.c： Integer： begin
end:'
Функция А вызывает функцию В, которая затем рекурсивно вызывает функцию А. Отобразите содержимое стека: после выполнения одного такого вызова; двух таких вызовов. Объясните, как будет происходить возврат в вызывающую программу, если после двух вызовов рекурсия заканчивается.
На языке Pascal описаны следующие типы данных:
type
TestArray = array[l..4] of integer：
TestRecord = record
A : TestArray:
В : char；
C : integer；
end；
TestUnlon = record
J : byte:
case I : integer of
1： (A ： TestRecord)：
(B : TestArray);
(C : integer): end；
а также переменные: var cl,c2 : char： 11,12 : integer： al : TestArray;
rl,r2,r3 : TestRecord: ul : TestUnlon:
Какой размер памяти потребуется для этих переменных, если считать, что размер памяти, необходимой для типов данных char и byte, составляет 1 байт, а размер памяти для типа данных integer — 2 байта?
Как изменится размер необходимой памяти, если предположить, что архитектура целевой вычислительной системы предполагает выравнивание данных по границе 2 байта? 4 байта?
Вычислите следующие выражения, записанные в форме обратной польской записи:
О 12*354* + + 012354**++ 012+3*5+4- 012+3*54+-
Напишите для каждого из них выражение в форме инфиксной (обычной) записи.
Дана грамматика G({(,)「,&,~,a},{S.T,E},P,S):
Р：.
S -> ST I т
Т -> Т&Е I Е
Е -> ~Е I ⑸ I а
Постройте схему СУ-компиляции выражений входных цепочек языка, заданного этой грамматикой, во внутреннее представление в форме обратной польской записи.
Для грамматики, приведенной выше в задаче № 4, постройте схему СУ-перевода во внутреннее представление программы в форме триад. Выполните перевод в форму триад цепочки символов аАа&~а&(аА~~а).
Для грамматики, приведенной выше в задаче № 4, постройте схему СУ-перевода во внутреннее представление программы в форме команд ассемблера (например, Intel 80x86). Выполните перевод в ассемблерный код цепочки символов а*а&~а&(а*~~а).
Дана последовательность операций:
А := 2;
В := А * 3;
С := 4 * 3 + 1:
А := D：
D := В + С;
С := А:
В := А + 4 * С + 3 * (D + 12):
Преобразуйте ее в форму записи на основе триад.
Выполните свертку операций.
Дана последовательность операций:
А := В * С + D * Е; B:=B*C + D*E: С:=В*С+D * Е;
D:=В*С-(D * Е+2);
Е:=В*С-(D * Е+3);
А:=А*Е+В*Е+1; В:=А*Е+В*Е+1;
Преобразуйте ее в форму записи на основе триад.
Выполните исключение лишних операций.
Постройте алгоритм распределения регистров для хранения промежуточных результатов на основе внутреннего представления программы в форме триад.
Постройте алгоритм перевода внутреннего представления программы в форме триад в последовательность команд ассемблера.
Глава 6 Современные системы программирования
Понятие и структура системы программирования
Понятие о системе программирования
Любой компилятор не существует сам по себе, а решает свои задачи в рамках всего системного программного обеспечения. Основная цель компиляторов — обеспечивать разработку новых прикладных и системных программ с помощью языков высокого уровня. /_
Всякая программа, как системная, так и прикладная, проходит этапы жизненного цикла, начиная от проектирования и вплоть до внедрения и сопровождения [10, 18, 33]. При этом компиляторы — это средства, служащие для создания программного обеспечения на этапах кодирования, тестирования и отладки.
Однако сам по себе компилятор не решает полностью всех задач, связанных с разработкой новой программы. И хотя компилятор является главной составляющей средств разработки, одного только лишь компилятора недостаточно для того, чтобы обеспечить прохождение программой всех указанных этапов жизненного цикла. Поэтому компиляторы — это программное обеспечение, которое функционирует в тесном взаимодействии с другими техническими средствами, применяемыми для разработки программного обеспечения.
Основные технические средства, используемые в комплексе с компиляторами, включают в себя следующие программные модули:
текстовые редакторы, служащие для создания текстов исходных программ;
компоновщики, позволяющие объединять несколько объектных модулей, порождаемых компилятором, в единое целое;
библиотеки прикладных программ, содержащие в себе наиболее часто используемые функции и подпрограммы в виде готовых объектных модулей;
загрузчики, обеспечивающие подготовку готовой программы к выполнению;
отладчики, выполняющие программу в заданном режиме с целью поиска, обнаружения и локализации ошибок;
другие программные средства, служащие для разработки программ и их компонентов (о некоторых из этих средств будет рассказано далее).
« Все эти средства разработки функционируют не отдельно, каждое само по себе, а в тесном взаимодействии друг с другом. Данные, полученные одним модулем, поступают на вход другого и наоборот. В современных средствах разработки интеграция модулей столь высока, что пользователь часто даже и не представляет, что он работает с несколькими программными средствами — для него вся система разработки представляет собой единое целое.
Весь этот комплекс программно-технических средств составляет новое понятие, которое здесь названо «системой программирования».
Возникновение систем программирования
Первоначально компиляторы разрабатывались и поставлялись вне связи с другими техническими средствами, с которыми им приходилось взаимодействовать. Единственным средством разработки, которое поставлялось вместе с компилятором, были библиотеки стандартных функций языка программирования, потому что без их наличия разработка программ была просто невозможна. В задачу разработчика входило обеспечить взаимосвязь всех используемых технических средств:
подготовить тексты исходной программы на входном языке компилятора;
подать данные в виде текста исходной программы на вход компилятора;
получить от компилятора результаты его работы в виде набора объектных файлов;
подать весь набор полученных объектных файлов вместе с необходимыми библиотеками подпрограмм на вход компоновщику;
получить от компоновщика единый файл программы (исполняемый файл) и подготовить его к выполнению с помощью загрузчика;
поставить программу на выполнение, при необходимости использовать отладчик для проверки правильности выполнения программы.
Все эти действия выполнялись с помощью последовательности команд, инициировавших запуск соответствующих программных модулей с передачей им всех необходимых параметров. Параметры передавались каждому модулю в команд' ной строке и представляли собой набор имен файлов и настроек, реализованных в виде специальных «ключей». Пользователи могли выполнять эти команды последовательно вручную, а с развитием средств командных процессоров ОС они стали объединять их в командные файлы.
Со временем разработчики компиляторов постарались облегчить труд пользователей, предоставив им все необходимое множество программных модулей в соста-
ве одной поставки компилятора. Теперь компиляторы поставлялись уже вкупе со всеми необходимыми сопровождающими техническими средствами. Кроме того, были унифицированы форматы объектных файлов и файлов библиотек подпрограмм. Теперь разработчики, имея компилятор от одного производителя, могли в принципе пользоваться библиотеками и объектными файлами, полученными от другого производителя компиляторов или от другой команды разработчиков. Поскольку процессу компиляции всегда соответствует типичная последовательность команд, то разрабатывать для этой цели командный файл в ОС неэффективно и неудобно. Для написания командных файлов компиляции пользователям компиляторов был предложен специальный командный язык, который обрабатывался интерпретатором команд компиляции — программой make1. Вся последовательность действий, необходимых для порождения исполняемого файла, представляла собой специального вида интерпретируемую программу на этом языке — Makefile [20, 29, 46, 48, 55]. В этой программе перечислялись все используемые входные модули, библиотеки подпрограмм, все порождаемые объектные файлы, «ключи» и правила обработки для каждого типа файлов. Программа Makefile позволяла в достаточно гибкой и удобной форме описать весь процесс создания программы от порождения исходных текстов до подготовки ее к выполнению. Появление Makefile можно назвать первым шагом по созданию систем программирования. Язык Makefile стал стандартным средством, единым для компиляторов всех разработчиков. Это было удобное, но достаточно сложное техническое средство, требующее от разработчика высокой степени подготовки и профессиональных знаний, поскольку сам командный язык Makefile был по сложности сравним с простым языком программирования. Для того чтобы понять, насколько непросто работать с такими системами программирования, в качестве наглядного примера приводится немного сокращенный текст Makefile, построенный автоматизированным способом с помощью современных средств разработки.
# Microsoft Developer Studio Generated NMAKE File CFG=CiMain - Win32 Debug
!IF "$(0S)" == "WindowsNT"
NULL=-
'ELSE
NULL=nul
!ENDIF
CPP=cl.exe'
RSC=rc.exe
OUTDIR=,\Debug INTDIR=.\Debug # Begin Custom Macros OutD1r=.\Debug # End Custom Macros ALL : "$(OUTOIR)\CiMain.exe" CLEAN :
-©erase "$(INTDIR)\C1Ma1n.obj"
-©erase "$(INTDIR)\vc60.idb"
От англ, «make» — строить, создавать.
-©erase "$(INTDIR)\vc60.pdb"
-©erase "$(0UTDIR)\C1Main.exe"
-©erase "$(0UTDIR)\C1Main.1lk"
-©erase "$(0UTDIR)\C1Main.pdb"
"$(OUTDIR)"：
if not exist "$(OUTDIR)/$(NULD" mkdir "$(OUTDIR)"
CPP_PROJ=/nologo /MLd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Fp"$(INTDIR)\C1Ma1n.pch" /YX /Fo"$(INTDIR)\\" /Fd~$(INTDIR)\\~/FD /GZ /с BSC32=bscmake.exe
BSC32_FLAGS=/nologo /o"$(0UTDIR)\C1Main.bsc"
BSC32_SBRS= \.
LINK32=link.exe
LINK32_FLAGS=kernel32.11b user32.1ib gdi32.1ib winspool.lib comdlg32.1ib advapi32.11b shell32.lib ole32.11b oleaut32.1ib uujd.lib odbc32.11b odbccp32.11b /nologo /subsystem：console /Incremental：yes /pdb:"$(0UTDIR)\C1Ma1n.pdb" /debug /machine：1386 /out:"$(0UTDIR)\C1Ma1n.exe" /pdbtype：sept LINK32_0BJS= \
"$(INTDIR)\C1Main.obj"
"$(0UTDIR)\C1Main.exe" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_0BJS)
$(LINK32) @<< $(LINK32_FLAGS) $(LINK32二OBJS) «-
,c{$(INTDIR)}.obj::
$(CPP).@« $(CPP_PROJ) $< <<
,cpp{$(INTDIR)}.obj::
$(CPP) @<< $(CPP_PROJ) $< «
!IF "$(NO_EXTERNAL_DEPS)" != "1"
!IF EXISTSCCiMalnTdep")
'INCLUDE "CiMaln.dep"
!ELSE
•MESSAGE Warning： cannot find "CiMain.dep"
!ENDIF
!ENDIF'
S0URCE=.\C1Ma1n.cpp
"$(INTDIR)\C1Ma1n.obj" ： $(SOURCE) "$(INTDIR)"
Такая структура средств разработки существовала достаточно долгое время, а в некоторых случаях она используется и по сей день (особенно системными программистами в ОС типа UNIX и Linux).
Появление интегрированных сред разработки
Командная строка — эффективное, но не всегда удобное средство управления компиляцией (хотя среди программистов под ОС типа UNIX обязательно найдутся желающие поспорить с этим). Фактически, для каждого сложного проекта разработчикам приходилось писать еще одну дополнительную программу, описывающую на языке Makefile, как следует строить (собирать, компилировать) этот проект. А программирование всегда есть потенциальный источник ошибок. Поэтому развитие систем программирования на этом не завершилось.
Следующим шагом в развитии систем программирования стало появление так называемой «интегрированной среды разработки». Интегрированная среда объединила в себе возможности текстовых редакторов и командный язык компиляции. Пользователь (разработчик исходной программы) теперь не должен был отвечать за передачу данных с выхода одного средства разработки на вход другого, от него также не требовалось описывать этот процесс с помощью языка Makefile. Теперь ему было достаточно только указать в удобной интерфейсной форме состав необходимых для создания программы исходных модулей и библиотек. Команды, библиотеки и «ключи», необходимые компилятору и другим средствам разработки, также задавались в виде интерфейсных форм настройки.
После этого интегрированная среда разработки сама автоматически готовила всю необходимую последовательность команд Makefile, выполняла их, получала результат и сообщала о возникших ошибках при их наличии.
Но главным преимуществом интегрированной среды разработки было то, что все действия пользователь мог выполнять непосредственно в окне редактирования исходного текста программы. Он мог исправлять текст исходных модулей, получать информацию об ошибках непосредственно в исходном тексте программы, не прерывая работу с интегрированной средой. Кроме удобства работы, объединение текстовых редакторов, компиляторов и компоновщиков в единую среду дало системам программирования целый ряд достоинств, о которых будет сказано далее.
Создание интегрированных сред разработки можно назвать вторым шагом в развитии систем программирования. Оно стало возможным благодаря бурному развитию персональных компьютеров и появлению развитых средств интерфейса пользователя (сначала текстовых, а потом и графических). Пожалуй, первой удачной средой такого рода можно признать интегрированную среду программирования Turbo Pascal на основе языка Pascal производства фирмы Borland [39, 47, 49, 59]. Ее популярность на рынке определила тот факт, что со временем все разработчики компиляторов обратились к созданию интегрированных средств разработки для своих продуктов.
Развитие интегрированных сред снизило требования к профессиональным навыкам разработчиков исходных программ. Теперь в простейшем случае от разработчика требовалось только знание исходного языка. Разработчик программы, работающий в интегрированной среде, мог даже не иметь представления о структуре системы программирования, которой он пользуется1.
Дальнейшее развитие средств разработки также тесно связано с повсеместным распространением развитых средств графического интерфейса пользователя (GUI — Graphical User Interface). Такой интерфейс стал неотъемлемой составной частью многих современных ОС и так называемых графических оболочек [24, 47]. Со временем он стал стандартом «де-факто» во всех современных прикладных программах.
Конечно, это не плюс такому разработчику, но раньше такая ситуация была принципиально невозможной.
Это не могло не сказаться на требованиях, предъявляемых к средствам разработки программного обеспечения. В их состав были сначала включены соответствующие библиотеки, обеспечивающие поддержку GUI и взаимодействие с функциями API (Application Program Interface, прикладной программный интерфейс) операционных систем. А затем для работы с ними потребовались дополнительные средства, обеспечивающие разработку внешнего вида интерфейсных модулей. Такая работа была уже более характерна для дизайнера, чем для программиста.
Для описания графических элементов программ потребовались соответствующие языки. На их основе сложилось понятие «ресурсов» (resources) прикладных программ.
Ресурсами пользовательского интерфейса будем называть множество данных, обеспечивающих внешний вид интерфейса пользователя результирующей программы и не связанных напрямую с логикой ее выполнения. Характерными примерами ресурсов являются: тексты сообщений, выдаваемых программой; цветовая гамма элементов интерфейса; надписи на элементах управления и т. п.
ПРИМЕЧАНИЕ
Термин «ресурсы» следует признать не очень удачным, так как этим словом обозначаются очень многие понятия, связанные с вычислительными системами (например, ресурсы вычислительного процесса). Однако он уже сложился и применяется при работе со средствами разработки, поэтому придется принять его.
Для формирования структуры ресурсов, в свою очередь, потребовались редакторы ресурсов, а затем и компиляторы ресурсов, обрабатывающие результат их работы1. Ресурсы, полученные с выхода компиляторов ресурсов, стали обрабатываться компоновщиками и загрузчиками.
Структура современной системы программирования
Системой программирования будем называть весь комплекс программных средств, предназначенных для кодирования, тестирования и отладки программного обеспечения. Нередко системы программирования взаимосвязаны и с другими техническими средствами, служащими целям создания программного обеспечения на более ранних этапах жизненного цикла (от формулировки требований и анализа до проектирования). Однако рассмотрение таких систем выходит за рамки данного учебника.
Системы программирования в современном мире доминируют на рынке средств разработки. Как правило, разработчики компиляторов поставляют свои продукты в составе соответствующей системы программирования. Отдельные компиляторы являются редкостью и, как правило, служат узкоспециализированным целям.
Наверное, с точки зрения терминологии компиляторы ресурсов правильнее было бы назвать «трансляторы», так как в результате своей работы они обычно порождают не объектный файл, а некий промежуточный код ресурсов. Однако термин «компилятор ресурсов» стал уже общепринятым.
На рис. 6.1 приведена общая структура современной системы программирования. На ней выделены основные составляющие системы программирования и их взаимосвязь. Отдельные составляющие разбиты по группам в соответствии с этапами развития средств разработки.
Выполнение
Рис. 6.1. Общая структура и этапы развития систем программирования
Из рис. 6.1 видно, что современная система программирования — это достаточно сложный комплекс различных программно-технических средств. Все они служат цели создания прикладного и системного программного обеспечения.
Текстовый редактор позволяет готовить и вносить изменения в тексты исходных программ, но в современных системах программирования его функции не ограничиваются только этим — с ним связаны практически все сервисные возможности.
Редактор ресурсов дает возможность разработчику готовить ресурсы пользовательского интерфейса для результирующей программы. Как правило, подготовка ресурсов выполняется в графическом виде (в форме графических образов), а результатом является описание ресурсов интерфейса на языке описания ресурсов, которое, в свою очередь, может быть обработано с помощью обычного текстового редактора.
Компиляторы являются главной составляющей системы программирования. В состав системы программирования могут входить несколько компиляторов. Основным, конечно, является компилятор с исходного языка, на работу с которым ориентирована данная система. Также необходимым является компилятор ресурсов, обеспечивающий обработку описания ресурсов. Остальные компиляторы включаются в состав системы программирования по мере необходимости (например, в состав многих систем программирования входит компилятор с языка ассемблера). Библиотеки подпрограмм обеспечивают работоспособность системы программирования и ее конкурентоспособность на рынке средств разработки. Для разработки необходимы, как минимум, две библиотеки подпрограмм и функций: библиотека функций исходного языка и библиотека функций целевой ОС, на которой будет
выполняться результирующая программа. Но, как правило, система программирования предлагает пользователю обширный перечень дополнительных библиотек и функций, и чем шире этот перечень, тем богаче возможности системы программирования.
Компоновщик обеспечивает объединение всех исходных модулей в единый файл. Функции этого средства разработки практически не изменились за всю историю развития систем программирования.
Загрузчик обеспечивает подготовку результирующей программы к выполнению. В современных ОС он не входит в состав систем программирования, а является частью самой ОС.
Отладчик способствует поиску и локализации ошибок в программе. Обычно речь идет о семантических ошибках, так как подавляющее большинство синтаксических ошибок обнаруживаются компилятором.
Далее будут более подробно описаны функции основных перечисленных составляющих современных систем программирования.
Тенденция такова, что развитие систем программирования сейчас идет в направлении неуклонного повышения их дружественности и сервисных возможностей. Это связано с тем, что на рынке в первую очередь лидируют те системы программирования, которые позволяют существенно снизить трудозатраты, необходимые для создания программного обеспечения на этапах жизненного цикла, связанных с кодированием, тестированием и отладкой программ. Показатель снижения трудозатрат в настоящее время считается более существенным, чем показатели, определяющие эффективность результирующей программы, построенной с помощью системы программирования.
В качестве основных тенденций в развитии современных систем программирования следует указать внедрение в них средств разработки на основе так называемых «языков четвертого поколения» — 4GL (Fourth Generation Languages),— а также поддержка систем «быстрой разработки программного обеспечения» — RAD (Rapid Application Development).
Языки четвертого поколения — 4GL — представляют собой широкий набор средств, ориентированных на проектирование и разработку программного обеспечения. Они строятся на основе оперирования не синтаксическими структурами языка и описаниями элементов интерфейса, а представляющими их графическими образами. На таком уровне проектировать и разрабатывать прикладное программное обеспечение может пользователь, не являющийся квалифицированным программистом, зато имеющий представление о предметной области, на работу в которой ориентирована прикладная программа. Языки четвертого поколения являются следующим (четвертым по счету) этапом в развитии систем программирования.
Описание программы, построенное на основе языков 4GL, транслируется затем в исходный текст и файл описания ресурсов интерфейса, представляющие собой обычный текст на соответствующем входном языке высокого уровня. С этим текстом уже может работать профессиональный программист-разработчик — он может корректировать и дополнять его необходимыми функциями. Дальнейший
ход создания программного обеспечения идет уже традиционным путем, как это показано на рис. 6.1.
Такой подход позволяет разделить работу проектировщика, ответственного за общую концепцию всего проекта создаваемой системы, дизайнера, отвечающего за внешний вид интерфейса пользователя, и профессионального программиста, отвечающего непосредственно за создание исходного кода программного обеспечения.
В целом языки четвертого поколения решают уже более широкий класс задач, чем традиционные системы программирования. Они составляют часть средств автоматизированного проектирования и разработки программного обеспечения, поддерживающих все этапы жизненного цикла — CASE-систем (Computer Aided Software Engineering). Их рассмотрение выходит за рамки данного учебника.
Более подробную информацию о языках 4GL, технологии RAD и CASE-системах в целом можно получить в [И, 37, 56].
Принципы функционирования систем программирования
Функции текстовых редакторов в системах программирования
Текстовый редактор в интегрированной среде разработки
В принципе, текстовые редакторы появились вне какой-либо связи со средствами разработки. Они решали задачи создания, редактирования, обработки и хранения на внешнем носителе любых текстов, которые не обязательно должны были быть исходными текстами программ на языках высокого уровня. Эти функции многие текстовые редакторы выполняют и по сей день.
Появление интегрированных сред разработки на определенном этапе развития средств разработки программного обеспечения позволило непосредственно включить текстовые редакторы в состав этих средств. Первоначально такой подход привел к тому, что пользователь (разработчик исходной программы) работал исключительно в среде текстового редактора, не отрываясь от него для выполнения компиляции, компоновки, загрузки и запуска программы на выполнение. Для этого потребовалось создать средства, позволяющие отображать ход всего процесса разработки программы в среде текстового редактора, — такие, например, как метод отображения ошибок в исходной программе, обнаруженных на этапе компиляции, с позиционированием на место в тексте исходной программы, содержащее ошибку.
Можно сказать, что с появлением интегрированных сред разработки ушло в прошлое то время, когда разработчики исходных текстов вынуждены были первоначально готовить тексты программ на бумаге с последующим вводом их в компьютер. Процессы написания текстов и собственно создание программного обеспечения стали единым целым.
Интегрированные среды разработки оказались очень удобным средством. Они стали завоевывать рынок средств разработки программного обеспечения. А с их развитием расширялись и возможности, предоставляемые разработчику в среде текстового редактора. Со временем появились средства пошаговой отладки программ непосредственно по их исходному тексту, объединившие в себе возможности отладчика и редактора исходного текста. Другим примером может служить очень удобное средство, позволяющее графически выделить в исходном тексте программы все лексемы исходного языка по их типам — оно сочетает в себе возможности редактора исходных текстов и лексического анализатора компилятора. В итоге в современных системах программирования текстовый редактор стал важной составной частью, которая не только позволяет пользователю подготавливать исходные тексты программ, но и выполняет все интерфейсные и сервисные функции, предоставляемые пользователю системой программирования. И хотя современные разработчики по-прежнему могут использовать любые средства для подготовки исходных текстов программ, как правило, они предпочитают пользоваться тем текстовым редактором, который включен в состав системы программирования.
Лексический анализ «на лету»
Лексический анализ «на лету» — это функция текстового редактора в составе системы программирования. Она заключается в поиске и выделении лексем входного языка в тексте программы непосредственно в процессе ее создания разработчиком.
Реализуется это следующим образом: в то время, когда разработчик готовит исходный текст программы (набирает его вручную или получает из некоторого другого источника), система программирования параллельно выполняет поиск лексем в этом тексте. Поскольку скорость подготовки исходного текста даже самым квалифицированным пользователем намного уступает скорости его обработки лексическим анализатором на современном компьютере, для пользователя процесс поиска лексем происходит незаметно и не создает задержек — создается полная иллюзия параллельной работы1.
В простейшем случае обнаруженные лексемы просто выделяются в тексте с помощью графических средств интерфейса текстового редактора — цветом, шрифтом и т. п. Это облегчает труд разработчика программы, делает исходный текст более наглядным и способствует обнаружению ошибок на самом раннем этапе — на этапе подготовки исходного кода.
В более развитых системах программирования найденные лексемы не просто выделяются по ходу подготовки исходного текста, но и помещаются в таблицу идентификаторов компилятора, входящего в состав системы программирования. Такой подход позволяет экономить время на этапе компиляции, поскольку первая ее фаза — лексический анализ — уже выполнена на этапе подготовки исход-
Конечно, о реальной параллельной работе текстового редактора и лексического анализатора может идти речь, только если они работают в многопроцессорной вычислительной системе.
ного текста программы. Но преимущество такого подхода в основном заключается не в этом, а в том, что таблица идентификаторов, созданная на этапе создания исходного кода, может помочь разработчику в дальнейшей подготовке исходного кода. Эта возможность используется в системах подсказок и гиперссылок, о которых говорится в следующем подразделе.
Системы гиперссылок подсказок и справок
Следующей сервисной возможностью, предоставляемой разработчику системой программирования за счет лексического анализа «на лету», является возможность обращения разработчика к таблице идентификаторов в ходе подготовки исходного текста программы. Разработчик может дать компилятору команду найти нужную ему лексему в таблице. Поиск может выполняться по типу или по какой-то части информации лексемы (например, по нескольким первым буквам). Причем поиск может быть контекстно-зависимым — система программирования предоставит разработчику возможность найти лексему именно того типа, который может быть использован в данном месте исходного текста. Кроме самой лексемы разработчику может быть предоставлена некоторая информация о ней — например, типы и состав формальных параметров для функции, перечень доступных методов для типа или экземпляра класса. Это опять же облегчает труд разработчика, поскольку избавляет его от необходимости помнить состав функций и типов многих модулей или обращаться лишний раз к документации и справочной информации.
Обращение к таблице идентификаторов для разработчика реализуется в виде двух сервисных функций: подсказок и гиперссылок.
Подсказка возникает в том случае, когда разработчик подготовил какую-то часть исходного кода и сделал паузу перед подготовкой следующей части исходного кода. В этот момент система программирования имеет возможность подсказать ему в текстовом редакторе, какой код может следовать далее. Подсказка может иметь вид пояснения или варианта кода:
пояснение дает разработчику представление о том, какой код должен следовать далее, но не предлагает этот код (разработчик должен набрать код самостоятельно) —например, после ввода наименования функции появляется подсказка, содержащая перечень и типы параметров функции;
вариант кода предлагает разработчику часть исходного текста или шаблон исходного текста, который может следовать за уже подготовленным фрагментом (разработчик может выбрать один из вариантов заранее подготовленного кода) — например, после ввода переменной, соответствующей некоторому классу, подсказка предлагает перечень методов и свойств этого класса, из которых можно выбрать один нужный.
Конечно, подсказки — это лишь сервисные возможности, облегчающие труд программиста, но не подменяющие его. Кроме того, поскольку система программирования в данном случае судит об исходном коде на основании результатов предварительного лексического анализа, она может ошибаться. Поэтому разработчик всегда может ввести исходный код, отличный от предложенного подсказкой, или вообще отказаться от системы подсказок.
Гиперссылка позволяет сразу же перейти от одной взаимосвязанной части уже готового исходного кода к другой. Например, по имени функции получить ее описание, по имени переменной — тип этой переменной, а по имени сложного типа данных — его описание.
Другой удобной сервисной функцией в современных системах программирования является система справок. Как правило, она содержит три основные части:
справку по семантике и синтаксису используемого входного языка;
руководство по работе с самой системой программирования;
справку о функциях библиотек, входящих в состав системы программирования. Система справок (Help) в настоящее время является составной частью многих прикладных и системных программ. Как правило, она поддерживается соответствующими утилитами ОС. Поэтому нет ничего удивительного в том, что на рынке нет систем программирования, которые не были бы снабжены справками. Главной особенностью справок в системе программирования является тот факт, что как и подсказки, они должны быть контекстно-зависимыми.
Более того, разработчик, создающий программу с помощью системы программирования, конечно, тоже будет желать, чтобы его результирующая программа была оснащена справкой. Для этого системы программирования включают в свой состав сервисные функции, позволяющие создавать и дополнять систему подсказок и справок. Это делается таким образом, чтобы разработчик мог создавать и распространять вместе со своими прикладными программами соответствующие им подсказки и справки.
Компилятор как составная часть системы программирования
Компиляторы являются, безусловно, базовыми модулями в составе любой системы программирования. И основным, конечно же, будет компилятор с исходного языка. Поэтому не случайно то, что они стали главным предметом рассмотрения в данном учебнике. Без компилятора никакая система программирования не имеет смысла, а все остальные ее составляющие на самом деле служат лишь целям обеспечения работы компилятора и выполнения им своих функций.
От первых этапов развития систем программирования вплоть до появления интегрированных сред разработки пользователи (разработчики исходных программ) всегда, так или иначе, имели дело с компилятором. Они непосредственно взаимодействовали с ним как с отдельным программным модулем.
Сейчас, работая с системой программирования, пользователь, как правило, имеет дело только с ее интерфейсной частью, которую обычно представляет текстовый редактор с расширенными функциями. Запуск модуля компилятора и вся его работа происходят автоматически и скрыты от пользователя — разработчик видит только конечные результаты выполнения компилятора. Хотя многие современные системы программирования сохранили прежнюю возможность непосредственного взаимодействия разработчика с компилятором, но пользуются этими
средствами только узкий круг профессионалов. Большинство пользователей редко непосредственно сталкиваются с компиляторами.
На самом деле, кроме основного компилятора, выполняющего перевод исходного текста на входном языке в язык машинных команд, большинство систем программирования могут содержать в своем составе целый ряд других компиляторов и трансляторов. Так, большинство систем программирования содержат в своем составе и компилятор с языка ассемблера, и компилятор (транслятор) с входного языка описания ресурсов.
Тем не менее, работая с любой системой программирования, следует помнить, что основным модулем ее всегда является компилятор. Именно технические характеристики компилятора прежде всего влияют на эффективность результирующих программ, порождаемых системой программирования.
Компоновщик. Назначение и функции компоновщика
Компоновщик (или редактор связей) предназначен для связывания между собой объектных файлов, порождаемых компилятором, а также файлов библиотек, входящих в состав системы программирования. Название «компоновщик» происходит от англ, «link» (связывать, сцеплять). Во многих системах программирования файл компоновщика носит имя «linker», а разработчики на жаргонном языке нередко называют его «линковщик», или «линкер».
ВНИМАНИЕ
Автору встречались в технической литературе примеры, когда компоновщик называли загрузчиком. С точки зрения автора, это принципиально неправильно. Функции компоновщика и загрузчика существенно различаются. В современных системах программирования загрузчик, как правило, отсутствует — его функции выполняет ОС.
Объектный файл (или набор объектных файлов) не может быть исполнен до тех пор, пока все модули и секции не будут в нем увязаны между собой. Это и делает редактор связей (компоновщик). Результатом его работы является единый файл (часто называемый «исполняемым файлом»), который содержит весь текст результирующей программы на языке машинных кодов.
Задача компоновщика проста — он должен пройти весь код результирующей программы, начиная от места вызова ее главной исполняемой функции (точки входа) и до конца (точки выхода), найти все вызовы внешних процедур и функций, обращения к внешним переменным и увязать их с кодом других модулей, где описаны эти процедуры, функции и переменные. Причем в этих модулях, в свою очередь, могут быть обращения к другим внешним функциям — и т. д. Функции, описанные в разных модулях исходной программы, могут вызывать друг друга сколь угодно раз — компоновщик должен найти соответствие каждому из этих вызовов и определить («разрешить») соответствующую ссылку (адрес). Отсюда и происходит другое название компоновщика — «редактор связей».
Ссылки (вызовы процедур или функций, обращения к переменным), которым компоновщик не смог найти соответствие, называются «неразрешенными»1. В готовой к выполнению результирующей программе не должно быть неразрешенных ссылок. Компоновщик порождает сообщение об ошибке, если при попытке собрать объектные файлы в единое целое он не смог обнаружить какой-либо необходимой составляющей.
Компоновщик начинает свою работу с того, что выбирает из первого объектного модуля программную секцию и присваивает ей начальный адрес. Программные секции остальных объектных модулей получают адреса относительно начального адреса в порядке следования. При этом может выполняться также функция выравнивания начальных адресов программных секций. Одновременно с объединением текстов программных секций объединяются секции данных, таблицы идентификаторов и внешних имен. Разрешаются межсекционные ссылки.
Процедура разрешения ссылок сводится к вычислению значений адресных констант процедур, функций и переменных с учетом перемещений секций относительно начала собираемого программного модуля. Если при этом обнаруживаются ссылки на внешние переменные, отсутствующие в списке объектных модулей, редактор связей организует их поиск в библиотеках, доступных в системе программирования. Если же и в библиотеке необходимую составляющую найти не удается, формируется сообщение об ошибке. То же самое может произойти, если описание некоторой переменной, процедуры или функции будет обнаружено более чем в одном объектном файле среди обрабатываемых компоновщиком. Тогда компоновщик не сможет определить, к какому из них относится ссылка2.
В современных системах программирования компоновщик включает в состав исполняемого файла не только код объектных модулей, который подготовил компилятор исходной программы, но и описание ресурсов пользовательского интерфейса, которое готовит компилятор ресурсов. 一
Как и компилятор при распределении памяти, компоновщик работает с относительными адресами переменных, процедур и функций — условными единицами, отсчитываемыми от начала программы. Так же как и компилятор, он не может знать адресов памяти, в которых будет выполняться результирующая программа. Компоновщик работает с теми именами процедур и функций, которые им присвоил компилятор в таблице идентификаторов. Эти имена, как уже было сказано ранее, могут отличаться от имен, данных пользователем. Поэтому если два или более обращений к одной и той же функции или переменной в исходном тексте программы выполнены по-разному, компилятор может дать им разные имена и ссылка останется неразрешенной, что приведет к сообщению об ошибке от компоновщика (см. раздел, посвященный идентификации имен переменных и функций в данном учебном пособии). Так исходный код программы может влиять на
Происходит от слова «решать», а не «разрешать».
В некоторых системах программирования такие ссылки разрешаются по порядку следования файлов — ссылка относится к тому объектному файлу или библиотеке, который идет первым по порядку среди всех возможных. Однако такие ссылки — потенциальный источник трудно обнаруживаемых ошибок.
работу компоновщика и порождать ошибки, обнаруживаемые системой программирования только на этапе компоновки результирующей программы.
Другая возможная ошибка на этапе компоновки — несоответствие между объектным файлом и файлом описания процедуры или функции. Дело в том, что компилятор порождает вызовы процедур и функций исходя из их описания. Если функция описана в одном из исходных файлов, то он может проверить соответствие ее описания и исходного кода, но если обращение выполняется к библиотечной функции, то такая возможность отсутствует (библиотеки функций поставляются, как правило, в виде объектного кода). В том случае, когда имена функций совпадают, но описание не соответствует реальному объектному коду, может возникнуть трудно обнаруживаемая ошибка — такую ошибку можно отследить только при отладке результирующей программы. Конечно же, такие ошибки крайне редко встречаются в библиотеках систем программирования и других библиотеках процедур и функций, поставляемых известными производителями.
Компоновщик — это достаточно простой компонент в составе системы программирования. От него не зависит эффективность результирующей программы, но ее объем может зависеть от типа компоновщика. В простейшем случае при обнаружении ссылки на некоторый объектный файл компоновщик подключает к исполняемому файлу весь код этого объектного файла и все его данные. Тогда алгоритм работы компоновщика прост, но в этом варианте мы получаем исполняемый файл результирующей программы, который может содержать некоторую часть объектного кода, к которой никогда не будет обращений при выполнении программы. В более сложном случае компоновщик при обнаружении ссылки подключает к исполняемому файлу не весь код объектного файла, а только ту его часть, которая связана с разрешаемой ссылкой. В этом случае исполняемый файл результирующей программы будет иметь меньший объем, но код компоновщика усложнится, так как ему нужно будет отслеживать не только внешние, но и внутренние ссылки. Однако это незначительное усложнение, и, как правило, все современные системы программирования оснащены компоновщиками второго типа. Обычно компоновщик формирует простейший программный модуль, создаваемый как единое целое. Однако в общем случае компоновщик может создавать и другие модули: программные модули с оверлейной структурой, объектные модули библиотек и модули динамически подключаемых библиотек.
Загрузчики и отладчики. Функции загрузчика
Трансляция адресов. Настраивающий загрузчик
Объектные модули строятся на основе так называемых относительных адресов. Компилятор, порождающий объектные файлы, а затем и компоновщик, объединяющий их в единое целое, не могут знать точно, в какой физической области памяти компьютера будет располагаться программа в момент ее выполнения. Поэтому они работают не с реальными адресами ячеек ОЗУ, а с некоторыми относительными адресами. Такие адреса отсчитываются от условной точки, принятой за начало области памяти, занимаемой результирующей программой (обычно это точка начала первого модуля программы).
Конечно, ни одна программа не может быть исполнена в этих относительных адресах. Поэтому требуется модуль, который бы выполнял преобразование относительных адресов в реальные (абсолютные) адреса непосредственно в момент запуска программы на выполнение. Этот процесс называется трансляцией адресов, и выполняет его специальный модуль, называемый загрузчиком.
Однако загрузчик не всегда является составной частью системы программирования, поскольку выполняемые им функции зависят непосредственно от архитектуры целевой вычислительной системы, в которой выполняется результирующая программа, созданная системой программирования. На первых этапах развития ОС загрузчики существовали в виде отдельных модулей, которые выполняли трансляцию адресов и готовили программу к выполнению — создавали так называемый «образ задачи». Такая схема была характерна для многих ОС (например для ОСРВ на ЭВМ типа СМ-1, ОС RSX/11 или RAFOS на ЭВМ типа СМ-4 и т. п. [16, 41]). Образ задачи можно было сохранить на внешнем носителе или же создавать его вновь всякий раз при подготовке программы к выполнению.
С развитием вычислительных систем появилась возможность выполнять трансляцию адресов непосредственно в момент запуска программы на выполнение. Для этого в состав исполняемого файла включается таблица, содержащая перечень ссылок на адреса, которые необходимо подвергнуть трансляции. В момент запуска исполняемого файла ОС обрабатывает эту таблицу и преобразовывает относительные адреса в абсолютные. Такая схема, например, характерна для ОС типа MS DOS, которые широко распространены в среде персональных компьютеров. В этой схеме модуль загрузчика как таковой отсутствует (фактически он входит в состав ОС), а система программирования ответственна за подготовку таблицы трансляции адресов — эту функцию выполняет компоновщик.
В современных ОС существуют сложные методы преобразования адресов, которые работают непосредственно уже во время выполнения программы. Эти методы основаны на возможностях, аппаратно заложенных в архитектуру вычислительных комплексов. Методы трансляции адресов могут быть основаны на сегментной, страничной и сегментно-страничной организации памяти [15]. Тогда для выполнения трансляции адресов в момент запуска программы должны быть подготовлены соответствующие системные таблицы. Эти функции целиком ложатся на модули ОС, поэтому они не выполняются в системах программирования. Загрузчик, который выполняет трансляцию адресов в момент запуска программы, называется настраивающим загрузчиком. В современных вычислительных системах такой загрузчик входит в состав ОС, а компоновщик, входящий в состав системы программирования, готовит для настраивающего загрузчика таблицу трансляции адресов, входящую в состав исполняемого файла. Каждая ОС содержит в себе свой настраивающий загрузчик и предусматривает свой формат таблицы трансляции адресов — система программирования при создании исполняемого файла должна учитывать это. Это одна из причин, почему исполняемые файлы для различных ОС несовместимы между собой, даже если они предназначены для одной и той же архитектуры вычислительной системы (например исполняемый файл для ОС типа UNIX не будет напрямую исполняться в среде MS DOS, даже если обе ОС установлены на Intel-совместимом персональном компьютере).
Динамические загрузчики
Новые задачи встали перед загрузчиками с развитием ОС. В современных ОС появилась возможность создавать исполняемые программы, имеющие оверлейную структуру, использовать динамически загружаемые библиотеки и ресурсы пользовательского интерфейса. -
Первоначально ОС выполняла загрузку в оперативную память компьютера полностью всей исполняемой программы вместе с кодом всех используемых в ней библиотек и модулей в момент запуска этой программы на выполнение. При этом если объем программы превышал объем памяти, доступной для ее выполнения, то программа не могла быть выполнена. Также если код какой-нибудь библиотеки использовался в нескольких программах, то всякий раз он заново загружался в оперативную память. Это вело к неэффективному использованию памяти.
С развитием оверлейных структур и динамических библиотек появилась возможность загружать исполняемый код модуля программы или библиотеки в оперативную память не сразу же в момент запуска программы на выполнение, а в тот момент, когда произойдет обращение к функции или процедуре, содержащейся в этом коде [15]. При этом если обращение к модулю или библиотеке не происходит, то они в оперативную память компьютера не загружаются — и память на хранение их кода не расходуется. Кроме того, если код функций какой-нибудь библиотеки используется несколькими программами (особенно это относится к системным библиотекам), то нет необходимости несколько раз загружать один и тот же фрагмент кода — можно по мере необходимости обращаться к уже загруженному в оперативную память фрагменту. Напротив, код библиотеки, который не используется в данный момент ни одной программой, может быть удален из оперативной памяти (при возникновении обращения к нему он будет заново подгружен в память).
В предельном случае вся исполняемая программа может представлять собой незначительный по объему базовый модуль, загружаемый в память, а остальные модули и библиотеки будут тогда вызываться и подгружаться по мере необходимости. Такая структура позволяет существенно повысить эффективность использования оперативной памяти.
За обеспечение работы с динамически загружаемыми библиотеками и модулями отвечает динамический загрузчик.
Динамический загрузчик всегда входит в состав ОС. В его задачи входит следить за обращениями к динамически загружаемым библиотекам и модулям, загружать в оперативную память используемые библиотеки, следить за количеством обращений к каждой библиотеке, освобождать память, занимаемую неиспользуемыми библиотеками. При этом каждая динамически загружаемая библиотека (или модуль) должна представлять собой исполняемый файл определенной структуры, содержащий в себе данные, необходимые для трансляции адресов. При обращении к ней она загружается в оперативную память с помощью настраивающего загрузчика. При этом код модуля или библиотеки может использоваться несколькими исполняемыми программами, а данные должны дублироваться всякий раз при новом обращении, поскольку они должны быть уникальными
для каждой исполняемой программы. Более подробно о работе с динамическими библиотеками вы можете узнать в [2, 15, 24, 26, 27, 34, 43, 47].
Как и формат исполняемых файлов, формат динамически загружаемых библиотек и модулей зависит от типа ОС. При создании динамической библиотеки система программирования должна учитывать, в архитектуре какой вычислительной системы она будет выполняться. В остальном создание таких библиотек мало чем отличается от создания исполняемых файлов.
Другая задача, решаемая динамическим загрузчиком, — обеспечение доступа исполняемой программы к используемым ею ресурсам пользовательского интерфейса. Ресурсы пользовательского интерфейса могут содержаться внутри самого исполняемого файла или же в специально разработанных для этого файлах с данными. Они предоставляются исполняемой программе по мере обращения к ним. Как правило, каждый ресурс имеет уникальное имя в пределах данной программы. Задача динамического загрузчика — найти ресурс по имени, загрузить в оперативную память и предоставить программе доступ к нему, а при завершении использования — освободить память, занятую ресурсом. Функции работы с ресурсами пользовательского интерфейса зависят от типа ОС. Система программирования сама формирует файлы ресурсов или включает необходимые ресурсы непосредственно в исполняемый файл в нужном формате в зависимости от типа целевой вычислительной системы.
Отладчик. Функции отладчика
Еще одним модулем системы программирования, функции которого тесно связаны с выполнением программы, является отладчик.
Отладчик — это программный модуль, который позволяет выполнять основные задачи, связанные с мониторингом процесса выполнения результирующей прикладной программы. Этот процесс называется отладкой и включает в себя следующие основные возможности:
последовательное пошаговое выполнение результирующей программы на основе шагов по машинным командам или по операторам входного языка;
выполнение результирующей программы до достижения ею одной из заданных точек останова (адресов останова);
выполнение результирующей программы до наступления некоторых заданных условий, связанных с данными и адресами, обрабатываемыми этой программой;
просмотр содержимого областей памяти, занятых командами или данными результирующей программы.
Первоначально отладчики представляли собой отдельные программные модули, которые могли обрабатывать результирующую программу в терминах языка машинных команд. Их возможности в основном сводились к моделированию выполнения результирующих программ в архитектуре соответствующей вычислительной системы. Выполнение могло идти непрерывно либо по шагам.
Дальнейшее развитие отладчиков связано со следующими принципиальными моментами:
появлением интегрированных сред разработки;
появлением возможностей аппаратной поддержки средств отладки во многих вычислительных системах.
Первый из этих шагов дал возможность разработчикам программ работать не в терминах машинных команд, а в терминах исходного языка программирования, что значительно сократило трудозатраты на отладку программного обеспечения. При этом отладчики перестали быть отдельными модулями и стали интегрированной частью систем программирования, поскольку они должны были теперь поддерживать работу с таблицами идентификаторов (см. раздел «Таблицы идентификаторов. Организация таблиц идентификаторов» главы 2) и выполнять задачу, обратную идентификации лексических единиц языка (см. раздел «Семантический анализ и подготовка к генерации кода» главы 5). Это связано с тем, что в такой среде отладка программы идет в терминах имен, данных пользователем, а не в терминах внутренних имен, присвоенных компилятором. Соответствующие изменения потребовались также в функциях компиляторов и компоновщиков, поскольку они должны были включать таблицу имен в состав объектных и исполняемых файлов для ее обработки отладчиком.
Второй шаг позволил значительно расширить возможности средств отладки. Теперь для них не требовалось моделировать работу и архитектуру соответствующей вычислительной системы. Выполнение результирующей программы в режиме отладки стало возможным в той же среде, что и в обычном режиме. В задачу отладчика входили только функции перевода вычислительной системы в соответствующий режим перед запуском результирующей программы на отладку. Во многом эти функции являются приоритетными, поскольку зачастую требуют установки системных таблиц и флагов процессора вычислительной системы (мы рассмотрели большую часть этих вопросов в первой части данного учебника).
Отладчики в современных системах программирования представляют собой модули с развитым интерфейсом пользователя, работающие непосредственно с текстом и модулями исходной программы. Многие их функции интегрированы с функциями текстовых редакторов исходных текстов, входящих в состав систем программирования.
Библиотеки подпрограмм
Библиотеки подпрограмм как составная часть систем программирования
Библиотеки подпрограмм составляют существенную часть систем программирования. Наряду с дружественностью пользовательского интерфейса, состав доступных библиотек подпрограмм во многом определяет возможности системы программирования и ее позиции на рынке средств разработки программного обеспечения. Библиотеки подпрограмм входили в состав средств разработки начиная с самых ранних этапов их развития. Даже когда компиляторы еще представляли собой
отдельные программные модули, они уже были связаны с соответствующими библиотеками, поскольку компиляция так или иначе предусматривает связь программ со стандартными функциями исходного языка. Эти функции обязательно должны входить в состав библиотек.
С точки зрения системы программирования библиотеки подпрограмм состоят из двух основных компонентов. Это собственно файл (или множество файлов» библиотеки, содержащий объектный код, и набор файлов описаний функций подпрограмм, констант и переменных, составляющих библиотеку. Описания оформляются на соответствующем входном языке (например, для языка С или C++ это будет набор заголовочных файлов). Иногда эти файлы могут быть совмещены (например, в системе программирования Turbo Pascal стандартные библиотеки представлены в виде объектных файлов специального формата — TPU — Turbo Pascal Units). Кроме того, в современных системах программирования в состав библиотеки входит также описание ее на естественном языке в виде файла подсказок и справок.
Набор файлов описания библиотеки служит для информирования компилятора о составе входящих в библиотеку функций. Обрабатывая эти файлы, компилятор получает всю необходимую информацию о составе библиотеки с точки зрения входного языка программирования. Эти файлы предназначены только для того, чтобы избавить разработчика от необходимости постоянного описания библиотечных функций, подпрограмм, констант и переменных.
В состав системы программирования может входить большое количество разнообразных библиотек. Среди них всегда можно выделить основную библиотеку, содержащую обязательные функции входного языка программирования. Такая библиотека называется обычно стандартной библиотекой языка. Эта библиотека всегда используется компилятором, поскольку без нее разработка программ на данном входном языке невозможна. Все остальные библиотеки необязательны и подключаются к результирующей программе только по прямому указанию разработчика.
В процессе развития систем программирования состав библиотек постоянно расширялся. В них включалось все большее и большее число функций. Это было вызвано тем, что система программирования, предоставляющая пользователю более широкий выбор библиотечных функций, получала лучшие позиции на рынке средств разработки программного обеспечения. Сами по себе библиотеки подпрограмм и функций, созданных для того или иного языка, также становились товаром на рынке средств разработки. Этот естественный процесс продолжается до сих пор, и чем длиннее история существования того или иного языка программирования, тем шире диапазон существующих для него библиотек.
Системы программирования для некоторых языков продолжают существовать во многом благодаря тому, что для них создан мощный аппарат библиотечных функций. Так, язык FORTRAN существует благодаря широчайшему набору функций для работы с математическими и физическими процессами, а язык COBOL — функций из финансовой сферы.
В ходе развития систем программирования принципы создания и использования библиотечных функций претерпели мало изменений. Принципиально новые воз-
можности предоставили только современные ОС, которые позволили подключать к результирующим программам не статические, а динамические библиотеки.
Статические библиотеки подпрограмм
Статические библиотеки подпрограмм и функций представляют собой часть объектного кода, которая встраивается (подключается) к результирующей программе на этапе ее разработки.
Все статические библиотеки подключаются к результирующей программе один раз на этапе ее создания, после чего они являются ее неотъемлемой частью. Код статических библиотек входит в состав исполняемого файла программы точно так же, как и объектный код, созданный компилятором на основе исходного текста программы. При выполнении программы нет никакого различия между объектным кодом, построенным на основании исходного текста, созданного разработчиком, и объектным кодом библиотеки.
Объектный код статической библиотеки подключается компоновщиком к результирующей программе при создании исполняемого модуля. Поэтому по своей структуре статическая библиотека мало чем отличается от обычных объектных файлов, порождаемых компилятором. Чаще всего система программирования хранит объектный код входящих в ее состав библиотек в некотором упакованном виде. При подключении библиотеки к исполняемому файлу компоновщик распаковывает ее код и встраивает его в общий объектный код результирующей программы в обычном порядке.
Будучи один раз созданной с использованием статических библиотек, результирующая программа в дальнейшем уже никак не зависит от изменений в этих библиотеках, а также от их наличия в вычислительной системе, где она будет выполняться, —весь необходимый объектный код уже входит в состав такой программы. В этом очевидное преимущество использования статических библиотек. В то же время статические библиотеки обладают двумя недостатками, один из которых является весьма существенным:
Во-первых, при наличии ошибки в библиотеке она будет проявляться во всех программах, которые используют эту библиотеку, а после ее исправления все такие программы нужно будет построить (пересобрать) заново с использованием обновленной библиотеки. Конечно, если учесть, что в современных системах программирования все новые библиотеки появляются только после тщательной всесторонней отладки, этим недостатком можно пренебречь.
Во-вторых, поскольку объектный код статических библиотек встраивается в исполняемый файл, это ведет к увеличению объема результирующей программы. В современных прикладных программах более 50% объектного кода может составлять код из файлов библиотек. При наличии многих программ, использующих код одной и той же библиотеки, это ведет к неэффективному использованию как места для хранения исполняемых файлов программ, так и оперативной памяти вычислительной системы во время их выполнения. В особенности это относится к системным библиотекам — библиотекам ОС, которые используются если не всеми, то очень многими программами.
Именно второй недостаток статических библиотек послужил толчком к созданию другого типа библиотек подпрограмм и функций — динамически загружаемых (или просто динамических) библиотек.
Динамические библиотеки подпрограмм
Динамические (динамически загружаемые) библиотеки подключаются к результирующей программе в момент ее выполнения. В этом основное отличие динамических библиотек от обычных, статических библиотек.
Возможны два основных варианта загрузки динамических библиотек при выполнении результирующей программы. В первом варианте динамическая библиотека загружается в оперативную память компьютера сразу же, как только начинает выполняться программа, использующая данную библиотеку, вне зависимости от того, будет ли выполняться обращение к функциям библиотеки или нет. Во втором варианте библиотека загружается в оперативную память только тогда, когда происходит непосредственное обращение к одной из ее подпрограмм или функций. Соответственно, существует два варианта освобождения памяти, занимаемой динамической библиотекой: либо она освобождается только по завершении выполнения всей программы, либо по команде основной программы, сигнализирующей о том, что данная библиотека более использоваться не будет.
Второй вариант является более предпочтительным с точки зрения экономии объема занимаемой оперативной памяти, но он сложнее в реализации и требует указаний разработчика программы, поскольку только разработчик может явно определить моменты выполнения программы, которые требуют загрузки в память той или иной библиотеки, или наоборот, освобождения памяти, поскольку библиотека более не будет использоваться. Первый вариант менее экономично расходует оперативную память, но проще в реализации, поскольку компоновщик сам может определить перечень всех используемых в программе библиотек и обеспечить загрузку их в память в момент начала выполнения программы. Современные системы программирования предусматривают, как правило, оба варианта работы с динамически загружаемыми библиотеками — решение о том, какой вариант будет использован, принимает разработчик программы. В принципе, одна программа может предполагать различные варианты работы с различными библиотеками —выбор зависит от объема кода библиотеки и от частоты обращений к ней. За загрузку динамических библиотек в оперативную память, освобождение памяти, занятой динамическими библиотеками, а также за связь кода и данных библиотек с кодом и данными исполняемой программы отвечает динамический загрузчик, который входит в состав ОС. Он же обеспечивает повторное использование кода динамических библиотек. Повторное использование кода заключается в том, что если две различных программы обращаются к одной и той же динамической библиотеке, то нет необходимости загружать ее объектный код в оперативную память дважды — достаточно обеспечить доступ обеим программам к одной и той же копии объектного кода при условии разделения данных. Более подробно эти вопросы освещены в [24, 26, 27, 34, 43, 47].
Формат файлов динамических библиотек может быть различным — как правило, он строго определяется требованиями соответствующей ОС и близок к формату исполняемых файлов. Как и статические библиотеки, динамические библиотеки предусматривают описание входящих в них функций в виде текста на соответствующем входном языке, чтобы дать информацию о них компилятору в ходе обработки исходного текста программы и избавить разработчика от создания таких описаний. Но для динамических библиотек компилятор не включает в код программы обращения к функциям, как он это делает для статических библиотек. Вместо этого в код вставляются вызовы соответствующих функций ОС, обеспечивающих обращение к коду динамической библиотеки, если связь с библиотекой осуществляется по первому варианту работы. Если же связь с динамической библиотекой осуществляется по второму варианту, то разработчик сам должен организовать вызов соответствующих функций ОС в исходном коде.
Преимущества динамических библиотек очевидны — они не требуют включать в результирующую программу объектный код часто используемых функций, чем существенно сокращают ее объем. Конечно, динамические библиотеки требуют наличия в ОС специального механизма, позволяющего подключать часть объектного кода непосредственно по ходу выполнения программы. Однако для современных ОС, выполняющихся в вычислительных системах, которые поддерживают широкий набор методов адресации, это не является проблемой [15].
Недостатки динамически загружаемых библиотек заключаются в том, что результирующие программы оказываются связаны с объектным кодом, непосредственно не входящим в их состав. Тогда для выполнения такой программы обязательно требуется наличие всех используемых ею библиотек в составе вычислительной системы, где эта программа выполняется. Кроме того, логика работы результирующей программы становится зависимой от кода всех входящих в нее библиотек. Изменение библиотеки, которое может происходить независимо от разработчиков программы, может повлиять на функционирование самой программы. Такое развитие событий порой оказывается неожиданным для пользователя.
Поэтому использование динамических библиотек накладывает определенные обязательства как на разработчика программы, так и на создателей библиотек. Разработчик прикладной программы должен использовать библиотеку только так, как это определено ее создателем, а создатель библиотеки в случае ее модификации должен организовывать изменения таким образом, чтобы они не сказывались на логике работы программ, ориентированных на предыдущие версии его библиотеки. Подавляющее большинство разработчиков (как программ, так и библиотек) стремятся придерживаться этих правил, но не всегда им это удается1.
Широкий набор динамических библиотек поддерживается всеми современными ОС. Как правило, они содержат системные функции ОС и общедоступные функ-
В современных ОС появились средства, позволяющие поддерживать не только файлы, но и версии динамических библиотек. Они во многом используют методы, применяемые в системах управления версиями исходных файлов. Тогда приложение, обращаясь к библиотеке, может указать не только имя, но и требуемую версию вызываемой функции библиотеки.
ции программного интерфейса (API). Кроме того, многае независимые разработчики предоставляют для различных систем программирования свои динамические библиотеки как отдельные товары на рынке средств разработки прикладных программ.
Ресурсы пользовательского интерфейса. Редакторы ресурсов
Как уже было сказано выше, ресурсами пользовательского интерфейса будем называть множество данных, обеспечивающих внешний вид интерфейса пользователя результирующей программы, не связанных напрямую с логикой ее выполнения. Примерами ресурсов являются: тексты сообщений, выдаваемых программой, цветовая гамма элементов интерфейса, надписи на элементах управления и т. п. Ресурсы пользовательского интерфейса могут храниться в различном виде: либо в составе результирующей программы, либо в составе динамически загружаемой библиотеки, либо в виде отдельного файла. Формат хранения ресурсов также может быть различным. Это может быть специального вида двоичный код описания данных, близкий к объектному коду, или же структурированный текстовый файл. Формат и способ хранения ресурсов пользовательского интерфейса зависит от ОС. Как правило, каждая ОС предоставляет разработчику несколько вариантов, из которых он выбирает удобный для себя.
Работа с ресурсами пользовательского интерфейса включает в себя загрузку в память требуемого ресурса, отображение его на экране компьютера (в том или ином виде), а также освобождение памяти, занятой ресурсом. Эти действия выполняются с помощью специальных системных функций, предоставляемых ОС. Как правило, для удобства работы с ними эти функции входят в состав одной или нескольких динамически загружаемых библиотек, поставляемых ОС. Кроме того, в составе ОС обычно предусмотрен специальный набор наиболее часто используемых ресурсов интерфейса, называемых системными. Пользователь не должен разрабатывать и включать в состав результирующей программы такой ресурс —он может воспользоваться ресурсом, входящим в состав ОС. Примерами системных ресурсов являются: внешний вид текста системных сообщений (системный шрифт или фонт), основной фон окон и меню прикладных программ, внешний вид наиболее употребительных органов управления (кнопок, списков и т. п.).
В каком бы виде и формате ни хранились ресурсы в результирующей программе, порядок их создания практически всегда один и тот же: сначала создается описание ресурсов пользовательского интерфейса на входном языке описания ресурсов, затем оно обрабатывается компилятором ресурсов, входящим в состав системы программирования, после чего компоновщик подключает ресурсы к исполняемому файлу результирующей программы, или оформляет их в виде динамически загружаемой библиотеки, или оставляет в виде отдельного файла ресурсов. Язык описания ресурсов — это, как правило, простой язык, построенный на основе регулярной грамматики. Но строить описания ресурсов в таком виде неэффективно, так как любому разработчику внешний вид интерфейса программы
удобнее формировать в виде графических образов. Это тем более важно, поскольку часто интерфейс создают не программисты, а дизайнеры. Поэтому современные системы программирования имеют в своем составе графические средства редактирования ресурсов пользовательского интерфейса. Эти средства позволяют создавать интерфейс в виде графических образов, на основе которых потом строится его описание на языке описания ресурсов. В системах программирования, предлагающих средства быстрой разработки приложений (RAD), средства разработки графического интерфейса позволяют также создать простейший шаблон исходного кода для работы с этим интерфейсом.
Преимущество использования ресурсов заключается в том, что пользовательский интерфейс результирующей программы можно проектировать, создавать и изменять независимо от логики работы самой программы. Эту работу можно поручить дизайнерам, в то время как исходный код создают программисты. Например, чтобы перевести программу на новый язык1, часто бывает достаточно перевести на этот язык все текстовые сообщения и строковые элементы форм, и это гораздо удобнее выполнять, если они находятся отдельно, а не внутри исходного кода.
Мобильность и переносимость программного обеспечения
Условия мобильности программного обеспечения
Мобильностью программного обеспечения будем называть способность программного обеспечения выполнять свои функции на различных вычислительных системах вне зависимости от их архитектуры. В понятие «архитектура вычислительной системы» в данном случае включаются как аппаратные, так и все программные средства, необходимые для функционирования программного обеспечения.
Как уже отмечалось выше, на возможность выполнения программным обеспечением своих функций влияют очень многие факторы. В общем виде перечислить их все не представляется возможным, так как они существенно зависят от назначения программного обеспечения. Одно дело говорить о функциях драйвера некоторого периферийного устройства, другое дело — о работе какой-то утилиты ОС, и совершенно иное — о функциях прикладной программы.
Далее перечислены только основные факторы, влияющие на мобильность программного обеспечения:
состав специализированных аппаратных средств и периферийных устройств, используемых программным обеспечением;
тип ОС, на которую ориентировано программное обеспечение;
состав и функции динамически загружаемых библиотек;
Имеется в виду естественный язык общения программы с пользователем, а не язык про- граммнровання.
структура и формат хранения ресурсов пользовательского интерфейса, используемых программным обеспечением;
перечень внешних программ и модулей, с которыми должно взаимодействовать данное программное обеспечение при выполнении своих функций.
Чем меньше зависимость результирующей программы от каждого из этих факторов, тем выше ее мобильность. Если совершенно исключить зависимость от них, то можно добиться полной переносимости результирующей программы. Но, к сожалению, в реальной жизни добиться этого практически невозможно.
Единственный фактор, от которого можно полностью избавиться, — это зависимость от используемых специализированных аппаратных средств и периферийных устройств. Если рассматриваемая программа не является драйвером некоторого периферийного устройства или не ориентирована специально на работу с ним, то от такой зависимости можно и нужно отказаться. Все современные ОС и системы программирования предоставляют широкий диапазон средств для работы с типовыми периферийными устройствами — монитором, клавиатурой, мышью, принтером, а также с файлами и оперативной памятью. Разработчику нет никакой необходимости писать код для прямого взаимодействия с драйверами таких устройств, а уж тем более напрямую с самим аппаратным обеспечением. Это не только снижает мобильность программного обеспечения, но и увеличивает трудоемкость создания исходного кода, повышает вероятность возникновения ошибок. Большинство прикладных программ и значительная часть системных программ создаются вне какой-либо зависимости от аппаратных средств (если, конечно, иного не требует сама функциональность программы). В том случае, когда взаимодействие с нестандартным периферийным устройством все же необходимо, мобильность результирующей программы будет выше, если работа с аппаратными средствами будет идти через функции или API-драйверы этих средств, а если драйвер для них отсутствует, лучше разработать его отдельно от остальной части программы. -
Зависимость от других (программных) факторов исключить в результирующей программе практически невозможно, поскольку все они существенно зависят от типа ОС, на которую ориентирована программа. Тип ОС определяет формат исполняемого файла, формат и функции системных динамических библиотек, способ и форму хранения ресурсов пользовательского интерфейса. Любая современная результирующая программа не может существовать вне связи с этими элементами ОС. В лучшем случае можно добиться мобильности результирующей программы в рамках нескольких ОС одного типа или одного производителя (например, на всех ОС типа Linux или на всех ОС производства Microsoft), но не более того.
Обеспечение переносимости исходного кода программ
В большинстве случаев мобильность результирующей программы обеспечить невозможно, но можно добиться мобильности для исходного кода программы: программное обеспечение сохраняет способность выполнять свои функции на различных вычислительных системах вне зависимости от их архитектуры в том
случае, если оно создано на основе одного и того же исходного кода с помощью некоторой системы программирования и ориентировано на определенную целевую вычислительную систему. В таком варианте говорят о переносимости программного обеспечения.
На переносимость программного обеспечения влияют те же факторы, что и на его мобильность, но в меньшей степени1.
Поэтому для того чтобы добиться максимально возможной переносимости исходной программы, следует придерживаться следующих основных правил:
не использовать в исходном коде программы прямые обращения к периферийным устройствам компьютера, к драйверам аппаратных средств (кроме всего прочего, такие обращения могут быть запрещены в ОС для прикладных программ непривилегированных пользователей);
не включать в исходной код прямые обращения к функциям ОС, а также не использовать статические и динамические библиотеки, ориентированные на определенный тип ОС;
использовать только широко распространенные динамически загружаемые библиотеки (существующие во всех типах ОС) или динамические библиотеки, для которых имеется исходный код;
подключать динамически загружаемые библиотеки только средствами системы программирования (первый способ), не использовать для этой цели специфические функции ОС;
использовать только средства системы программирования для создания ресурсов пользовательского интерфейса, не обращаться к системным ресурсам;
исключить взаимодействие с внешними программами и модулями или ограничить его только программами, доступными во всех типах ОС;
не использовать для взаимодействия с внешними программами и модулями прямые обращения к средствам ОС.
Конечно, добиться соблюдения всех этих правил нелегко, и чем шире функциональность программного обеспечения, чем более развитым и сложным пользовательским интерфейсом оно обладает, тем сложнее обеспечивать его переносимость. Например, обеспечить переносимость программы с текстовым диалоговым интерфейсом, выполняющей математические расчеты, существенно проще, чем обеспечить переносимость графического редактора или компьютерной игры. В первом случае взаимодействие программного обеспечения с ОС минимально, а используемые библиотеки (математические функции) являются более широко распространенными, чем во втором (работа с графическими средствами).
Для реальных приложений, конечно же, невозможно полностью исключить взаимодействие с ОС. Поэтому для решения проблемы переносимости был предложен
1 Термины «мобильность» и «переносимость» близки по смыслу и предполагают разную трактовку в разной литературе (действительно, эти два слова по сути означают одно и то же). Здесь, с точки зрения автора, термин «мобильность» применяется к результирующей программе, в то время как «переносимость» — к исходному тексту программы.
подход, основанный на стандартизации функций библиотек, обеспечивающих взаимодействие программного обеспечения с ОС. Для этой цели разработаны несколько стандартов, которые описывают основные функции взаимодействия с ОС, их аргументы, выполняемые ими действия и правила обращения к этим функциям. Если ОС и система программирования поддерживают стандарт, то в их состав обязательно входят библиотеки, обеспечивающие выполнение функций, описанных в стандарте. Тогда взаимодействие приложения с ОС происходит так, как показано на рис. 6.2.
Рис. 6.2. Структура приложения, соответствующего стандарту переносимости
Программное обеспечение, построенное строго в соответствии с требованиями стандарта, структура которого изображена на рис. 6.2, является переносимым на все типы ОС, которые поддерживают данный стандарт. Для этого его достаточно только подготовить (откомпилировать и собрать) в системе программирования, ориентированной на данную ОС. Наиболее известным стандартом переносимости программного обеспечения является стандарт POSIX (IEEE Std 1003.1), разработанный IEEE (Institute of Electrical and Electronical Engineers)[15].
Кроме описанных выше требований, на переносимость программного обеспечения влияют возможности системы программирования, в которой оно создано. Во-первых, система программирования должна поддерживать выбранный стандарт переносимости исходного кода, во-вторых, она должна быть ориентирована на все типы ОС, для которых должна обеспечиваться переносимость программного обеспечения. Если программное обеспечение соответствует требованиям стандарта переносимости, то всегда можно выбрать другую систему программирования для перехода на новый тип ОС. Тогда переносимость исходного кода зависит от распространенности языка программирования, на котором он написан. Чем более распространенным является язык, чем больше для него существует систем программирования, тем выше возможности по переносимости программного обеспечения.
В настоящее время сложилось так, что самыми широкими возможностями по переносимости исходного кода обладают языки С и C++, которые изначально возникли в среде ОС UNIX, ориентированной на соответствие стандарту переносимости POSIX. Для этих языков существует самый широкий выбор систем
программирования от различных производителей. Гораздо уже возможности по переносимости для исходного кода на языке FORTRAN (для этого языка существует широкий набор библиотек, но сам язык существенно устарел). Для других распространенных языков — Basic и Pascal — вопрос о переносимости исходного кода остается открытым, поскольку в настоящее время для них доступен очень узкий выбор систем программирования. Фактически, программы, созданные на этих языках, переносимостью не обладают (фирма Microsoft — разработчик систем программирования для языка Visual Basic — не заботится о переносимости исходного кода, что определяется политикой этой компании; в то время как фирма Borland (Inprise) — разработчик систем программирования Delphi для языка Object Pascal — предпринимает определенные усилия в этом направлении, о чем будет сказано далее).
Однако даже используя широко распространенные языки программирования и следуя стандартам, практически невозможно добиться абсолютной переносимости исходного кода. Для этой цели существуют другие средства.
Мобильность программного обеспечения на основе интерпретаторов
Другой способ обеспечения мобильности и переносимости программного обеспечения —использование интерпретаторов для выполнения исходного кода программ. В этом случае для исходного кода обеспечивается полная переносимость (в этом случае понятия «мобильность» и «переносимость» совпадают). При использовании интерпретаторов для обеспечения переносимости исходного кода ограничения на прямое использование функций ОС должны соблюдаться точно так же, как и для компиляторов (зачастую сами интерпретаторы предполагают такого рода ограничения).
Этот способ универсален, но обладает двумя существенными недостатками:
исходный текст программ может быть выполнен интерпретатором далеко не для всех языков программирования;
скорость выполнения кода интерпретатором значительно ниже, чем при выполнении откомпилированного объектного кода.
Эти недостатки ограничивают применение интерпретаторов для обычных прикладных, а тем более системных программ. Однако данный способ нашел широкое применение в сети Интернет, где полная переносимость программного обеспечения играет первостепенную роль. Об этом будет сказано далее в соответствующем разделе. 、
Существует еще один вариант обеспечения мобильности программного обеспечения, ориентированный на использование не только компилятора, но и специального интерпретатора для обеспечения мобильности результирующей программы. В этом случае результатом работы компилятора является не объектный код, а некоторый промежуточный двоичный код, который не может быть непосредственно выполнен, а должен быть обработан специальным интерпретатором. В общем случае выполнение программного обеспечения в этом варианте происходит так, как показано на рис. 6.3.
Рис. 6.3. Обеспечение мобильности программного обеспечения на основе промежуточного двоичного кода
Использование промежуточного двоичного кода позволяет снизить влияние основного недостатка интерпретации — низкой скорости выполнения программы Увеличение скорости выполнения программы в такой схеме происходит, поскольку промежуточный двоичный код представляет собой простейший набор команд, который может быть описан регулярной грамматикой, а потому не требует сложной обработки. Такая схема работы используется для программного обеспечения, написанного на языке Java [15, 50, 56, 73]. Она рассмотрена далее в разделе, посвященном этому языку.
Преимущества и недостатки переносимости программ
В принципе, вопрос о переносимости программного обеспечения должен решаться разработчиком индивидуально в зависимости от функциональности программы и целей, которые перед собой ставят ее создатели.
Переносимость исходного кода обеспечивает создателям программного обеспечения более широкий рынок сбыта, а также снижает их зависимость от изменения архитектуры вычислительных систем в будущем. Кроме того, обеспечивая переносимость программного обеспечения и следуя стандартам, разработчики уменьшают зависимость коммерческого успеха создаваемого программного обеспечения от позиции на рынке производителей систем программирования и операционных систем. Если выбранная ОС или система программирования перестает устраивать разработчиков либо начинает терять свои позиции на рынке, они могут перейти на использование другой ОС или другой системы программирования, удовлетворяющей тому же стандарту. 、
Таковы преимущества переносимости исходного кода программ. Но у нее есть и свои недостатки.
Основным недостатком является тот факт, что, стремясь добиться большей переносимости исходного кода, разработчики вынуждены терять в эффективности. Ведь работа с драйверами аппаратных средств, прямые обращения к функциям ОС и библиотек являются самыми эффективными средствами работы с ними. Используя предусмотренный стандартом промежуточный уровень, разработчик вынужден согласиться с потерями в скорости выполнения программы и с увели-
чением объема исполняемого кода. И уж тем более теряется эффективность, когда используется интерпретация.
Ориентируясь на указанные преимущества и недостатки, создатель программы сам вправе решать, будет он стремиться к переносимости исходного кода или нет.
Разработка приложений в архитектуре «клиент-сервер»
История возникновения приложений с архитектурой «клиент-сервер»
Распространение динамически загружаемых библиотек и ресурсов пользовательского интерфейса программ привело к ситуации, когда большинство прикладных программ стали представлять собой не единый программный модуль, а набор сложным образом взаимосвязанных между собой компонентов. Многие из этих компонентов либо входили в состав ОС, либо же требовалась их поставка и установка от других разработчиков, которые очень часто могли быть никак не связаны с разработчиками самой прикладной программы.
При этом среди всего множества компонентов прикладной программы можно было выделить две логически цельные составляющие: первую — обеспечивающую «нижний уровень» работы приложения, отвечающую за методы хранения, резервирования, доступа и разделения данных; вторую — организующую «верхний уровень» работы приложения, включающий в себя логику обработки данных и интерфейс пользователя.
Первая составляющая, как правило, представляла собой набор компонентов, созданных разработчиками, никак не связанными с созданием данной прикладной программы. Часто она так или иначе должна была обеспечивать доступ к базам данных, которые могли предусматривать достаточно сложную организацию. Для работы ее компонентов зачастую требовалось наличие высокопроизводительной вычислительной системы.
Вторая составляющая включала в себя собственно алгоритмы, логику и весь интерфейс, созданные разработчиками прикладной программы. Эта составляющая предусматривала наличие взаимосвязи с данными, содержащимися в первой составляющей, для чего требовались методы доступа к этим данным. Требования к вычислительным системам, необходимым для выполнения ее компонентов, были обычно существенно ниже, чем для первой составляющей.
Таким образом, сложилось понятие приложения, построенного на основе архитектуры «клиент-сервер». Первый компонент в этой архитектуре стал носить название «сервер данных», а второй — «клиент», или «клиентское приложение». Постепенно с развитием этой архитектуры на рынке стали появляться компании, специализирующиеся на производстве серверов данных, в то же время разработчики прикладных программ стали все чаще использовать серверы данных от известных производителей.
Эту тенденцию не могли не отметить производители средств разработки, и на рынке появились системы программирования, специально ориентированные на разработку приложений, работающих в архитектуре «клиент-сервер».
Структура приложения, построенного в архитектуре «клиент-сервер»
Как уже было сказано выше, приложение, построенное на основе архитектуры «клиент-сервер», в общем виде состоит из двух основных частей: клиентской части и сервера данных. При этом первая (серверная) часть приложения обеспечивает реализацию всех процедур, связанных с хранением данных, доступом к данным, резервным копированием и защитой данных. Вторая (клиентская) часть приложения, получая данные от сервера данных, обеспечивает их обработку и отображение в интерфейсе пользователя. По командам клиентской части сервер данных выполняет также их добавление, обновление и удаление.
Как правило, разработчики, создающие программное обеспечение в архитектуре «клиент-сервер», разрабатывают именно клиентскую часть. В качестве сервера данных чаще всего выбирается сервер одного из известных производителей. Реже разрабатываются обе составляющих — и сервер данных, и клиентские приложения. Но тогда с одним сервером данных работают несколько различных клиентских приложений (иначе нет никакого смысла создавать программное обеспечение в данной архитектуре).
На начальном этапе развития архитектуры «клиент-сервер» доступ к данным сервера осуществлялся на уровне файлов, а разделение доступа к файлам обеспечивалось средствами ОС. Сервер данных выполнял только примитивные процедуры хранения, копирования и защиты файлов от несанкционированного доступа. Такие приложения иногда называют приложениями, построенными по принципу «файл-сервер». В общем виде схема их работы представлена на рис. 6.4. «-
Рис. 6.4. Схема доступа к данным для приложений типа «файл-сервер»
Приложения типа «файл-сервер» можно только весьма условно отнести к приложениям, построенным в архитектуре «клиент-сервер». Хотя в них присутствует серверный компонент, его функции в основном выполняются в ОС.
Главными недостатками приложений, построенных по принципу «файл-сервер», были следующие:
невозможность эффективно разделить доступ к данным при их одновременном использовании несколькими пользователями;
невозможность организовать защиту данных иначе, как на уровне доступа ОС;
высокая нагрузка на сеть для передачи файлов, если сервер данных и клиентское приложение работают на разных компьютерах в составе сети.
Полноценное приложение в архитектуре «клиент-сервер» возможно получить, если использовать БД для хранения данных и СУБД (систему управления базами данных) для доступа к данным. Схема работы такого приложения представлена на рис. 6.5.
Рис. 6.5. Схема доступа к данным для приложений в архитектуре «клиент-сервер»
Все функции по хранению данных, доступу к ним, защите и резервному копированию данных в такой схеме реализует СУБД на сервере. Такой подход освобождает клиентские рабочие места от реализации этих функций и снижает требования к ним. Клиентское приложение не работает непосредственно с файлами и данными — оно обращается к СУБД с запросами на получение (просмотр) данных, их добавление, модификацию и удаление. При работе сервера данных и клиентского приложения на разных компьютерах в составе сети через сеть будут передаваться не все данные из БД, а только запросы клиента и ответы СУБД на них. Таким образом в архитектуре «клиент-сервер» снижается нагрузка на сеть при обмене данными.
Полноценное приложение, созданное в архитектуре «клиент-сервер», решает все. проблемы, связанные с недостатками приложений типа «файл-сервер», но требует наличия СУБД и развитых средств взаимодействия с ней. По мере развития данной архитектуры на рынке стали появляться СУБД различных типов. Все СУБД можно разделить на три основных типа: реляционные, сетевые (не путать
с распределенными БД) и объектные (объектно-ориентированные). Кроме того, СУБД подразделяются по способам доступа и хранения информации.
Сейчас на рынке СУБД доступен широкий спектр различных серверов данных от самых простейших настольных СУБД, практически мало чем отличающихся от приложений типа «файл-сервер» (например, такие СУБД, как PARADOX или Microsoft Access), до промышленных СУБД с развитыми средствами управления данными (такие СУБД, как Microsoft SQL Server или ORACLE). На рынке промышленных СУБД в настоящее время доминируют несколько наиболее известных компаний-производителей, предлагающих стандартизованные интерфейсы для доступа к создаваемым ими СУБД. На них, в свою очередь, стали ориентироваться и разработчики прикладных программ.
Современные серверы данных. Язык запросов данных
Принципы построения серверов данных. Язык SQL
В настоящее время наибольшее распространение на рынке СУБД получили реляционные БД. В качестве примеров таких СУБД, рассчитанных на применение в качестве промышленных серверов хранения данных (вплоть до корпоративного уровня), можно назвать СУБД Sybase, Microsoft SQL Server, Oracle, DB2. Принципы, лежащие в основе реляционных СУБД, стали определяющими в выборе методов взаимодействия между клиентской и серверной частью в архитектуре «клиент-сервер». Этих базовых принципов стараются придерживаться все ведущие разработчики СУБД, в том числе и СУБД, построенных на основании иных технологий, чем реляционные БД.
Главным фактором, определяющим взаимодействие клиентской части приложения и сервера данных, стал механизм запросов, с которыми клиентское приложение обращается к серверу. Этот механизм должен предоставить клиенту (фед- ства, которые давали бы ему возможность определить, какие данные он хочет получить от сервера и какие операции с ними выполнить. Для этой цели был предложен специальный язык описания запросов — SQL (Structured Query Language, язык структурированных запросов). По мере развития языка SQL он был признан всеми разработчиками серверов данных, и со временем появились международные стандарты языка запросов (например, известный стандарт SQL 92, который в настоящее время поддерживается всеми серверами данных от известных производителей).
Язык SQL предоставляет средства для выполнения четырех основных операций с данными на сервере: выборка (SELECT), добавление (INSERT), обновление (UPDATE) и удаление (DELETE). Кроме этих основных операций существуют другие, вспомогательные, связанные с распределением прав доступа и другими функциями сервера данных. Каждая операция описывается соответствующим предложением языка, построенным с учетом его синтаксических и семантических правил. Клиентское приложение, желающее выполнить какое-либо действие с данными, должно сформулировать его в виде предложения языка SQL, направить запрос
с этим предложением серверу данных и дождаться ответа от него, в котором будет сформулирован результат выполнения операции. Если действие не может быть выполнено с помощью одной операции языка SQL, оно разбивается на несколько операций, которые выполняются последовательно.
Другим важным механизмом, определяющим взаимодействие клиентской и серверной частей, является механизм транзакций. Его суть заключается в том, что клиентское приложение может определить группу взаимосвязанных действий над данными, которые либо должны быть выполнены все вместе в комплексе, либо не выполнены вообще. Взаимосвязь действий определяется логикой клиентской части. Тогда, начав выполнение этой группы действий (открыв транзакцию), клиент последовательно передает серверу данных все команды в виде предложений языка SQL и ожидает результатов. При правильности выполнения всех команд клиентская часть подтверждает это (закрывает транзакцию) и только после этого операция считается выполненной, и все сделанные изменения вносятся в данные на сервере. Если же по каким-то причинам операция не могла быть выполнена, клиент отказывается от нее (отменяет транзакцию), и сервер должен восстановить то состояние данных, которое было до начала транзакции. Взаимодействие клиентской и серверной частей приложения в архитектуре «клиент-сервер» здесь описано только в самом общем виде. Рассмотрение операторов языка SQL, механизма транзакций и других механизмов, связанных с работой СУБД, не входит в рамки данного учебника. Об этом можно узнать из книг, посвященных современным СУБД.
На стороне сервера каждое предложение SQL должно интерпретироваться в последовательность операций, выполняемых сервером. Получив SQL-запрос от клиента, сервер распознает его на, основе грамматики SQL, определяющей синтаксис запроса, а также проверяет семантику, основываясь на структуре БД, которая известна серверу данных. Если запрос содержит синтаксические или семантические ошибки, сервер сообщает об этом клиенту. Если же запрос правильный, на его основе сервер строит схему выполнения запроса, которую затем выполняет и передает результат ее выполнения клиенту.
ПРИМЕЧАНИЕ
Видно, что схема обработки и выполнения SQL-запросов на сервере данных полностью соответствует принципам, на основе которых функционируют интерпретаторы и компиляторы для языков программирования. С этой точки зрения язык SQL является полноправным компьютерным языком (хотя нельзя сказать, что он является языком программирования).
Видно, что этой схеме присущ недостаток, который связан со всеми интерпретируемыми языками, — каждый раз сервер данных вынужден тратить время на распознавание запроса и проверку его правильности. В том случае, когда клиент направляет серверу часто повторяющиеся типовые запросы, это ведет к неэффективным затратам времени. Эффективность схемы была бы выше, если бы сервер данных мог работать по схеме компилятора — один раз распознавать запрос, а потом выполнять его каждый раз при обращении клиента. Разработчики
СУБД обратили на это внимание, и в современных серверах данных присутствуют соответствующие решения в виде запросов с параметрами, предопределенных выборок (VIEW) и хранимых процедур сервера. Обо всем этом лучше узнать в специализированной литературе, посвященной современным СУБД.
Технологии доступа к серверам данных
Используя стандартизованный язык SQL, разработчик клиентской части приложения, работающего в архитектуре «клиент-сервер», может строить запросы к серверу данных, не ориентируясь на определенный тип СУБД. При этом взаимодействие клиентской части с сервером на уровне запросов не будет зависеть от типа используемого сервера данных (СУБД). Однако остается открытым вопрос о том, как SQL-запросы будут передаваться от клиента серверу и каким образом клиент будет получать ответы.
Наиболее очевидным решением было бы использование для этой цели динамически загружаемых библиотек. Клиентское приложение обращается к функции соответствующей библиотеки и передает ей запрос к серверу в виде предложения на языке SQL. В задачу библиотеки входит установить связь с сервером, передать ему запрос, дождаться ответа и вернуть результат клиенту в качестве результата выполнения функции. Однако такое простое решение обладает одним существенным недостатком: для каждого типа сервера должна использоваться своя динамически загружаемая библиотека со своими функциями, что делает клиентское приложение зависимым от типа СУБД.
В настоящее время на рынке СУБД доминируют несколько крупных производителей, среди которых всегда можно выбрать сервер данных, удовлетворяющий тем или иным требованиям, предъявляемым для решения прикладной задачи. Поэтому зачастую разработчики клиентской части программного обеспечения, работающего в архитектуре «клиент-сервер», пренебрегают указанным недостатком, используя описанную выше схему для взаимодействия с сервером данных. Они разрабатывают свои приложения, ориентируясь на определенный тип СУБД. Этому способствует тот факт, что многие фирмы-производители СУБД (такие, например, как Oracle или Microsoft) предлагают не только серверы данных, но и системы программирования, ориентированные на работу с конкретным типом СУБД. Такой путь имеет свои преимущества, так как прямое обращение к динамической библиотеке, взаимодействующей с сервером данных, дает наибольшую эффективность по скорости выполнения запросов клиента.
Однако зависимость от типа СУБД не всегда допустима для клиентской части в архитектуре «клиент-сервер», особенно в том случае, когда разработчики стремятся добиться переносимости своего программного обеспечения. Для этой цели служат универсальные интерфейсы взаимодействия клиентской и серверной частей в архитектуре «клиент-сервер». Существует несколько вариантов таких интерфейсов от разных производителей. Одним из наиболее распространенных является интерфейс ODBC.
ODBC (Open Database Connectivity, открытая взаимосвязь с БД) является средством, позволяющим унифицировать организацию взаимодействия с различными СУБД. Для этого доступ к базе данных осуществляется при помощи специ-
ального ODBC-драйвера, который транслирует запросы к базе данных на язык, поддерживаемый конкретной СУБД.
Для установления соединения с БД технология ODBC использует ODBC-драйверы и источники данных (data sources), которые позволяют настроиться на сеанс конкретного пользователя СУБД. Для этого источник содержит имя пользователя и его пароль, а также при необходимости другую информацию, требуемую для присоединения к СУБД. ODBC-драйвер представляет собой динамически загружаемую библиотеку, которая может использоваться приложением для получения доступа к конкретному серверу данных. Каждому типу СУБД соответствует свой ODBC-драйвер. Система ODBC также включает в себя ряд служебных утилит.
Взаимодействие клиентской части программного обеспечения с СУБД осуществляется при помощи набора системных вызовов, которые выполняются по отношению к источнику данных. Источник данных взаимодействует с драйвером ODBC, транслирует ему запросы клиента и получает ответы, а тот, в свою очередь, обращается к СУБД. При необходимости работать с другим типом СУБД достаточно указать другой тип ODBC-драйвера в источнике данных, при этом не требуется изменять саму клиентскую часть программного обеспечения, работающего в архитектуре «клиент-сервер».
ВНИМАНИЕ
Переход клиентской части программного обеспечения в архитектуре «клиент-сервер» с одного типа сервера данных на другой возможен только в том случае, если для взаимодействия с СУБД клиентская часть использует запросы, удовлетворяющие стандарту, поддерживаемому обоими серверами.
Такая двухступенчатая схема взаимодействия клиента с сервером данных обеспечивает независимость клиентской части от типа СУБД на сервере данных, но в целом снижает эффективность работы приложения в архитектуре «клиент-сервер», поскольку запрос, посланный клиентом, дважды обрабатывается различными библиотеками функций прежде, чем попадет на сервер. Как и в случае решения вопроса о переносимости программного обеспечения, решение вопроса о выборе способа взаимодействия с сервером данных остается за разработчиком клиентской части программного обеспечения и зависит от предъявляемых к нему требований.
Более подробно об организации приложений на основе архитектуры «клиент- сервер» можно узнать в [24, 26, 43, 70].
Принципы создания приложений в архитектуре «клиент-сервер»
Создание приложений для архитектуры «клиент-сервер»
Ситуация, связанная с распространением на рынке приложений, построенных на основе архитектуры «клиент-сервер», оказала свое влияние и на структуру систем программирования. Многие из них стали предлагать средства, ориентиро-
ванные на создание приложений в архитектуре «клиент-сервер». Как правило, эти средства поставляются в составе системы программирования и поддерживают возможность работы с широким диапазоном известных серверов данных через один или несколько доступных интерфейсов обмена данными. Разработчик прикладной программы выбирает одно из доступных средств плюс возможный тип сервера (или несколько возможных типов), и тогда его задача сводится только к созданию клиентской части приложения, построенной на основе выбранного интерфейса.
Создав клиентскую часть, разработчик может далее использовать и распространять ее только в комплексе с соответствующими средствами из состава системы программирования. Интерфейс обмена данными обычно входит в состав системы программирования или в состав ОС. Большинство систем программирования предоставляют возможность распространения средств доступа к серверной части без каких-либо дополнительных ограничений.
Что касается самой серверной части, то возможны два пути: простейшие СУБД требуют от разработчиков приобретения лицензий на средства создания и отладки БД, но часто позволяют распространять результаты работы без дополнительных ограничений; мощные промышленные СУБД, ориентированные на работу десятков и сотен пользователей, требуют приобретения лицензий как на создание, так и на распространение серверной части приложения. В этом случае конечный пользователь приложения получает целый комплекс программных продуктов от множества разработчиков.
Преимущества и недостатки архитектуры «клиент-сервер»
По сравнению с ранее существовавшими приложениями, приложения, построенные на основе архитектуры «клиент-сервер», обеспечивают своим разработчикам ряд преимуществ:,
разработчики приложений в архитектуре «клиент-сервер» избавлены от необходимости самостоятельно создавать средства для хранения данных, разделения доступа к ним, защиты и резервного копирования данных — все эти функции берет на себя СУБД;
СУБД обеспечивает высоконадежные механизмы разделения доступа к данным и защиты их от несанкционированного доступа, удовлетворяющие общепризнанным стандартам;
все функции по управлению данными выполняются на сервере данных, что снижает требования к вычислительным ресурсам рабочих станций, на которых выполняются клиентские приложения;
для обмена данными между клиентским приложением и сервером данных через сеть передаются не все данные, а только запросы клиента и ответы сервера, что снижает нагрузку на сеть;
при необходимости увеличить количество клиентов в системе достаточно включить в сеть новые рабочие станции, увеличить мощность сервера и пропускную способность сети (если требуется) — нет необходимости обновлять программное и аппаратное обеспечение уже существующих рабочих станций.
В то же время сама по себе архитектура «клиент-сервер» не лишена некоторых недостатков:
функции управления данными возложены на сервер данных, но обработка данных по-прежнему выполняется клиентскими приложениями, что не позволяет существенно снизить требования к ним, если логика системы предусматривает достаточно сложные манипуляции с данными;
при необходимости изменить или дополнить логику обработки данных нужно выполнить обновление клиентских приложений на всех рабочих местах, что может быть достаточно трудоемко;
если необходимо изменить только внешний вид интерфейса пользователя (отображение данных), но оставить неизменной логику обработки данных, чаще всего требуется заново создать и установить на рабочем месте новый вариант клиентской части системы;
при использовании мощной промышленной СУБД требуется наличие лицензии на подключение к СУБД для каждого рабочего места, где установлена клиентская часть программного обеспечения.
Для устранения этих недостатков была предложена следующая модель разработки приложений — трехуровневая, а в общем случае — многоуровневая архитектура.
Разработка программ
в многоуровневой архитектуре
Принципы разработки приложений в многоуровневой архитектуре
Понятие о трехуровневой архитектуре программного обеспечения
Трехуровневая архитектура разработки приложений явилась логическим продолжением идей, заложенных в архитектуре «клиент-сервер».
Главным недостатком архитектуры приложений типа «клиент-сервер» стал тот факт, что в клиентской части приложения совмещались как довольно сложные функции, связанные с обработкой получаемых от сервера данных, так и более простые функции организации интерфейса пользователя. Для выполнения этих функций к вычислительной системе должны предъявляться разные требования, и в том случае, когда выполняется сложная обработка данных, эти требования со стороны «клиентской» части приложения могут быть непомерно велики. Кроме того, обработка данных (логика приложения), как правило, изменяется незначительно по мере прохождения жизненного цикла программного обеспечения, развития приложения и выхода его новых версий. В то же время интерфейсная часть может серьезно видоизменяться и в предельном случае подстраиваться под требования конкретного заказчика.
Еще одним фактором, повлиявшим на дальнейшее развитие архитектуры «клиент-сервер», стало распространение глобальных сетей и развитие всемирной сети Интернет. Многие приложения стали нуждаться в предоставлении пользователю возможности доступа к данным посредством глобальной сети. Возможностей архитектуры «клиент-сервер» для этой цели во многих случаях недостаточно, поскольку клиент зачастую может не иметь никаких вычислительных ресурсов, кроме программы навигации по сети (браузера, browser).
Поэтому дальнейшим развитием архитектуры «клиент-сервер» стало разделение клиентской части еще на две составляющих: сервер приложений (английские термины «application server» или «middleware»), реализующий обработку данных (логику приложения), и «тонкий клиент» («thin client»), обеспечивающий интерфейс и доступ к результатам обработки (далее «тонкий клиент» будем называть просто «клиент»). Серверная часть осталась без изменений, но теперь она стала называться «сервер данных», или «сервер баз данных» («database server»), а не просто «сервер», чтобы не путать с сервером приложений.
Простейшая структура программного обеспечения, построенного на основе трехуровневой архитектуры, представлена на рис. 6.6.
Рис. 6.6. Структура приложения, построенного на основе трехуровневой архитектуры
Как уже было сказано, в состав программного обеспечения, построенного на основе трехуровневой архитектуры, входят три основных составляющих: сервер данных, сервер приложений и клиентская часть. Сервер данных, как и в случае архитектуры «клиент-сервер», выполняет все операции, связанные с управлением данными: хранение данных, доступ к данным, защита и резервное копирование данных. Как и в архитектуре «клиент-сервер», в качестве сервера данных в трехуровневой архитектуре чаще всего выступает соответствующая СУБД. Сервер приложений выполняет все функции, связанные с обработкой данных, а также он формирует все запросы к серверу данных и обеспечивает представление данных для клиентской части в той или иной форме. А на клиентскую часть приходятся функции, связанные с отображением данных и организацией интерфейса пользователя.
Особенности разработки программного обеспечения для многоуровневой архитектуры
В общем случае программное обеспечение, построенное на основе трехуровневой архитектуры, может иметь более сложную структуру, чем показано на рис. 6.6. Например, сервер приложений может обмениваться данными не с одним, а с несколькими серверами данных, или клиентская часть может взаимодействовать с несколькими серверами приложений. С другой стороны, по своим функциям сам сервер приложений может быть разделен на несколько уровней. В самом простейшем случае первый уровень будет взаимодействовать с сервером данных, второй уровень — выполнять обработку данных, а третий уровень — формировать данные для представления их клиенту. В некоторых случаях такое усложнение системы оправданно. Тогда говорят не о трехуровневой, а о многоуровневой архитектуре программного обеспечения.
Несмотря на рассмотренные выше возможные усложнения трехуровневой архитектуры программного обеспечения, принципы, лежащие в ее основе, остаются неизменными и могут быть рассмотрены в рамках трехуровневой архитектуры. Увеличение количества серверов данных или серверов приложений в каждом конкретном случае, а также разбиение самого сервера приложений на несколько уровней не вносят принципиальных изменений в организацию механизмов обмена данными между ними. Просто увеличивается количество взаимодействующих приложений, и могут усложняться протоколы обмена данными между ними.
Если в архитектуре «клиент-сервер» разработчик прикладной программы создавал только код клиентской части, а в качестве сервера данных использовал, как правило, одну из имеющихся на рынке СУБД, то в трехуровневой архитектуре разработчик должен создавать две составляющих — сервер приложений и клиентскую часть, а также выбрать механизм обмена данными между ними и определить протокол обмена данными. Это является принципиальным отличием разработки программного обеспечения для трехуровневой архитектуры от разработки программного обеспечения для архитектуры «клиент-сервер».
Далее будут рассмотрены механизмы, лежащие в основе организации обмена данными между сервером приложений и клиентской частью.
Технологии взаимодействия с сервером приложений
Технология RPC (Remote Procedure Call)
Технология RPC (Remote Procedure Call, вызов удаленных процедур) возникла для обеспечения взаимодействия двух параллельно выполняющихся процессов в ОС типа UNIX задолго до появления многоуровневых архитектур программного обеспечения. Ее основы были заложены в саму архитектуру ОС типа UNIX [8, 20, 29, 46].
Вызов удаленной процедуры заключается в том, что один из процессов («процесс-клиент») запрашивает у другого процесса («процесса-сервера») некоторую услугу (сервис) и не продолжает свое выполнение до тех пор, пока не получит
соответствующие результаты. Видно, что по смыслу такой механизм взаимодействия процессов напоминает вызов процедуры или функции в прикладной программе (отсюда и происходит название). Разница заключается в том, что выполнение вызова может происходить не только в рамках разных задач, но и на разных компьютерах.
Кроме того, видно, что механизм вызова RPC очень похож на обмен данными между клиентской частью и сервером данных в приложении, построенном на основе архитектуры «клиент-сервер» (не случайно процессы и приложения имеют схожие названия). Это не удивительно, поскольку в большинстве случаев программное обеспечение в архитектуре «клиент-сервер» также использует механизмы RPC, просто они остаются закрытыми для разработчика прикладной программы. Реализация технологии RPC достаточно сложна, поскольку этот механизм должен обеспечить работу взаимодействующих приложений, возможно, находящихся на разных компьютерах. Если при обращении к процедуре или функции в рамках одного приложения на одном компьютере передача данных выполняется через стек (см. раздел об организации дисплея памяти процедуры или функции в данном учебнике) или общие области памяти (глобальные переменные), то в случае удаленного вызова передача параметров процедуре превращается в задачу синхронизации двух приложений и осуществления передачи запроса по сети. Соответственно, получение результата также должно использовать сетевые механизмы для взаимодействия двух приложений.
Также надо отметить, что одни и те же данные могут иметь разное представление в компьютерах с разной архитектурой. Поэтому еще одной задачей RPC является автоматическое обеспечение преобразования форматов данных при взаимодействии приложений, выполняющихся на разнородных компьютерах.
Удаленный вызов процедур включает в себя следующие шаги [72, 73, 74]:
клиент осуществляет локальный вызов процедуры, называемой «заглушкой» (stub);
процедура-заглушка принимает аргументы, преобразует их в стандартную форму и формирует сетевой запрос к серверу; упаковка аргументов и создание сетевого запроса называется «сборкой» (marshalling);
сетевой запрос пересылается на удаленный компьютер, где соответствующий модуль RPC должен ожидать такой запрос;
модуль RPC (который, как правило, входит в состав ОС) при получении запроса извлекает параметры вызова (unmarshalling), определяет тип сервера, которому предназначается вызов;
модуль RPC на удаленном компьютере обращается к серверу, передает ему параметры вызова и ожидает получения результата;
полученный результат преобразуется в стандартную форму, формируется сетевой запрос (marshalling) и передается процедуре-заглушке;
процедура-заглушка извлекает результат вызова из полученного сетевого запроса (unmarshalling) и возвращает его клиенту; выполнение вызова RPC закончено.
В общем виде схема выполнения вызова RPC представлена на рис. 6.7.
Передача сетевого Передача сетевого запроса
запроса на вызов на возврат результата
Рис. 6.7. Выполнение вызова удаленной процедуры по технологии RPC
Столь сложный механизм взаимодействия определяет тот факт, что реализация механизма обмена данными между клиентской частью программного обеспечения и сервером приложений не может быть полностью возложена на разработчика прикладной программы. Для этой цели должны использоваться функции ОС, а для организации обмена данными между приложениями, выполняющимися на компьютерах с различной архитектурой, должны быть разработаны соответствующие стандарты.
Использование RPC накладывает определенные ограничения на тип связи между приложениями. Дело в том, что в RPC применяется синхронный механизм взаимодействия: запрашивающее приложение выдает запрос и ждет ответа. На время ожидания приложение оказывается заблокированным. В связи с этим развертывать основанные на RPC приложения представляется целесообразным в локальных сетях, где время ответа обычно не очень велико. Кроме того, RPC является механизмом взаимодействия, ориентированным на соединение. В связи с этим RPC не может быть применена в глобальных сетях, так как вероятность недоступности приложения в этом случае достаточно велика.
Технологии MOM (Message Oriented Middleware) и ORB (Object Request Broker)
С развитием программного обеспечения, построенного на основе трехуровневой архитектуры, на рынке стали появляться новые технологии организации взаимодействия клиентской части с сервером приложений, отличные от RPC.
Программное обеспечение, обеспечивающее взаимодействие между приложениями на разных уровнях, получило название «промежуточное программное обеспечение» (от англ, «middleware»). Следующим шагом в разработке промежуточного
программного обеспечения для взаимодействия между активными приложениями стали системы передачи сообщений. Принцип их построения достаточно прост, но тем не менее они предоставляют огромные возможности по связыванию программ.
В основе систем передачи сообщений лежит технология очередей сообщений: приложения обмениваются информацией не непосредственно друг с другом, а используя специальные буферы (очереди). В случае необходимости обмена данными программа пересылает их в принадлежащую ей очередь и продолжает функционирование. Доставку сообщения по назначению и его хранение обеспечивает специальное программное обеспечение — MOM (Message Oriented Middleware, ориентированное на сообщения промежуточное программное обеспечение). При этом МОМ, как правило, может работать на разных программно-аппаратных платформах и с использованием различных сетевых протоколов. Мультиплат- формность достигается за счет минимизации функций, выполняемых клиентской частью, а поддержка различных протоколов — за счет использования внутреннего протокола обмена информацией. Разработчику же предоставляется несложный и высокоуровневый API для работы с очередями сообщений.
Наличие очередей сообщений гарантирует доставку информации: в случае сбоев или отказов в сети, а также при отказе серверов будет обеспечено либо сохранение сообщения до восстановления соединения, либо его повторная передача, либо же будет произведен поиск нового пути в обход отказавшего участка.
Системы, построенные на базе МОМ, похожи на системы электронной почты, но отличаются от последних тем, что обеспечивают взаимодействие между приложениями, а не между людьми. Соответственно МОМ предназначена для передачи структурированной информации преимущественно технологического типа (то есть порождаемой без участия пользователя), в то время как системы электронной почты осуществляют в большинстве случаев передачу неструктурированной информации.
Технология брокеров запросов к объектам (ORB, Object Request Broker) является наряду с МОМ наиболее бурно развивающимся типом программного обеспечения для серверов приложений. ORB управляют обменом сообщениями в сети. Подобно «человеческому» брокеру, ORB выполняет функции интеллектуального посредника, то есть принимает запросы от клиента (клиентского приложения), осуществляет поиск и активизацию удаленных объектов (серверов приложений), которые принципиально могут ответить на запрос, и передает ответ объектам запрашивающего приложения.
ORB, как и RPC и МОМ, скрывает от пользователя процесс доступа к удаленным объектам. Запрашивающий клиент должен знать имя активизируемого объекта (сервера приложений) и передать ему некоторые параметры (как правило, это информация об интерфейсе вызываемого объекта — своего рода API для ORB). Интерес к ORB подогревается тем, что это программное обеспечение для серверов приложений поддерживает объектную модель, ставшую стандартом де-факто при разработке больших информационных систем.
Организация серверов приложений
Столь сложная организация взаимодействия клиентской части с сервером приложений, с одной стороны, и большой интерес к разработке приложений для трехуровневой архитектуры, с другой стороны, привели к развитию в составе современных ОС соответствующих средств, которые обеспечивают выполнение обращений клиентской части к серверу приложений.
В настоящее время на рынке конкурируют стандарт CORBA и технология COM/DCOM корпорации Microsoft. Семейство стандартов COM/DCOM создано фирмой Microsoft для ОС семейства Microsoft Windows [66, 67, 68], а семейство стандартов CORBA (Common Object Request Broker Architecture) поддерживается специальным консорциумом, состоящим из широкого круга производителей ОС и систем программирования для большого спектра различных вычислительных архитектур [60]. Этот последний стандарт (CORBA) претендует на то, чтобы обеспечивав переносимость серверов приложений и клиентских частей, соответствующих ему. Детальное рассмотрение такого рода стандартов и принципов их организации не входит в рамки темы данной книги.
Современные системы программирования в настоящее время обеспечивают поддержку разработки приложений в трехуровневой (трехзвенной) архитектуре. Средства поддержки тех или иных стандартов, необходимых для работы клиентской части и сервера приложений в трехуровневой архитектуре, сейчас присутствуют в составе многих систем программирования [15]. Принципы их использования и распространения аналогичны принципам, применяемым для средств поддержки архитектуры типа «клиент-сервер». Следует заметить, что существуют системы программирования, ориентированные на разработку либо клиентской части, либо сервера приложений; и в то же время многие системы программирования стремятся предоставить разработчикам средства для создания обеих частей в трехуровневой архитектуре. Сервер баз данных в трехуровневой архитектуре по-прежнему чаще всего является продуктом стороннего разработчика (как правило, производителя СУБД)1.
Используя описанные выше технологии и стандарты, разработчик может сам создать сервер приложений, а затем и клиентскую часть для своего программного продукта, разработать протоколы обмена данными между ними и создать соответствующие функции. Однако создание сервера приложений и разработка протоколов взаимодействия с ним — это достаточно сложный и трудоемкий процесс, содержащий много факторов, которые потенциально могут привести к появлению сложно обнаруживаемых ошибок. С другой стороны, в составе сервера приложений только связанные с логикой работы программной системы функции (обработка данных, их получение от сервера и представление клиенту) представляют собою «значимую» часть, которая требует интеллектуального труда разработчика. А весь программный код, связанный с обеспечением обмена данными сервера
Конечно, сервер БД — это программа, и как всякая программа она создается с использованием соответствующего компилятора; но в этом случае речь уже не идет о создании части трехуровневого приложения — здесь сервер БД выступает как отдельное законченное приложение.
приложений и клиентской части, как правило, требует кропотливого рутинног: труда, который может быть автоматизирован.
На этот факт обратили внимание производители систем программирования, и сейчас на рынке средств разработки программного обеспечения появились программ.• ные продукты, часто носящие название «сервер приложений». Эти продукты о. частую входят в состав соответствующих систем программирования, но мог. поставляться и отдельно от них. Такой сервер приложений представляет собс,. своеобразный контейнер, обеспечивающий разработчику взаимодействие с клиентской частью и с сервером данных по определенному стандарту, а также обле чающий написание программного кода, реализующего логику обработки данны.. От разработчика требуется только создать код, отвечающий за саму обработку,- все остальное большей частью обеспечит сервер приложений. Единственнь- ограничением при таком способе создания программного обеспечения для тре уровневой архитектуры является тот факт, что созданный таким образом полномасштабный сервер приложений должен поставляться заказчику в комплекте с программным кодом сервера приложений из состава системы программирования, а это чаще всего требует приобретения дополнительных лицензий от производителя системы программирования. Однако при таком пути достигается существенный выигрыш в объеме трудозатрат на разработку сервера приложений. Хорошим примером такого рода сервера приложений может служить программный продукт Borland Enterprise Server (первоначально носивший название Borlanc Application Server) от известного производителя систем программирования — компании Borland (Inprise)[59].
Возможности многоуровневой архитектуры
По сравнению с архитектурой «клиент-сервер» трехуровневая архитектура предоставляет разработчику программного обеспечения следующие преимущества: 口 функции обработки данных возложены на сервер приложений, а на клиентскую часть приходятся только функции отображения данных и организации интерфейса пользователя, что существенно снижает требования к аппаратнопрограммному обеспечению клиентской части программного обеспечения;
при необходимости изменить или дополнить логику обработки данных достаточно модифицировать только программное обеспечение на сервере приложений, а обновление клиентских приложений на всех рабочих местах не обязательно;
если необходимо изменить только внешний вид интерфейса пользователя, тс достаточно только изменить простую по своей структуре клиентскую часть на тех рабочих местах, где это необходимо;
для подключения к серверу данных (который, как правило, поставляется сторонним разработчиком) можно ограничиться одной лицензией1.
Это не всегда справедливо, так как многие фирмы-производители СУБД учли это обстоятельство и требуют специальных лицензий при использовании их СУБД в трехуровневой архитектуре либо же рассчитывают стоимость лицензии исходя не из количеств, подключений, а из параметров архитектуры сервера данных.
Главным недостатком трехуровневой архитектуры следует признать довольно сложный и трудоемкий процесс организации взаимодействия между клиентами и сервером приложений. Именно по этой причине далеко не все современные программные системы, построенные на основе архитектуры «клиент-сервер», быстро переходят на трехуровневую архитектуру, поскольку выделить в составе программного комплекса сервер приложений, описать его функции и организовать взаимодействие клиентских частей с ним — это сложный процесс, требующий усилий от разработчиков. В том случае, если функциональность программного обеспечения, построенного на основе архитектуры «клиент-сервер», достаточно стабильна, а обработка данных не содержит сложных ресурсоемких операций, переход на трехуровневую архитектуру не всегда оправдан (следует признать, что развитие аппаратных средств также способствует этому, поскольку появляются достаточно мощные и недорогие рабочие станции).
Более подробно о разработке программного обеспечения на основе трехуровневой архйтектуры можно узнать в [24, 26, 27, 59, 60, 69].
Разработка программного обеспечения для сети Интернет
Интернет — это всемирная «сеть сетей». Он объединяет в себе вычислительные системы и локальные сети, построенные на базе различных аппаратно-программных архитектур. При осуществлении взаимодействия по сети двух компьютеров один из них выступает в качестве источника данных (интернет-сервера), а другой — приемника данных (интернет-клиента). Сервер подготавливает данные, а клиент принимает их и каким-то образом обрабатывает. Нередко в качестве данных выступают тексты программ, которые подготавливает сервер, а исполнять должен клиент.
В таких условиях определяющим становится требование унифицированного исполнения кода программ* вне зависимости от архитектуры вычислительной системы. Компиляция и создание объектного кода в условиях всемирной сети становятся бессмысленными, потому что заранее не известно, на какой вычислительной системе потребуется исполнять полученный в результате компиляции код.
Поэтому основной особенностью программирования в сети Интернет является использование в качестве основного средства программирования интерпретируемых языков. При интерпретации исполняется не объектный код, а сам исходный код программы, и уже непосредственно интерпретатор на стороне клиента отвечает за то, чтобы этот исходный код был исполнен всегда одним и тем же образом вне зависимости от архитектуры вычислительной системы. Тогда сервер готовит код программы вне зависимости от типа клиента.
В такой ситуации нагрузка на интернет-клиент может возрасти. Но задачу можно несколько упростить: интернет-сервер может готовить не высокоуровневый код исходной программы, а некий унифицированный промежуточный код низкого уровня, предназначенный для исполнения на стороне клиента. Тогда в обмене данным участвуют еще две дополнительных программы: компилятор (точнее —
транслятор) на стороне сервера, транслирующий исходный код программы 广 некотором языке высокого уровня в промежуточный низкоуровневый код, и иь терпретатор на стороне клиента, отвечающий за исполнение промежуточногс кода вне зависимости от архитектуры вычислительной системы клиента.
Для реализации такого рода схем существует много технических и Языковы средств. Существует также значительное количество языков программирование ориентированных на использование в глобальной сети [56, 62, 63, 64]. Интернет- программирование — это отдельная и довольно интересная область разработкг программ, но в целом вопросы, затрагиваемые в ней, лежат за пределами темь, данного учебника. Далее дается только очень краткий обзор принципов, положенных в основу тех или иных языков программирования в глобальной сети.
Язык HTML. Программирование статических веб-страниц
Язык HTML (HyperText Markup Language, язык разметки гипертекста) во многом определил развитие и широкое распространение сети Интернет по всему миру. Сам по себе язык достаточно прост, а для овладения им нужны только самые примитивные знания в области программирования.
Язык позволяет описывать структурированный текст (гипертекст), содержащий ссылки и взаимосвязи фрагментов; графические элементы (изображения), которые могут быть связаны как с текстовой информацией, так л между собой; а также простейшие элементы графического интерфейса пользователя (кнопки, списки, поля редактирования). На основе описания, построенного в текстовом виде на HTML, эти элементы могут располагаться на экране, им могут присваиваться различные атрибуты, определяющие используемые ресурсы интерфейса пользователя (такие, как цвет, шрифты, размер и т. п.). В результате получается графический образ — веб-страница (от «web» — «паутина» — слова, входящего в состав аббревиатуры WWW — World Wide Web — Всемирная паутина). Она, в принципе, может содержать различные мультимедийные элементы, включая графику, видео и анимацию.
Широкому распространению HTML послужил принцип, на основе которого этот язык стал использоваться в глобальной сети. Суть его достаточно проста: интернет-сервер создает текст на языке HTML и передает его в виде текстового файла на клиентскую сторону сети по специальному протоколу обмена данными HTTP (HyperText Transfer Protocol, протокол передачи гипертекста). Клиент, получая исходный текст на языке HTML, интерпретирует его и в соответствии с результатом интерпретации строит соответствующие интерфейсные формы и изображения на экране клиентской ЭВМ.
Грамматика HTML проста, а потому не составляет сложности построить соответствующий интерпретатор. Такими интерпретаторами явились программы-навигаторы в сети Интернет (браузеры, browser), которые, по сути, должны были содержать, как минимум, две составляющих: клиентскую часть для обмена данными по протоколу HTTP и интерпретатор языка HTML. Некоторое время на рынке существовало огромное количество такого рода программ, в настоящее
время преобладают две — Internet Explorer (производства компании Microsoft) и Netscape Navigator (производства компании Netscape). Первая из них доминирует на архитектуре персональных компьютеров на базе процессоров типа Intel 80x86 под управлением ОС типа Microsoft Windows.
Гораздо разнообразнее программное обеспечение серверной части. Это вызвано тем, что в протоколе HTTP нигде строго не специфицирован источник HTML- текста. Им может быть обычный текстовый файл, и тогда клиент будет видеть у себя статическую картинку всякий раз, когда устанавливает соединение с данным сервером. Но может быть и так, что сервер будет порождать новый HTML- текст всякий раз, когда клиент устанавливает с ним соединение, или даже менять текст по мере работы клиента с сервером. Тогда и изображение на стороне клиента, зависящее от интерпретируемого текста HTML, будет динамически изменяться по мере изменения текста. Последний вариант представляет гораздо больший интерес с точки зрения предоставляемых возможностей. Вопрос только в том как организовать динамическое изменение HTML-текста. Вот в этом направлении и шло развитие основных средств интернет-программирования.
Описание языка HTML можно найти на многих сайтах в глобальной сети, а также в многочисленной литературе по интернет-программированию (например, в [56]). Язык HTML прост и поэтому удобен. Однако отсюда же проистекают и основные его недостатки. Во-первых, он не предоставляет средств динамического изменения содержимого интерфейсных форм и изображений, поэтому основной метод — динамическое изменение самого текста HTML. Во-вторых, данный язык не предоставляет никаких методов поддержки современных архитектур типа «клиент- сервер» или трехуровневой архитектуры. Он не позволяет обмениваться данными ни с серверами БД, ни с серверами приложений как на стороне сервера, где готовятся тексты HTML, так и на стороне клиента, где эти тексты интерпретируются. Наконец, этот язык имеет очень ограниченные средства для реакции на действия пользователя в интерфейсных формах, созданных с его помощью.
Для устранения этих недостатков были предложены различные средства. Некоторые из них рассмотрены ниже. -
Программирование динамических веб-страниц
Основная идея динамической генерации веб-страниц заключается в том, что большая часть НТМ L-страницы не хранится в файле на сервере, а порождается непосредственно каждый раз при обращении клиента к серверу. Тогда сервер формирует страницу и сразу же по готовности передает ее клиенту. Таким образом, всякий раз при новом обращении клиент получает новый текст HTML, и не исключено, что тексты могут значительно различаться между собой даже при обращении к одному и тому же серверу.
Вопрос только в том, как обеспечить динамическую генерацию HTML-кода на стороне сервера.
Самое очевидное решение заключается в том, чтобы разработать некоторый исполняемый файл (приложение), который будет динамически строить новый HTML-код. Тогда на вход такого исполняемого файла поступают некоторые па-
раметры (например данные, которые пользователь ввел в форме или командной строке), а на выходе он должен порождать HTML-код в виде текста. Для этой цели служат специальные приложения, называемые CGI-приложениями.
CGI (Common Gateway Interface, общедоступный шлюзовой интерфейс) — это интерфейс для запуска внешних программ на сервере в ответ на действия клиента, установившего соединение с ним через глобальную сеть. Пользуясь этим интерфейсом, приложения могут получать информацию от удаленного пользователя, анализировать ее, формировать HTML-код и отсылать его клиенту. CGI-приложения могут получать данные из заполненной формы, построенной с помощью HTML, либо из командной строки описания URL (Universal Resource Locator, универсальный указатель ресурса). Строка URL вводится в программе-навигаторе, осуществляющей доступ к серверу со стороны клиента. То, какие CGI-приложения по каким действиям пользователя должны выполняться на сервере, указывается непосредственно в коде НТМL-страницы, которую сервер передает клиенту.
Кроме интерфейса CGI существуют и другие варианты интерфейсов, позволяющие динамически создавать HTML-код путем запуска на сервере приложений в ответ на действия клиента. Например, можно выделить интерфейс ISAPI (Internet Server Application Programming Interface, интерфейс прикладных программ ин- тернет-сервера). Отличие ISAPI от CGI заключается в том, что для поддержки CGI создаются отдельные приложения, выполняющиеся в виде самостоятельных программ, a ISAPI поддерживается с помощью библиотек, динамически подключаемых к серверу. ISAPI-библиотеки исполняются непосредственно в адресном пространстве сервера, имеют большие возможности и обеспечивают более высокую производительность сервера, в то время как CGI-приложения исполняются в ОС сервера как отдельные процессы и вынуждены определенным образом организовывать обмен данными с самим сервером (что снижает производительность). Но, с другой стороны, ошибка в библиотеке ISAPI может привести к выходу всего сервера из строя и его длительной неработоспособности. В то же время ошибка в коде CGI-приложения может в худшем случае привести только к аварийному завершению выполнения этого приложения, а сам сервер при этом сохранит работоспособность. Тогда в результате ошибки будет неверно отображена только какая-то одна HTML-страница либо часть страницы, а все остальные части сервера будут продолжать исправно работать.
Современные системы программирования, в том числе и те из них, что были рассмотрены в качестве примеров в данной книге, позволяют создавать приложения и библиотеки, рассчитанные на работу в глобальной сети в соответствии со стандартом CGI или ISAPI. При этом создание исходного кода приложения практически ничем не отличается от создания обычной исполняемой программы: компилятор по-прежнему порождает объектные файлы, но компоновщик собирает исполняемый файл или библиотеку с учетом того, что они будут исполняться в архитектуре сервера глобальной сети. Функции загрузчика выполняет ОС по команде сервера либо сам интернет-сервер.
Этот метод удобен, но имеет один серьезный недостаток: при изменении содержимого динамической HTML-страницы или же при изменении логики ее реакции на действия интернет-клиента требуется создать новый код CGI или ISAPI-
приложения. А для этого нужно выполнить полностью весь цикл построения результирующей программы, начиная от изменения исходного кода, включая компиляцию и компоновку. Поскольку содержимое веб-страниц меняется довольно часто (в отличие от обычных программ), то такой подход нельзя признать очень эффективным. Кроме того, может потребоваться перенос интернет-сервера с одной архитектуры вычислительной системы на другую, а это также потребует перестройки всех используемых CGI-приложений и ISAPI-библиотек, кроме того, они в этом случае должны удовлетворять всем требованиям переносимости программного обеспечения.
Лучших результатов можно добиться, если не выполнять на сервере уже скомпилированный и готовый объектный код, а интерпретировать код программы, написанной на некотором языке. При интерпретации исходного кода сервер, конечно, будет иметь производительность Ниже, чем при исполнении готового объектного кода, но этим можно пренебречь, поскольку производительность серверов Интернета ограничивает чаще всего не мощность вычислительной системы, а пропускная способность канала обмена данными. Тогда зависимость кода сервера от архитектуры вычислительной системы будет минимальной, а изменить содержимое порождаемой НТМL-страницы можно будет сразу же, как только будет изменен порождающий ее исходный код (без дополнительной перекомпиляции).
Существует несколько языков и соответствующих им интерпретаторов, которые нашли применение в этой области и успешно служат цели порождения HTML- страниц. Среди них можно назвать язык Perl; язык, лежащий в основе различных версий веб-технологии, PHP (Personal Home Pages); а также язык сценариев, на котором основана веб-технология, ASP (Active Server Pages) — последний предложен и поддерживается известным производителем программного обеспечения —фирмой Microsoft.
Текст на интерпретируемых языках, которые поддерживаются такими веб-технологиями, как ASP или PHP, представляет собой часть текста обычных HTML- страниц со встроенными в них сценариями (script). Эти сценарии можно писать на любом языке, поддерживаемом сервером. Интернет-сервер обрабатывает их при поступлении запроса об URL-адресе соответствующего файла. Он разбирает текст HTML-страницы, находит в нем тексты сценариев, вырезает их и интерпретирует в соответствии с синтаксисом и семантикой данного языка. В результате интерпретации получается выходной текст на языке HTML, который сервер вставляет непосредственно в то место исходной страницы, где встретился сценарий. Так обрабатывается динамическая веб-страница на любом интерпретируемом языке, ориентированном на работу в глобальной сети. Естественно, для работы со страницей сервер должен иметь в своем составе интерпретатор соответствующего языка.
Все эти языки сценариев обладают присущими им характерными особенностями. Во-первых, они имеют мощные встроенные функции и средства для работы со строками, поскольку основной задачей программ, написанных с помощью таких языков, является обработка входных параметров (строковых) и порождение HTML-кода (который также является текстом). Во-вторых, все они имеют средства для работы в архитектуре «клиент-сервер» для обмена информацией
с серверами БД, а многие современные версии таких языков (например, язык, поддерживаемый веб-технологией ASP) — средства для функционирования в трехуровневой архитектуре для обмена данными с серверами приложений.
Недостаток всех перечисленных методов заключается в том, что сначала сервер вынужден строить HTML-описание, собирая его некоторым образом из каких-тс своих данных, а затем интернет-клиент на своей стороне разбирает (интерпретирует) полученное описание HTML-страницы. Таким образом, выполняется как бы двойная работа по генерации, а затем интерпретации текстов языка HTML Кроме того, между клиентом и сервером по сети передаются довольно громоздкие описания HTML-страниц, что может значительно увеличивать трафик сети. Тем не менее, несмотря на недостатки, данные методы довольно распространены в глобальной сети, поскольку они очень просты, а кроме того, не требуют от клиентского компьютера ничего, кроме способности интерпретировать тексты HTML. Эта особенность довольно существенна.
Есть и другие варианты генерации динамических HTML-страниц. Рассмотренные далее методы, хотя и снижают нагрузку на сеть, но предъявляют определенные требования к клиентской части, что не всегда приемлемо.
Информацию по перечисленным выше языкам, поддерживающим такие методы, можно найти в соответствующей технической литературе (она частично имеется в [14, 56]), но лучше обратиться на соответствующие сайты во всемирной сети [63, 64].
Языки программирования Java и Java Script
Язык Java был разработан компанией Sun в качестве средства веб-программирования. Этот язык, в отличие от языка описания гипертекста HTML, является полноценным языком программирования. Он содержит в себе все основные операторы, конструкции и структуры данных, присущие языкам программирования. Синтаксические конструкции и семантика языка Java большей частью были заимствованы из языков программирования С и C++.
Основная идея, отличающая язык Java от многих других языков программирования, не ориентированных на применение в глобальной сети, заключается в том. что Java не является полностью компилируемым языком. Исходная программа, созданная на языке Java, не преобразуется в машинные коды. Компилятор языка порождает некую промежуточную результирующую программу на специальном низкоуровневом двоичном коде (эта результирующая программа называется Java-апплетом, а код, на котором она строится, — Java байт-кодом). Именно этот код интерпретируется при исполнении результирующей Java-программы. Такой метод исполнения кода, основанный на интерпретации, делает его практически независимым от архитектуры целевой вычислительной системы.
Таким образом, для исполнения Java-программы необходимы две составляющих: компилятор промежуточного двоичного кода, порождающий его из исходного текста Java-программы, и интерпретатор, исполняющий этот промежуточный двоичный код. Такой интерпретатор получил название виртуальной Java-маши-
ны. Описание основных особенностей реализации виртуальной Java-машины (интерпретатора промежуточного низкоуровневого кода) с точки зрения системы программирования описаны в [7, 62].
Одной из отличительных особенностей данного языка является использование специального механизма распределения памяти (менеджера памяти). В языке Java не могут быть использованы функции динамического распределения памяти по запросам пользователя и связанные с ними операции над адресами и указателями, поскольку они зависят от архитектуры вычислительной системы. Динамическая память в языке может выделяться только системой программирования под классы и объекты самого языка. Для этого менеджер памяти должен сам организовывать своевременное выделение областей памяти при создании новых классов и объектов, а затем освобождать области памяти, которые уже больше не используются. В последнем случае должна решаться непростая задача «сборки мусора» — поиска неиспользуемых фрагментов в памяти и их освобождение. Причем, поскольку в языке Java за распределение памяти отвечает не пользователь, а интерпретатор кода, эти задачи должны решаться независимо от хода выполнения самой Java-программы.
Менеджер памяти входит в состав виртуальной Java-машины и, безусловно, зависит от архитектуры вычислительной системы, где функционирует эта машина, но интерпретируемые ею программы при этом остаются независимыми от архитектуры. Хороший менеджер памяти — важная составляющая виртуальной Java- машины наряду с быстродействующим интерпретатором промежуточного низкоуровневого кода.
При выполнении Java-программы в глобальной сети компилятор, порождающий промежуточный низкоуровневый код, находится на стороне сервера, а интерпретатор, выполняющий этот код, — на стороне клиента. По сети от сервера к клиенту передается только скомпилированный код. С этой точки зрения использование языка Java для исполнения программ в сети дает преимущества по сравнению с использованием других языков, выполняемых на стороне сервера, как описано выше. Преимущество заключается в том, что по сети не надо передавать громоздкие HTML-описания страниц или тексты команд и программ сценариев (script), что значительно снижает трафик в сети, а на стороне клиента не надо распознавать эти команды и программы.
Кроме того, язык Java является лучшим средством для написания мобильного программного обеспечения, которое будет выполняться на вычислительной системе в любой архитектуре, вне зависимости от типа аппаратных средств и ОС. Достаточно иметь Java-машину, обеспечивающую интерпретацию Java байт-кода в данной вычислительной архитектуре для данного типа ОС.
Однако отсюда проистекают и основные недостатки, присущие языку Java. Главный из них заключается в том, что на клиентской стороне должна присутствовать виртуальная Java-машина для интерпретации поступающего из сети кода. Это значит, что так или иначе интерпретатор языка Java должен входить в состав архитектуры целевой вычислительной системы, а без его наличия функционирование такой схемы становится невозможным. Кроме того, промежуточный код
языка исполняется на стороне клиента, а значит, скорость его выполнения и возможности Java-программы во многом зависят от производительности клиентского компьютера, которая может оказаться недостаточно высокой у машины, ориентированной только на подключение к глобальной сети. Речь идет не только о скорости интерпретации команд, но и о том, что клиентская система должна быть способна работать со всеми базовыми классами, присущими языку Java.
Еще одна особенность связана с необходимостью обеспечения безопасности при исполнении Java-программ. Поскольку код исполняемой программы поступает из глобальной сети, то нет никакой гарантии, что этот код не содержит фатальную ошибку. Кроме того, такой код может быть преднамеренно создан со злым умыслом. Имея все возможности языка программирования (в отличие от текста HTML) и исполняясь в среде вычислительной системы клиента, он может привести к выходу из строя этой системы или к повреждению хранящихся в ней данных. Потому при построении интерпретатора виртуальной Java-машины нужно целенаправленно выделять и отслеживать потенциально опасные команды (такие, как выполнение программ или обращение к файлам на клиентской машине). Несмотря на то что большинство производителей виртуальных Java-машин считаются с этим правилом, проблема безопасности остается актуальной при использовании языка Java.
Язык Java быстро завоевал популярность и занял значительное место на рынке языков программирования и связанных с ними средств разработки. По сути, этот язык явился первой удачной реализацией двухэтапной модели выполнения программ, построенной на использовании компилятора промежуточного кода с последующей интерпретацией полученного кода. Независимость выполнения Java-программ от архитектуры целевой вычислительной системы способствовала росту популярности языка.
Росту популярности языка программирования Java и построенных на его основе систем программирования способствовал также тот факт, что в его состав входят встроенные средства поддержки интерфейса с серверами БД, ориентированные на разработку приложений, выполняющихся в архитектуре «клиент-сервер». Системы программирования языка Java совместимы также с известной группой стандартов, ориентированной на разработку результирующих программ, выполняющихся в трехуровневой архитектуре — CORBA.
Первоначально язык поддерживался только одним разработчиком — компанией Sun. Но со временем и с ростом популярности языка в его поддержку стали включаться и другие известные компании-производители программных продуктов. Среди них можно выделить уже упоминавшуюся в данном пособии компанию Borland, создавшую на базе языка Java систему программирования Borland JBuilder, а также сервер приложений Borland Enterprise Server (первоначально — Borland Application Server), ориентированный на выполнение Java-программ в трехуровневой архитектуре программного обеспечения. В настоящее время компании, поддерживающие системы программирования на основе языка Java, образуют специальное сообщество для поддержки и распространения средств разработки на основе данного языка. Всю необходимую информацию можно по-
лучить на сайте [62] и во многих других местах всемирной сети Интернет, которая во многом способствовала развитию этого языка1.
Основной проблемой языка Java остается его производительность. При прочих равных условиях интерпретируемая программа, построенная на основе системы программирования для Java, будет уступать в скорости откомпилированной программе, созданной в любой другой современной системе программирования. Поэтому язык Java практически не применяется в программах реального времени, а также в программах, требующих сложных расчетов. Но во многих прикладных программах, где производительность не имеет столь принципиального значения, он вполне может быть использован, так как дает преимущества в независимости результирующей программы от архитектуры целевой вычислительной системы. Большинство современных ОС допускают наличие в своем составе виртуальных Java-машин для интерпретации результирующего кода Java-программ.
Необходимость иметь в составе архитектуры вычислительной системы клиентского компьютера виртуальную Java-машину, а также довольно высокие требования к производительности компьютеров на клиентской стороне в ряде случаев ограничивают возможности применения языка Java. С другой стороны, зачастую для организации динамической веб-страницы достаточно лишь выполнить ряд простых действий, не укладывающихся в рамки статического HTML. Для этого нет необходимости создавать, компилировать и передавать по сети полноценную Java-программу.
Чтобы решить эти проблемы, был предложен командный язык Java Script, который можно назвать упрощенным вариантом языка Java.
Фрагменты кода, написанные на Java Script, передаются непосредственно внутри текста HTML-страниц. Синтаксис и семантика Java Script в целом соответствуют языку Java, но возможности его выполнения сильно ограничены — они не выходят за рамки той программы, которая интерпретирует HTML-страницу. В таком случае эта программа выступает и в роли виртуальной Java-машины для выполнения операторов Java Script. Чаще всего это программа навигации по сети — браузер. Он находит в тексте HTML-страницы операторы языка Java Script, выделяет их и исполняет по всем правилам языка Java. Однако выполнение Java Script происходит только в рамках адресного пространства программы-навигатора. Это, с одной стороны, ограничивает его возможности, но, с другой стороны, увеличивает безопасность выполнения операторов, так как в худшем случае при наличии некорректных операторов языка неработоспособной окажется только запущенная программа-навигатор, но не вся клиентская система в целом.
Известная компания-производитель ОС и систем программирования — Microsoft — некоторое время тоже способствовала распространению языка Java и занималась его поддержкой. Однако затем, к сожалению, по причинам маркетинговых и других разногласий с компанией Sun отказалась от использования данного средства разработки. Многие идеи, первоначально заложенные в Java, нашли свою реализацию в языке C# (Си-шарп), предложенном этой компанией и продвигаемым ею в настоящее время на рынок средств разработки.
Операторы Java Script сейчас широко используются для организации динамических веб-страниц. Их выполнение (интерпретация) обеспечивается всеми современными программами-навигаторами в глобальной сети. Более подробную информацию о языке Java Script и его возможностях можно найти в [7] или на многих сайтах, посвященных языку Java [62].
Контрольные вопросы и задачи
Вопросы.
Почему различные функции, выполняемые программными модулями в составе системы программирования, разнесены по различным модулям, а не включены в состав компилятора? Какие для этого есть исторические и технические причины?
Используя схему, приведенную в данном учебном пособии, объясните функционирование системы программирования на различных этапах развития: Q в виде комплекса программных модулей, выполняемых по командам Makefile; Q в виде единой интегрированной среды разработки;
Q в виде единой интегрированной среды разработки, объединенной со средствами проектирования программного обеспечения.
Каким целям служит командный файл Makefile? В чем его отличие от обычных командных файлов? В каких случаях в настоящее время продолжают использоваться средства разработки на основе Makefile?
Что такое Application Program Interface (API)? Какие задачи решаются в прикладных программах с помощью API? Какие средства реализации API существуют? (При необходимости обратитесь к первой части данного учебника.)
Что такое ресурсы прикладной программы? Относятся ли к понятию ресурсов прикладной программы следующие типы данных:
Q текст сообщения, выдаваемого программой при возникновении ошибки;
Q тексты пунктов главного меню программы;
Q файлы, обрабатываемые прикладной программой;
Q цвет фона главного окна программы;
Q структурьГ данных, используемые программой в процессе работы;
Q файл подсказки, выдаваемой программой по запросу пользователя?
В каких случаях на современном рынке программных средств встречаются компиляторы и интерпретаторы, не входящие в состав систем программирования? Приведите примеры.
Если в процессе создания современной системы программирования встанет вопрос о разработке более эффективного компилятора либо о развитии сервисных средств и интерфейса пользователя, то какому направлению будет отдано предпочтение? Почему?
Какие специфические функции выполняет текстовый редактор в составе системы программирования? Как он должен быть взаимосвязан с другими модулями системы?
В чем особенности функционирования компилятора в составе системы программирования по сравнению с его функционированием в виде отдельного программного модуля?
Почему компоновщик носит также название «редактор связей»? В чем заключается процедура разрешения внешних ссылок объектного файла?
И. В современных системах программирования загрузчик, как правило, отсутствует. Его функции выполняет ОС. Расскажите, как эти функции выполняются в различных ОС (при необходимости обратитесь к первой части данного учебника). Какую информацию должна получить ОС от системы программирования для выполнения загрузки исполняемого файла программы?
Современные отладчики используют средства ОС и возможности архитектуры целевой вычислительной системы для отладки прикладных программ. Из материала первой части данного учебника вспомните, какие средства отладки существуют.
Если система программирования выполняет отладку результирующей программы путем моделирования архитектуры целевой вычислительной системы, то чем ограничены возможности такого отладчика? Чем отличается такое выполнение программы от работы интерпретатора?
В чем преимущества и недостатки динамически загружаемых библиотек по сравнению с обычными (статически подключаемыми) библиотеками? Если подключение к результирующей программе статической библиотеки выполняет компоновщик, то какая часть системы программирования или ОС ответственна за подключение динамически загружаемой библиотеки?
Как вызов функции динамически загружаемой библиотеки обрабатывается компилятором? Какие действия выполняет в этом случае компоновщик? Должна ли динамически загружаемая библиотека быть доступна системе программирования в момент компоновки результирующей программы?
Какие дополнительные возможности предоставляет пользователю лексический анализ исходного текста программы «на лету»? Как влияет реализация такого лексического анализа в системе программирования на эффективность работы компилятора, на количество проходов, выполняемых компилятором?
Какие преимущества имеет приложение (результирующая программа), функционирующее в составе архитектуры «клиент-сервер» по сравнению с обычным приложением? Какие дополнительные требования предъявляет такое приложение к вычислительным ресурсам? Какие требования предъявляются к системе программирования, позволяющей создавать приложения, функционирующие в составе архитектуры «клиент-сервер»?
Клиентскую часть приложения, функционирующего в составе архитектуры «клиент-сервер», часто называют «толстым клиентом». Сравните функции и характеристики «толстого клиента» в архитектуре «клиент-сервер» с функциями и характеристиками «тонкого клиента» в трехуровневой архитектуре. В чем их принципиальное различие?
Почему требования к вычислительным ресурсам у «тонкого клиента», как правило, ниже, чем у «толстого клиента»?
Сравните функции сервера приложений и сервера данных. В чем различие между ними?
Какие основные особенности определили успех и долгое существование системы программирования Turbo Pascal производства компании Borland на российском рынке средств разработки? В чем вы видите недостатки этой системы?
Сравните между собой системы программирования Borland Delphi и Borland C++ Builder. В чем преимущества и недостатки каждой из этих систем?
Какие особенности систем программирования компании Microsoft позволили им, на ваш взгляд, завоевать свое место на рынке средств разработки?
Сравните между собой системы программирования Microsoft Visual Basic и Microsoft Visual C++. В чем преимущества и недостатки каждой из этих систем? Есть ли у каждой из них характерные черты, общие с системами программирования производства компании Borland?
В чем сходство и в чем различие принципов распространения прикладного программного обеспечения, созданного для ОС типа UNIX и для ОС Linux проекта GNU? Почему системы программирования (и прежде всего, системы программирования для языков С и C++) являются неотъемлемой частью этих ОС?
В чем заключаются основные особенности разработки программного обеспечения для глобальной сети Интернет? Почему в этой сети часто используются интерпретируемые языки?
В чем принципиальная разница функционирования динамических веб-страниц, организованных с помощью программного обеспечения на основе интерфейса CGI (или ISAPI), и динамических веб-страниц, построенных на основе интерпретируемых языков сценариев типа Perl, веб-технологий PHP или ASP?
В чем принципиальная разница функционирования динамических веб-страниц, организованных с помощью программного обеспечения на основе интерфейса CGI (или ISAPI), и динамических веб-страниц, построенных с использованием JavaScript? В чем принципиальная разница выполнения команд на языке JavaScript и команд на языках сценариев, поддерживаемых веб-технологиями PHP и ASP?
Задачи
Функция F1 содержится в библиотеке, построенной с помощью компилятора в некоторой системе программирования. При попытке использовать эту функцию при построении исполняемого файла в другой системе программирования компоновщик выдает сообщение об ошибке вида «функция F1 не найдена». Какова может быть причина появления такого рода ошибки? Что следует предпринять разработчику программы?
?. Функция F1 содержится в библиотеке, построенной с помощью компилятора в некоторой системе программирования. Функция F1 отлажена и проверена, однако при использовании ее в исполняемом файле, созданном в другой системе программирования, возникает ошибка, связанная с защитой памяти. Результирующая программа не может выполняться корректно. Какова может быть причина появления такого рода ошибки? Что следует предпринять разработчику программы?
L Функция F1 является виртуальной функцией некоторого класса С1. На основе одного и того же исходного кода в одной системе программирования построены динамически загружаемая библиотека и исполняемый файл. Исполняемый файл создает экземпляр класса С1 и передает его в качестве параметра в динамически загружаемую библиотеку, где вызывается функция F1. Приведет ли такая схема к возникновению ошибок во время выполнения программы? Если ошибки возможны, то что следует предпринять разработчику программы? Как изменится ситуация, если предположить, что для создания исполняемого модуля и динамически загружаемой библиотеки использовался один и тот же исходный код, но разные системы программирования?
L Имеется класс С1. На основе одного и того же исходного кода в одной системе программирования построены динамически загружаемая библиотека и исполняемый файл. Исполняемый файл создает экземпляр класса С1 и передает его в качестве параметра в динамически загружаемую библиотеку. Динамически загружаемая библиотека проверяет экземпляр класса на принадлежность к типу С1. Приведет ли такая схема к возникновению ошибок во время выполнения программы? Если ошибки возможны, то что следует предпринять разработчику программы?
Указатель литературы
Абрамова Н. Л. и др. Новый математический аппарат для анализа внешнего поведения и верификации программ — М.: Институт проблем управления РАН, 1998. - 109 с.
Архангельский А Я. и др. Русская справка (HELP) по Delphi 5 и Object Pascal - М.: БИНОМ, 2000. - 32 с.
Афанасьев А. Н. Формальные языки и грамматики: Учебное пособие — Ульяновск: УлГТУ, 1997. — 84 с.
Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции —М.: Мир, 1978. — т. 1, 612 с. — т. 2, 487 с.
Бартеньев О. В. Фортран для студентов — М.: Диалог-МИФИ, 1999. — 342 с.
Березин Б. И., Березин С Б. Начальный курс С и C++ — М.: Диалог-МИФИ, 1996. — 288 с.
Бранденбау Дж. JavaScript: Сборник рецептов для профессионалов — СПб.: Питер, 2000. — 416 с.
Браун С. Операционная система UNIX — М.: Мир, 1986. — 463 с.
Бржезовский Л. В” Корсакова Н. В., Фильчаков В. В. Лексический и синтаксический анализ. Формальные языки и грамматики — Л.: ЛИАП, 1990. — 31 с.
Бржезовский А. В., Фильчаков В. В. Концептуальный анализ вычислительных систем — СПб.: ЛИАП, 1991. — 78 с.
И. Вендров А. М. С AS Е -технологии. Современные методы и средства проектирования информационных систем — М.: Финансы и статистика, 1998. — 176 с.
Вирт Н. Алгоритмы и структуры данных — М.: Мир, 1989. — 360 с.
Волкова И. А., Руденко Т. В. Формальные языки и грамматики. Элементы теории трансляции — М.: Диалог-МГУ, 1999. — 62 с.
Гончаров А. Самоучитель HTML — СПб.: Питер, 2000. — 240 с.
Гордеев А. В., Молчанов А. Ю. Системное программное обеспечение — СПб.: Питер, 2002. — 734 с.
Гордеев А. В., Решетникова Н. Н., Соловьев А. П. Дисковая операционная система реального времени — СПб.: ГААП, 1994. — 44 с.
Грис Д. Конструирование компиляторов для цифровых вычислительных машин —М.: Мир, 1975. — 544 с.
Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ —М.: Мир, 1985. — 332 с.
Дворянкин А. И. Основы трансляции: Учебное пособие — Волгоград: ВолгГТУ, 1999. — 80 с.
Дунаев С. UNIX System V. Release 4.2: Общее руководство — М.: Диалог-МИФИ, 1995. - 287 с.
Евстигнеев В. А., Мирзуитова И. П. Анализ циклов: выбор кандидатов на распараллеливание —Новосибирск: Ин-т систем информатики, 1999. — 48 с.
Жаков В. И” Коровинский В. В., Фильчаков В. В. Синтаксический анализ и генерация кода — СПб.: Г А АП, 1993. — 26 с.
Жаков В. И., Корсакова Н. В., Никитин А В., Фильчаков В. В. Структуры данных: Учебное пособие — Л.: ЛИАП, 1989. — 76 с.
Калверт Ч. Delphi 4. Энциклопедия пользователя — Киев: ДиаСофт, 1998.
Карпов Б. И. Delphi: Специальный справочник — СПб.: Питер, 2001 — 684 с.
Карпов Б. И. Visual Basic 6: Специальный справочник — СПб.: Питер, 2000.— 415 с.
Карпов Б. И., Баранова Т. К. C++: Специальный справочник — СПб.: Питер, 2002. - 480 с.
Карпов Ю. Г. Теория автоматов: Учебник для вузов — СПб.: Питер, 2003.— 208 с..
Керниган Б., Пайк Р. UNIX — универсальная среда программирования — М.: Финансы и статистика, 1992. — 420 с.
Кисилев С. Ю. Технология разработки программного обеспечения информационных систем — СПб.: СПбГУАП, 1998. — 102 с.
Клочка В. И. Теория вычислительных процессов и структур: Учебное пособие —Краснодар: КубГТУ, 1999. — 118 с.
Компаниец Р. И., Маньков Е. В., Филатов Н. Е. Системное программирование. Основы построения трансляторов: Учебное пособие для высших и средних учебных заведений — СПб.: КОРОНА-принт, 2000. — 256 с.
Концептуальное моделирование информационных систем/Под ред. В. В. Фильчакова —СПб.: СПВУРЭ ПВО, 1998. — 356 с.
Кэнту М. Delphi 5 для профессионалов. — СПб.: Питер, 2001.
Льюис Ф. и др. Теоретические основы построения компиляторов — М.: Мир, 1979. - 483 с.
Майерс Дж. Надежность программного обеспечения — М.: Мир, 1987. — 360 с.
Маклаков С В. BPWin и ERWin. CASE-средства разработки информационных систем — М.: Диалог-МИФИ, 2000. — 254 с.
Мельников Б.①.Подклассы класса контекстно-свободных языков — М.: МГУ, 1995. — 174 с.
Немюгин С., Перколаб Л. Изучаем Turbo Pascal — СПб.: Питер, 2000.
Непомнящий В. А., Рякин О. М. Прикладные методы верификации программ/ Под ред. Ершова А. П. — М.: Радио и связь, 1988. — 256 с.
Операционная система СМ ЭВМ РАФОС: Справочник/Под ред. Семика В. П.— М.: Финансы и статистика, 1984. — 207 с.
Павловская Г. А C/C++: Учебник. — СПб.: Питер, 2001.
Петруцос 3., Хау К. Visual Basic 6 и VBA — СПб.: Питер, 2000. — 425 с.
Полетаева И. Л. Методы трансляции: Конспект лекций — Новосибирск:'НГТУ, 1998. - ч. 2 - 51 с.
Пратт Г., Зелковиц М. Языки программирования: разработка и реализация — СПб: Питер, 2001.
Рассел ¥., Кроуфорд Ш. UNIX и Linux: книга ответов — СПб.: Питер, 1999.— 297 с.
Рогаткин Д., Федоров A. Borland Pascal в среде Windows — Киев: Диалектика, 1993. - 511 с.
Рейчард К, Фостер-Джонсон 3. UNIX: Справочник — СПб.: Питер, 2000.— 384 с.
Рудаков П. И., Федотов М. А. Основы языка Pascal: Учебный курс — М.: Радио и связь: Горячая линия — Телеком, 2000. — 205 с.
Серебряков В. И. Лекции по конструированию компиляторов — М.: МГУ, 1997. - 171 с.
Страуструп Б. Язык программирования Си++ — М.: Радио и связь, 1991.— 348 с.
Федоров В. В. Основы построения трансляторов: Учебное пособие — Обнинск: ИАТЭ, 1995. — 105 с.
Финогенов К. Г. Основы языка ассемблера — М.: Радио и связь, 1999. — 288 с.
Фомин В. А Математические основы разработки трансляторов: Учебное пособие -СПб.: ИПЦ СПГУВК, 1996. — 65 с.
Чернышов А. В. Инструментальные средства программирования из состава ОС UNIX и их применение в повседневной практике — М.: МГУП, 1999. — 191 с.
Шапошников И. В. Интернет-программирование — СПб.: БХВ — Санкт-Петербург, 2000. — 214 с.
Эпплман Д. Win32 API и Visual Basic. — СПб.: Питер, 2001.
Юров В. Assembler: Учебник — СПб.: Питер, 2000. — 622 с.
http://www.borland.ru/
http://www.corba.ru/
http://www.gnu.org/
http://java.sun.com/
http://www.perl.org/
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
http://www.php.net/
http://www.linux.zp.ua:8100/philosophy/philosophy.ru.html
http://www.microsoft.com/RUS/lnternet/intranets.html
http://www.microsoft.com/RUS/mssol99/prod/dev/vc.htm
http://www.microsoft.com/RUS/mssol99/prod/dev/vb.htmhttp://www.microsoft.com/rus/net/
http://www.astu.astranet.ru:8080/cfin/prcorpsys/infsistpr_04.shtml
http://tango.ce.cctpu.edu.ru/citprg/prg96/84.shtml.htm
http://www.nkfi.ru/doc/mirror/infocity/infocity.kiev.ua/db/content/db063.phtml-id=1486.htmhttp://www.javapower.ru/java/middleware.htm
http://sure.org.ru/docs/networks/netware/glava_12-1.shtml.htm
Алфавитный указатель
А
API (Application Program Interface), 332
Application server, 366
В
Browser, 366, 382
I
Internet, 69, 366, 374
Middleware, 366
RAD (Rapid Application Development), 334
Адрес
абсолютный, 259, 342
относительный, 259, 265, 341
Адрес возврата, 267, 268
Алгоритм
к-предсказывающий, 185
вычисления выражений в обратной
польской записи, 292
исключения лишних операций
для линейного участка, 310
лексического анализатора, 129
метода цепочек, 90
преобразования в обратную польскую
запись, 293
преобразования дерева операций
в объектный код, 296 преобразования дерева операций
в триады, 299
Алгоритм {продолжение)
размещения элемента
с рехэшированием, 86
распознавателя LL( 1 )-грамматик, 187
распознавателя ЬК(к)-грамматик, 201 рекурсивного спуска, 176, 178 с подбором альтернатив, 151, 166,
186
свертки объектного кода для линейного участка, 308
сдвиг-свертка, 151, 172, 173, 197, 200,
223, 231, 237, 240
устранения левой рекурсии, 160
Алфавит, 16, 19, 21, 28, 107, 114, 122,
125, 145
Алфавит магазинных символов, 145
Архитектура вычислительной
системы, 319, 345, 374
Архитектура «клиент-сервер», 357, 381
Архитектура трехуровневая, 366, 381
Ассемблер, 70, 303
Б
Базовый тип данных, 260
Библиотека
динамически загружаемая, 267, 275 подпрограмм и функций, 258, 281, 328,
333, 339, 345
динамически загружаемая, 280, 348 языка, 299, 346
Внутреннее представление программы, 58, 250, 252, 258, 281, 285, 288, 291, 303, 304, 308
Внутреннее представление программы {продолжение)
обратная польская запись, 68, 286,
292
тетрады, 285, 288, 289, 291
триады, 285, 290, 291, 299, 308, 310
Вызов inline-функции, 315
Генератор языка, 59
Генерация кода, 60, 77, 281, 284, 295,
301
Грамматика, 20, 46, 62, 282
арифметических выражений, 46, 48, 159, 167, 173, 181, 190, 214, 216, 222, 228, 238, 287, 294
двоичных чисел с плавающей
точкой, 124
контекстно-зависимая, 32, 39
контекстно-свободная, 33, 39, 40, 145
LALR(l), 217, 220, 221
LALR(k), 217
LL(1), 187, 191
LL(k), 185-187, 199
LR(0), 198, 202, 203, 208, 215, 216, 220
LR(1), 198, 202, 209, 213, 214, 216, 220
LR(k), 198, 199, 203, 234
SLR(l), 215,216,220
SLR(k), 214
без Х-правил, 156
леворекурсивная, 160, 161, 165 нелеворекурсивная, 160, 167 нормальная форма, 150 однозначная, 185, 200, 225, 235 операторная, 234
операторного предшествования, 224, 234, 238, 294
пополненная, 200, 208, 210 праворекурсивная, 160 преобразование, 153, 163 приведенная, 154
простого предшествования, 224
расширенного предшествования, 224 слабого предшествования, 224 смешанной стратегии
предшествования, 224 леволинейная, 34, 39, 103, 121, 122, 125, 129, 131
автоматная, 103, 125
Грамматика (продолжение) неоднозначная, 47, 50 неукорачивающая, 32, 40 однозначная, 47 . остовная, 241 праволинейная, 34, 39, 103, 121, 125 автоматная, 103
регулярная, 34, 39, 71, 99, 103, 104,
121, 124, 131, 145, 188
формальная, 20, 30, 32
целочисленных констант
для языка С, 130
целых десятичных чисел, 21, 22, 39, 42
языка программирования, 20
д
Дерево вывода, 44, 46, 169, 175, 185, 195,
199, 231, 233, 242, 243, 285, 286, 287
Дерево операций, 286, 288, 295, 298, 299
Дисплей памяти процедуры (функции), 267
стековая организация, 268, 269, 271, 274
ДМП-автомат, 148
Дополнение программы неявными
функциями, 250, 252
Ж
Жизненный цикл программного обеспечения, 327, 334
3
Заголовочные файлы, 346
Загрузчик, 328, 332, 334, 342
И
Идентификация лексических
элементов, 60, 72, 256, 257
Инвариантные операнды, 313
Индуктивная переменная, 317
Интегрированная среда разработки, 331, 335
Интернет-клиент, 374
Интернет-сервер, 374
Интерпретатор, 58, 67, 292, 374
Интерфейс пользователя, 331
графический, 331, 334
Информация о типах во время
выполнения, 279
Исключительная ситуация, 272
Исходная программа, 58, 67, 99, 144, 249,
279, 281, 284, 286, 301, 304
Итерация цепочки, 15, 114
Коллизия, 85, 90
Команда языка ассемблера, 70, 71
Командный язык Makefile, 329 Компилятор, 12, 31, 55, 58, 61, 66, 129,
249, 252, 253, 260, 265-267, 269, 271, 274, 277, 279-282, 284, 286, 291, 292, 299, 301-303, 307, 312, 313, 317-319, 321, 332, 333, 338
генерация предупреждений, 255, 284 двухпроходный, 62
многопроходный, 62
однопроходный, 62
ресурсов, 332, 333
с языка ассемблера, 70—72, 333
Компоновщик, 327, 332, 334, 339, 342, 347
Конечный автомат (КА), 38, 99, 102, 107,
124, 125, 129, 138
граф переходов, 10&； 127, 128
детерминированный, 109, 128, 131
полностью определенный, 131
минимизация, 112
недетерминированный, 109, 127
полностью определенный, 107
Конечный преобразователь, 102, 138 Конкатенация цепочек, 15, 114, 284, 295
Л
Лексема (лексическая единица), 18, 38,
96, 144, 249, 259, 263, 336
выделение границ, 99
Лексический анализ, 38, 60, 71, 77, 96, 98, 139, 257
«на лету», 337
параллельный, 100
последовательный, 100, 102
Лексический анализатор, 102, 129, 144
Линейный участок, 316
Линейный участок программы, 305
Лишняя операция, 307
м
Макрогенератор, 74
Макрогенерация, 73
Макрокоманда, 72—75
с параметрами, 75
Макроопределение, 73—75
с параметрами, 74
сложное, 75
Макроподстановка, 73
Макропроцессор, 74
Макрорасширение, 73
Матрица предшествования, 230, 234—
236, 239
Менеджер памяти, 266, 380
Метасимвол грамматики, 24, 181
Метод цепочек, 89
Мнемокод, 63, 70
Многоадресный код
с неявно именуемым результатом, 285, 289
с явно именуемым результатом, 285, 288 Множество
FIRST(l), 187, 189, 191, 210, 215
FIRST(k), 187, 215
FOLLOW(l), 187, 189, 192, 215
FOLLOW(k), 187,215
крайних левых символов, 226, 229,
236, 238
крайних левых терминальных символов, 235, 239
крайних правых символов, 226, 229,
238
крайних правых терминальных символов, 235, 239
МП-автомат, 37, 145, 162, 165, 249
детерминированный, 37, 148
недетерминированный, 162, 171
расширенный, 147, 170, 172, 223,
241
М П - преобразователь, 149
Область видимости, 257
Область памяти, 259
выравнивание- границ, 262
глобальная, 263, 268
динамическая, 259, 265, 268, 278
выделяемая компилятором, 266, 275, 276
выделяемая пользователем, 265
локальная, 263
статическая, 259, 265, 275
Обнаружение и локализация
ошибок, 58, 153, 284
Объектная программа, 281, 296, 302,
304, 316
Объектный код, 286, 291, 295, 298,
302, 306, 307, 312, 313, 321
Объектный файл, 328, 339, 345
Оптимизация кода, 60, 68, 72, 292, 298,
301, 302, 304
для вызовов процедур
и функций, 305, 314
для линейных участков программы, 305 арифметические
преобразования, 307
исключение лишних операций, 306
перестановка операций, 307
свертка объектного кода, 307, 308
удаление бесполезных присваиваний, 306
для циклов
замена операций с индуктивными переменными, 316
для логических выражений, 305, 312
для параллельного выполнения
операций, 320
для циклов, 305, 316
вынесение инвариантных вычислений, 316
замена операций с индуктивными переменными, 317
слияние и развертывание
циклов, 316, 318
критерии оптимизации, 302
машинно-зависимая, 304, 305, 319
машинно-независимая, 304, 305
ОС UNIX, 140, 221
Отладка программы, 258, 304, 344
Отладчик, 328, 334, 344
Отношения предшествования, 224, 225,
227, 235, 237
Память динамическая, 72, 280, 380-
статическая, 72, 280
Подготовка к генерации кода, 60, 282
Позднее связывание, 279
Правило грамматики (продукция), 20, 24, 32, 50, 104, 106, 125, 129, 181, 186, 224, 236, 285, 294
Х-правила (пустые), 105, 154, 156, 171, 177,234
цепные правила, 105, 154, 158, 171
Преобразования типов, 252, 253
Преобразователь контекстно-свободный, 294
Препроцессор, 73, 75
Проблема однозначности грамматик, 121
Проблема преобразования грамматик, 41, 49, 225, 235
Проблема эквивалентности
грамматик, 49, 120
Программа
исходная, 55, 58
объектная, 56
результирующая, 55, 56
Программа LEX, 140, 221
Программа YACC, 221
Промежуточный код компиляции, 69, 379
Проход компиляции, 61, 286
Р
Распознаватель, 18, 26, 30, 35, 59, 128, 145,
160, 249, 294
восходящий, 151, 153
для языка ассемблера, 71
линейный, 37, 150
LALR( 1 )-грамматики, 217
LL( 1 )-грамматики, 193, 208
LR(0)-rpaMMaTHKii, 205, 208
LR( 1 )-грамматики, 210, 212
LR(k)-rpaMMaTHKii, 200
восходящий левосторонний, 197
нисходящий левосторонний, 186
операторного предшествования, 235
простого предшествования, 231
нисходящий, 151
с возвратом, 164
с возвратом, 162
нисходящий, 165
табличный, 150
Распределение памяти, 60, 72, 259,
261-264
Регистры процессора
базовый регистр, 268, 276
обозначение, 71
общего назначения, 319
передача параметров, 271, 314
распределение, 320
регистр аккумулятора, 272, 320
регистр стека, 268, 275
Регулярное выражение, 114, 115, 121, 122
Регулярное множество, 114, 115, 120, 121
Редактор ресурсов, 332, 333
Редактор связей, 339
Результирующая программа, 58, 153, 267
Рекурсия в правилах грамматики, 22,
160, 177
Ресурсы интерфейса прикладной программы, 332, 333, 350
Рехэширование, 86, 88
С
Свертка объектного кода, 307—309
Связывание
динамическое, 265
позднее, 279
раннее, 279•
статическое, 265
Семантические соглашения языка, 250, 251
Семантический анализ, 250, 256, 259, 302
Семантический анализатор, 60, 72, 249
Сентенциальная форма, 43, 155
Сервер данных, 364
Сервер приложений, 366
Символ, 14
бесплодный, 154, 156
недостижимый, 155, 156
нетерминальный, 20, 45, 104, 123, 125,
129, 164, 171, 176, 186, 189, 222, 224,
229, 234, 236, 237, 240, 286, 287
левая факторизация, 177
левый контекст, 208
правый контекст, 209
рекурсивный, 160
терминальный, 20, 44, 46, 100, 125,
129, 164, 171, 222, 224, 234
Синтаксически управляемый перевод, 283
Синтаксический анализ, 60, 71, 96, 144,
152, 222, 249, 259, 262, 282, 284, 295
Синтаксический анализатор, 31, 100
Синтаксический разбор, 144
Синтаксическое дерево, 250, 282,
284-286
Система программирования, 66, 69, 328,
332, 339, 364, 372
Borland J Builder, 381f
Turbo Pascal, 331
система подсказок и справок, 338
Скалярный тип данных, 260
Сканер, 96, 139
Сложные структуры данных, 261
Соглашение о вызове и передаче
параметров, 271, 314
Стек параметров процедуры
(функции), 268, 271, 275, 276
Стиль программирования, 253, 257, 265,
304, 307, 313
Строка символов, 14
СУ-компиляция, 284, 286, 288, 293, 294 СУ-перевод, 262, 283, 284, 294, 298, 301, 302
т
Таблица RTTI, 279-281, 315
Таблица идентификаторов, 58, 61, 77, 86, 90, 97, 98, 250, 259, 282, 285, 336, 345 бинарное дерево, 80 линейный список, 79 метод цепочек, 89 хэш-функция, 84
Таблица лексем, 97, 98, 144, 250
Текстовый редактор, 327, 333, 335
Тонкий клиент, 366
Транслятор, 12, 54, 58
Трансляция адресов, 342
У
Уравнение с регулярными коэффициентами, 115—117, 123
Ф
Фаза компиляции, 59, 61, 78, 284, 286 Файл исполняемый, 56 исходный, 55 объектный, 56
Форма Бэкуса—Наура, 21, 130, 160, 182 Функция
виртуальная, 279
X
Хэш-адресация, 83, 84, 92
Хэширование, 85
Хэш-таблица, 89
Хэш-функция, 83, 85
ц
Целевой символ грамматики, 20, 21, 45, 105, 123, 200
Цепочка вывода, 41, 43, 44, 46, 48, 154 левосторонняя, 165, 169, 194, 196 правосторонняя, 171, 175, 207, 213, 220, 231, 232, 242, 243 рекурсивная, 160 циклическая, 158, 160
Цепочка символов, 14, 73, 107, 281, 285 пустая, 16
Числа зависимости, 310
Язык
HTML, 69
Java Script, 382
ассемблера, 56, 63, 66, 70, 73, 145, 262,
269, 281, 286, 291, 296, 298, 303, 308
высокого уровня, 63
заданный КА, 107
машинных кодов, 269, 281, 286, 291
программирования, 19, 66, 68, 203,
222, 249, 256, 259, 260, 263, 269,
271, 279, 313
Borland Pascal, 76, 98, 106, 128, 132, 181,251,261,263, 331
С, 75, 77, 99, 101, 130, 178, 221, 255, 261,315
C++, 265, 267, 274, 315
FORTRAN, 66, 99, 102, 346
Java, 69, 379.
Object Pascal, 266
Язык (продолжение)
Pascal, 267, 274
Visual Basic, 69
объектно-ориентированный, 266, 272, 279, 281
семантика, 62, 250, 257, 260, 282, 287, 299
семантические нормы, 250, 254 синтаксис, 60, 70, 145, 148, 258, 287 способы определения, 19, 64 формальный, 16, 34, 43
контекстно-зависимый, 35, 37, 40, 249
контекстно-свободный, 36, 37, 40, 145, 222, 249, 284
LL, 284
LR, 284 детерминированный, 37, 148, 202, 235
лексика, 18
регулярный, 36, 38, 99, 103, 120, 122
семантика, 18, 55-
синтаксис, 18
способы определения, 17, 30 четвертого поколения (4GL), 335
：ИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Алексей Юрьевич Молчанов — выпускник Санкт-Петербургского университета аэрокосмического приборостроения, кандидат технических наук, доцент.
В настоящее время преподает на кафедре «Вычислительные комплексы, системы и сети», а также является директором по разработкам НПП «СпецТек»,
Разработка программного обеспечения для современных^ вычислительных систем немыслима без использования ， трансляторов, компиляторов и систем программирование;
Этот учебник позволит читателям получить исче叨^^yj^% представление об этой важной части системно「с^ программного обеспечения, начиная с фундаментальных теоретических основ и заканчивая обзором современных систем программирования. В книге вы найдете не только 夕 теоретические сведения, но и ценные практические советЗ纟 и пояснения, которые дадут возможность лучше ра^^рдть^ в предмете и применить свои знания на практн忌 "
Базовый курс для ctj^htob высших учёбнь^ заведений, обучающихся по направлению ^ «Информатика и вь1тиели 吗麼嬲％техн»«嚇竣
Этот файл был взят с сайта
http://all-ebooks.com
Данный файл представлен исключительно в ознакомительных целях. После ознакомления с содержанием данного файла Вам следует его незамедлительно удалить. Сохраняя данный файл вы несете ответственность в соответствии с законодательством.
Любое коммерческое и иное использование кроме предварительного ознакомления запрещено. Публикация данного документа не преследует за собой никакой коммерческой выгоды.
Эта книга способствует профессиональному росту читателей и является рекламой бумажных изданий. Все авторские права принадлежат их уважаемым владельцам. Если Вы являетесь автором данной книги и её распространение ущемляет Ваши авторские права или если Вы хотите внести изменения в данный документ или опубликовать новую книгу свяжитесь с нами по email.
Хц в anO + ^l^nl 十 Х2СЦ2 + …+ ХпОЦуг
В стетеме уравнений с регулярными коэффициентами все коэффициенты ач
являются регулярными выражениями над алфавитом V, а переменные не входят
в алфавит V: Vi Xj«V. Оба варианта записи равноправны, но в общем случае мо
гут иметь различные решетия прй одинаковых коэффициентах при переменных.