Системы программирования

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

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

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

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

Трансляция и компоновка

Трансляция

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

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

• Лексический анализ - Выявляются отельные  составляющие текста программы, которые называются лексемами, и определяется их тип. К числу лексем относятся названия операторов, например, read или write; имена (переменных или констант), например, NABOR или CHISLO, различные разделители, такие как круглые скобки, знаки препинания и т.д. Одновременно типами указанных лексем являются названия операторов, имена переменных, разделители и т.д. Если программистом допущена ошибка и оператор ввода указан, например, rread, он будет распознан компилятором как имя. На этом этапе выявляется  также использование недопустимых языком программирования символов, например, символа @. В результате лексического анализа исходная программа кодируется: каждая лексема заменяется кодом ее типа, что сокращает объем текста программы. Кроме того, из текста программы удаляются пробелы.
• Синтаксический анализ - определяется синтаксическая правильность закодированной в результате лексического анализа цепочки лексем. Например, определяется парность скобок, наличие в нужном месте требуемого знака препинания, соответствие исходного текста структурным правилам того или иного языка программирования, средствами которого была составлена программа. Для решения задачи в исходной (закодированной) цепочке выделяются подструктуры, соответствующие некоторым фрагментам оператора. Например, для оператора ввода в Турбо-Паскале можно определить структуру, представленную на рисунке 1 и соответствующую правилам из примера1 раздела Структурно-стилизованный способ описания алгоритма:

 Рисунок 1

В то же время структура "правильного" оператора ввода определяется схемой:

 Рисунок 2

Поскольку представленные структуры идентичны, оператор read (NABOR,CHISLO);  при синтаксическом анализе определяется как правильный.

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

 Рисунок 3

Поскольку структура этого рисунка  не соответствует структуре рисунка 1, оператор rread (NABOR,CHISLO); расценивается как синтаксически некорректный: компилятор не найдет в анализируемом фрагменте требуемого действия, которое задается названием оператора, и сообщит об этом программисту.

• Семантический анализ - на этом шаге выявляются ошибки, допущенные программистом в нарушение правил составления программ, например, следующего  вида: все переменные и константы перед употреблением в операторах языка должны быть описаны; каждое имя (переменной или константы) должно быть описано только один раз; требуется согласование типов переменных с использующими их функциями и т.д. Так, если вся программа состоит только из оператора read (NABOR,CHISLO);        она будет определена как семантически некорректная, поскольку в ней отсутствуют описания вводимых переменных.
• Генерация промежуточного кода - Закодированная цепочка лексем преобразуется в некоторое промежуточное представление, принятое на том или ином компьютере, например, в программу на языке ассемблера (для простоты используем некоторый условный ассемблер).
• Оптимизация промежуточного кода - из программы, полученной на предыдущем шаге, устраняются «лишние» операторы, переменные  и константы, использование которых  не влияет на корректность выполняемых действий.
• Генерация объектного кода - программа, полученная в результате оптимизации, преобразуется в машинный код (так называемый объектный модуль), в котором использованы относительные, а не абсолютные адреса основной памяти. Как правило, для получения объектного модуля применяется условная память с начальным адресом 1. Каждый оператор программы преобразуется в машинную команду и размещается, начиная с начального адреса, в той последовательности, в которой он следует в программе. При этом учитывается размер каждого оператора..

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

 Компоновка 

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

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

Например, пусть для выполнения программы из таблицы раздела Трансляция отводится область основной памяти, начиная с абсолютного адреса 40. Тогда, с учетом сегментированной схемы адресации указанные в таблице адреса ( с учетом абсолютного адреса 40) преобразуются в свои сегментированные эквиваленты:

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

исходный и объектный модули

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

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

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

О п р е д е л е н и е.  Модуль — выделенная по тем или иным мотивам часть первичного материала программного фонда.      

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

Объектный модуль

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