Чем отличается транслятор от компилятора

Определение транслятора, компилятора, интерпретатора и ассемблера

Транслятор – это программа, которая переводит входную программу на исходном (входном) языке в эквивалентную ей выходную программу на результирующем (выходном) языке.

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

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

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

Ассемблер – компилятор, который переводит каждую команду исходной программы в одну машинную команду.

Интерпретатор — это программа, которая воспринимает входную программу на исходном языке и выполняет ее.

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

4.3 Общая схема работы компилятора

Основные функции компилятора:

1) проверка исходной цепочки символов на принадлежность к входному языку;

2) генерация выходной цепочки символов на языке машинных команд или ассемблере.

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

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

Данные этапы состоят из более мелких стадий, называемых фазами. Состав фаз и их взаимодействие зависит от конкретной реализации компилятора. Но в том или ином виде в каждом компиляторе выделяются следующие фазы:

1) лексический анализ;

2) синтаксический анализ;

3) семантический анализ;

4) подготовка к генерации кода;

5) генерация кода.

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

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

Общая схема работы компилятора представлена на рисунке 4.3.

Рисунок 4.1– Общая схема работы компилятора

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Разница между: транспайлер, транслятор, компилятор?

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

• Вопрос задан более трёх лет назад
• 14058 просмотров

• Facebook
• Вконтакте
• Twitter

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

Трансляция — преобразование исходного кода программы из одного ЯП в другой. Обычно компиляторы (например для C/C++) транслируют исходник в программу на асемблере, и уже потом ее компилируют.

Что касатеся транспайлера (Transpiler) — это тот же транслятор с той лишь разницей, что у результата примерно тот же уровень абстракции, что и у исходного текста (ну например транслятор из Java в C++).

Принципы построения транслирующих и интерпретирующих систем

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

Содержание

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

Трансляторы

Транслятор (от англ. translate – переводить) – это программа, которая считывает текст программы, написанной на одном языке (входном), и транслирует (переводит) его в эквивалентный текст на другом языке (выходном).

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

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

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

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

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

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

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

Компилятор

Кроме понятия «транслятор» широко употребляется также близкое ему по смыслу понятие «компилятор».

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

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

Всякий компилятор является транслятором, но не наоборот — не всяким транслятор будет компилятором. Например, упомянутый выше транслятор с языка Pascal на С компилятором не является.

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

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

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

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

Принцип работы

Компиляция — в общем случае многоступенчатый процесс, включающий следующие фазы:

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

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

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

Скорость исполнения откомпилированного объектного кода обычно выше, чем при исполнении кода интерпретатором. Этот недостаток ограничивает применение интерпретаторов.

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

Схема работы

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

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

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

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

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

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

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

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

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

Принципы построения

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

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

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

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

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

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

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

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

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

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

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

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

Особенности построения и функционирования компиляторов

Для задания языка программирования необходимо решить три задачи:

1. 1. определить множество допустимых символов языка;
2. 2. определить множество правильных программ языка;
3. 3. задать смысл для каждой правильной программы.

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

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

1. 1. изложить смысл программы, написанной на языке программирования, на другом языке, который может воспринимать пользователь программы или компьютер;
2. 2. использовать для проверки смысла некоторую «идеальную машину», которая предназначена для выполнения программ, написанных на данном языке.

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

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

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

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

Например, предложение в программе на языке Pascal вида: i :-0: while i-0 do 1 -0. может быть легко оценено любой машиной как бессмысленное. Но если в задачу входит обеспечение взаимодействия с другой параллельно выполняемой программой или просто проверка надежности и долговечности процессора или какой-то ячейки памяти, то это же предложение покажется уже не лишенным смысла.

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

В теории формальных языков вопрос о смысле программ не решается.

Особенности построения интерпретаторов

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

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

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

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

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

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

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

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

Широко распространенным примером интерпретируемого языка может служить HTML (Hypertext Markup Language) — язык описания гипертекста. На его основе в настоящее время функционирует практически вся структура сети Интернет. Другой пример — языки Java и JavaScript сочетают в себе функции компиляции и интерпретации (текст исходной программы компилируется в некоторый промежуточный код, не зависящий от архитектуры целевой вычислительной системы, этот кол распространяется по сети и интерпретируется на принимающей стороне).

1. Молдованова О. В. Языки программирования и методы трансляции: Учебное пособие. – Новосибирск: СибГУТИ, 2012. – 134с.
2. Опалева Э. А. Языки программирования и методы трансляции / Опалева Э. А., Самойленко В. П. — СПб.: БХВ-Петербург, 2005. — 480 с.
3. Свердлов С. 3. Языки программирования и методы трансляции: Учебное пособие. — СПб.: Питер, 2007. — 638 с.
4. Молчанов А. Ю. Системное программное обеспечение: Учебник для вузов / А. Ю. Молчанов. — СПб.: Питер, 2003. — 396 с.
5. Карпов Ю. Г. Теория и технология программирования. Основы построения трансляторов. — СПб.: БХВ-Петербург, 2005. — 272 с.
6. Голицына О. Л. Языки программирования : учебное пособие. — 2-е изд., перераб. и доп. — М. : ФОРУМ, 2010. — 400 с. : ил

08.02.2022, 1112 просмотров.

Чем отличается транслятор от компилятора

к алгоритмизации алгоритмы, струкутуры данных и программирование СУБД ЯиМП 3GL 4GL 5GL технологии прогр.

Классификация трансляторов

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

Трансляторы реализуются в виде компиляторов, интерпретаторов, препроцессоров и эмуляторов. С точки зрения выполнения работы компилятор и интерпретатор существенно различаются.

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

Интерпретатор (англ. interpreter — истолкователь, переводчик) — переводит программу построчно (по одному оператору) в машинный код (команды процессора, ОС, иной среды), выполняет переведенный оператор (строку программы), а затем переходит к следующей строке программного текста. Интерпретатор не формирует исполняемых файлов, он сам выполняет все действия, записанные в тексте исходной программы.

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

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

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

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

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

Препроцессор — это транслятор с одного языка программирования в другой без создания исполняемого файла или выполнения программы.

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

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

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

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

к алгоритмизации алгоритмы, струкутуры данных и программирование СУБД ЯиМП 3GL 4GL 5GL технологии прогр.

Трансляторы

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

Существует три вида трансляторов: интерпретаторы, компиляторы и ассемблеры.

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

Компилятор преобразует (транслирует) всю программу в модуль на машинном языке, после этого программа записывается в память компьютера и лишь потом исполняется.

Ассемблеры переводят программу, записанную на языке ассемблера (автокода), в программу на машинном языке.

Любой транслятор решает следующие основные задачи:

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

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

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

Введение в .Net и c Sharp

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

Среда разработки содержит:

Текстовый редактор для ввода и корректировки текста программы

Компилятор для перевода программы на язык машинных команд

Средства отладки и запуска программы на исполнение

Общие библиотеки с многократно используемыми программными элементами

Справочную систему и др.

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

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

Переносимость-возможность исполнения на разных типах компьютерах

Безопасность – невозможность несанкционированных действий

Надежность – безотказность работы в заданных условиях

Использование готовых компонентов для ускорения разработки

Межъязыковое взаимодействие – применение нескольких языков программирования.

Все эти задачи решают в рамках платформы .NET.

Для обеспечения переносимости компиляторы платформы переводят программу не в машинный код, а в промежуточный язык MSIL (Microsoft Intermediate Language) или просто в IL. IL не содержит команд, зависящих от операционной системы или типа компьютера. Программу на IL исполняет среда выполнения CLR (Common Language Runtime), которая уже специфична для каждого типа компьютера. Перевод IL-программы в машинные коды конкретного компьютера выполняет JIT (Just In Time) –компилятор.

Схема выполнения программы на платформе .NET приведена на рис.1.

Компилятор создает сборку программы – файл с расширение .exe или .dll, который содержит IL-код. Выполнение программы организует среда CRL, которая следит за допустимостью операций, выполняет распределение и очистку памяти и обрабатывает ошибки исполнения. Это обеспечивает безопасность и надежность программ.

Платой за эти достоинства является снижение быстродействия программ и необходимость установки на компьютере .NET для исполнения готовых программ.

Итак, .NET – это платформа программирования.

C# (Си-Шарп) — это один из языков программирования платформы .NET. Он входит в Visual Studio — Visual Studio.NET (Версии 2008, 2010, 2012). Кроме C# в Visual Studio.NET входят Visual Basic.NET и Visual C++.

Транслятор, компилятор, интерпретатор

Одна из причин разработки нового языка компанией Microsoft — это создание компонентно-ориентированного языка для платформы .NET Framework.

Рис.1 Схема выполнения программы в .NET

.NET Framework состоит из двух частей:

Во-первых, она включает огромную библиотеку классов, которые можно вызывать из программ на C#. Классов очень много (порядка несколько тысяч). Это избавляет от необходимости писать все самостоятельно. Поэтому программирование на С# заключается в написании собственного кода, который при необходимости вызывает классы, хранящиеся в .NET Framework.

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

Платформа .NET является открытой средой – сторонние разработчики создали для .NET десятки компиляторов для языков Ada, COBOL, Fortran, Lisp, Oberon, Perl, Python и др.

Платформа .NET активно развивается – выпускаются все новые версии этой платформы. С помощью меню Project – Properties выясните версию используемой платформы .NET.

Теоретически программа для среды .NET может выполняться под любой операционной системой, в которой .NET установлена. Но на практике единственная официальная платформа для этого — это операционная система Windows. Однако существуют неофициальные реализации .NET для Unix-подобных ОС Linux, Mac OS X и других (Mono — проект системы .NET Framework на базе свободного программного обеспечения).

Слово рапира

Слово рапира английскими буквами(транслитом) — rapira

Слово рапира состоит из 6 букв: а а и п р р

Значения слова рапира. Что такое рапира?

Рапи́ра (нем. Rapier, от фр. rapière, изначально исп. espadas roperas — буквально, «меч для одежды» (то есть не для доспеха), искажённое в фр. la rapiere) — преимущественно колющее холодное оружие, разновидность шпаги…

ru.wikipedia.org

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

БСЭ. — 1969—1978

РАПИРА (нем. Rapier, от франц. rapiere). Спортивное колющее оружие. Состоит из стального гибкого клинка и эфеса (защитной чашеобразной гарды и рукоятки). Клинок прямоугольного сечения, сужающийся к вершине…

Олимпийская энциклопедия. — 2006

РАПИРА, Расширенный Адаптированный Поплан-Интерпретатор, Редактор, Архив, — учебно-производственный язык программирования. Разработан в начале 80-х годов в СССР. Рапира является средством…

Энциклопедия языков программирования

Рапира — ракетная система класса «земля-воздух», разработанная британскими вооружёнными силами для Королевских военно-воздушных сил. Состоит на вооружении армий Австралии, Великобритании, Индонезии, Сингапура, Турции, Малайзии и Швейцарии.

ru.wikipedia.org

Рапира боевая — (от франц. rapiere) — колющее, резке колюще-рубящее длинноклинковое Х.0. с рукояткой, известно в Европе со 2-й половины 17 в. Состояли из прямого плоского или граненого стального клинка с заостренным (у дуэльных Р.)…

Петров А. Словарь холодного оружия и доспехов

РАПИРА СПОРТИВНАЯ — спортивное холодное оружие, состоящее из гибкого прямоугольного в сечении клинка и съемного черена с круглой чашкообразной гардой.

weapon.slovaronline.com

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

Петров А. Словарь холодного оружия и доспехов

Рапира (язык программирования)

РАПИРА — Расширенный Адаптированный Поплан-Интерпретатор, Редактор, Архив — процедурный язык программирования. Разработан в начале 80-х годов в СССР в качестве средства перехода от более простых языков (в частности, учебного языка Робик)…

ru.wikipedia.org

Фехтование на летних Олимпийских играх 1896 — рапира

Соревнования по фехтованию на рапирах среди мужчин на летних Олимпийских играх 1896 прошли 7 апреля.

Транслятор, компилятор, интерпретатор

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

ru.wikipedia.org

Фехтование на летних Олимпийских играх 1900 — рапира

Соревнования по фехтованию на рапирах среди мужчин на летних Олимпийских играх 1900 прошли с 14 по 19 и 21 мая. Приняли участие 54 спортсмена из десяти стран.

ru.wikipedia.org

Фехтование на летних Олимпийских играх 1900 — рапира среди маэстро

Соревнования по фехтованию на рапирах среди мужчин-маэстро на летних Олимпийских играх 1900 прошли с 22 по 25 и с 27 по 28 мая.

Приняли участие 59 спортсменов из семи стран.

ru.wikipedia.org

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

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

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

Стандарты языка программирования C

Лекция: Стандарты и лицензии на программное обеспечение

Стандарты семейства UNIX. Стандарты языка программирования C. System V Interface Definition (SVID). Комитеты POSIX. X/Open, OSF и Open Group. Лицензии на программное обеспечение и документацию.
Содержание

• 3.1. Стандарты семейства UNIX
  • Стандарты языка программирования C
  • System V Interface Definition (SVID)
  • Комитеты POSIX
  • X/Open, OSF и Open Group

  3.1. Стандарты семейства UNIX

  Причиной появления стандартов на операционную систему UNIX стало то, что она была перенесена на многие аппаратные платформы. Ее первые версии работали на аппаратуре PDP, но в 1976 и 1978 годах система была перенесена на Interdata и VAX. С 1977 по 1981 годы оформились две конкурирующие ветви: UNIX AT&T и BSD. Наверное, цели разработки стандартов были разными. Одна из них – узаконить главенство своей версии, а другая – обеспечить переносимость системы и прикладных программ между различными аппаратными платформами. В связи с этим говорят и о мобильности программ. Такие свойства имеют отношение как к исходным текстам программ, так и исполнимым программам.

  Дальнейший материал приводится в хронологическом порядке появления стандартов.

  Стандарты языка программирования C

  Этот стандарт не относится непосредственно к UNIX. Но поскольку C является базовым как для этого семейства, так и других ОС, упомянем о стандарте этого языка программирования. Начало ему было положено выходом в 1978 году первой редакции книги Б.Кернигана и Д.Ритчи. Этот стандарт часто называют K&R. Программисты, авторы этого труда, работали над UNIX вместе с Кеном Томпсоном. При этом первый из них предложил название системы, а второй изобрел этот язык программирования. Соответствующий текст доступен в Интернете [45].

  Однако промышленный стандарт языка программирования С был выпущен в 1989 году ANSI и имел имя X3. 159 – 1989. Вот что написано про этот стандарт [46]:

  "Стандарт был принят для улучшения переносимости написанных на языке Си программ между различными типами ОС. Таким образом, в стандарт, кроме синтаксиса и семантики языка Си, вошли рекомендации по содержанию стандартной библиотеки. О наличии поддержки стандарта ANSI C говорит предопределенное символьное имя _STDC".

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

  ^ System V Interface Definition (SVID)

  Другое направление развития стандартов UNIX связано с тем, что не только энтузиасты задумывались о создании "эталонов". Основные разработчики системы с появлением многих "вариантов" решили издавать собственные документы. Так появляются стандарты, выпускаемые USG, организацией, разрабатывающей документацию версий UNIX AT&T с того момента, когда для создания операционной системы была образована эта дочерняя компания. Первый документ появился в 1984 году на основе SVR2. Он имел название SVID (System V Interface Definition). Четырехтомное описание было выпущено после выхода в свет версии SVR4. Эти стандарты дополнялись набором тестовых программ SVVS (System V Verification Suite). Основное назначение этих средств состояло в том, чтобы разработчики имели возможность судить, может ли их система претендовать на имя System V [14].

  Отметим, что положение дел со стандартом SVID в чем-то сходно со стандартом языка программирования С. Изданная авторами этого языка программирования книга является одним из эталонов, но не единственным. Выпущенный позже стандарт С является результатом коллективного труда, прошел этап обсуждения широкой общественности и, видимо, может претендовать на ведущую роль в списке стандартов. Так и SVVS является набором тестов, позволяющих судить, достойна ли система соответствовать имени System V, только одной из версий UNIX. При этом не учитывается весь опыт разработки операционных систем от разных производителей.

  Комитеты POSIX

  Работа по оформлению стандартов UNIX началась группой энтузиастов в 1980 году. Была сформулирована цель – формально определить услуги, которые операционные системы обеспечивают приложениям. Такой стандарт программного интерфейса стал основой документа POSIX (Portable Operating System Interface for Computing Environment – переносимый интерфейс операционной системы для вычислительной среды) [14]. Первая рабочая группа POSIX была образована в 1985 году на основе UNIX-ориентированного комитета по стандартизации /usr/group, также называемой UniForum [47]. Название POSIX было предложено родоначальником GNU Ричардом Столмэном.

  Ранние версии POSIX определяют множество системных сервисов, необходимых для функционирования прикладных программ, которые описаны в рамках интерфейса, специфицированного для языка С (интерфейс системных вызовов). Заложенные в нем идеи использовались комитетом ANSI (American National Standards Institute) при создании стандарта языка C, упомянутого ранее. Исходный состав функций, закладываемый в первые версии, опирался на UNIX AT&T (версия SVR4 [48]). Но в дальнейшем происходит отрыв спецификаций стандартов POSIX от этой конкретной ОС. Подход к организации системы на основе множества базовых системных функций был применен не только в UNIX (например, WinAPI фирмы Microsoft).

  В 1988 году был опубликован стандарт 1003.1 – 1988, определяющий API (Application Programming Interface, программный интерфейс приложений). Через два года был принят новый вариант стандарта IEEE 1003.1 – 1990. В нем были определены общие правила программного интерфейса, как для системных вызовов, так и для библиотечных функций. Далее утверждаются дополнения к нему, определяющие сервисы для систем реального времени, "нитей" POSIX и др. Важным является стандарт POSIX 1003.2 – 1992 – определение командного интерпретатора и утилит.

  Имеется перевод [1] этих двух групп документов, которые получили такие названия: POSIX.1 (интерфейс прикладных программ) и POSIX.2 (командный интерпретатор и утилиты – интерфейс пользователя). В упомянутом переводе содержатся три главы: основные понятия, системные услуги и утилиты. Глава "Системные услуги" разделена на несколько частей, каждая из которых группирует сходные по функциям услуги. Например, в одном из разделов "Базовый ввод/вывод" седьмая часть, посвященная операциям с каталогами, описывает три функции (opendir, readdir и closedir). Они определяются в четырех пунктах: "Синтаксис", "Описание", "Возвращаемое значение" и "Ошибки".

  Для тех, кто знаком с алгоритмическим языком программирования С, приведем пример фрагментов описания.

  Языки программирования, трансляторы, компиляторы и интерпретаторы

  Фактически такое описание дает представление о том, как специфицируется "Интерфейс системных вызовов". В пункте "Синтаксис" про функцию readdir приведены такие строки:

  struct dirent *readdir(DIR *dirp);

  Второй пункт ("Описание") содержит следующий текст:

  "Типы и структуры данных, используемые в определениях с каталогами, определяются в файле dirent.h. Внутренний состав каталогов определяется реализацией. При чтении с помощью функции readdir формируется объект типа struct dirent, содержащий в качестве поля символьный массив d_name, в котором находится завершаемое символом NUL локальное имя файла.

  Readdir читает текущий элемент каталога и устанавливает указатель позиции на следующий элемент. Открытый каталог задается указателем dirp. Элемент, содержащий пустые имена, пропускается".

  А вот что приводится в пункте "Возвращаемое значение":

  "Readdir при успешном завершении возвращает указатель на объект типа struct dirent, содержащий прочитанный элемент каталога. Прочитанный элемент может заноситься в статическую память и перекрывается очередным таким вызовом, примененным к тому же открытому каталогу. Вызов readdir для различных открытых каталогов не перекрывает читаемую информацию. В случае ошибки или достижении конца файла возвращается нулевой указатель".

  В пункте "Ошибки стандарта" указано следующее:

  "Readdir и closedir обнаруживают ошибку. [EBADF] Dirp не являются указателем на открытый каталог".

  Этот пример показывает, как описываются представляемые приложением услуги. Требования к операционной системе (реализации) заключается в том, что она "…должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения. Константа _POSIX_VERSION имеет значение 200112L [49]".

  В мире компьютерных технологий существует такое словосочетание: "программирование POSIX". Этому можно научиться, используя различные руководства по системному программированию UNIX и операционным системам (например, [5]). Есть отдельная книга с таким названием [3]. Заметим, что в предисловии к этой книге сказано, что она описывает ". . . стандарт втройне . . ", так как она опирается на последнюю версию POSIX 2003 года, в основе которой три стандарта: IEEE Std 1003.1, технический стандарт Open Group и ISO/IEC 9945.

  Как же проверить соответствие конкретной системы стандарту POSIX? Формализация такого вопроса не так проста, как кажется на первый взгляд. В современных версиях предлагается 4 вида соответствия (четыре семантических значения слова "соответствие": полное, международное, национальное, расширенное).

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

  Отметим, что набор документов POSIX изменяется уже много лет. Но разработчики новых версий всегда стараются максимально сохранить преемственность с предыдущими версиями, В более свежих редакциях может появиться что-то новое. Например, в документе 2004 года были объединены четыре части [50]:

  • Base Definitions volume (XBD) – определение терминов, концепций и интерфейсов, общих для всех томов данного стандарта;
  • System Interfaces volume (XSH) – интерфейсы системного уровня и их привязка к языку Си, где описываются обязательные интерфейсы между прикладными программами и операционной системой, в частности – спецификации системных вызовов;
  • Shell and Utilities volume (XCU) – определение стандартных интерфейсов командного интерпретатора (т.н. POSIX-shell), а также базовой функциональности Unix-утилит;
  • Rationale (Informative) volume (XRAT) – дополнительная, в том числе историческая, информация о стандарте.

  Как и первые редакции, документ в своей основной части описывает группы представляемых услуг. Каждый элемент там описан в следующих пунктах: NAME (Имя), SINOPSIS (Синтаксис), DISCRIPTION (Описание), RETURN VALUE (Возвращаемое значение), ERRORS (Ошибки) и в заключении EXAMPLE (Примеры).

  Современные версии стандарта определяют требования как к операционной системе, так и к прикладным программам. Приведем пример [51].

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

  И в заключение приведем отрывок из курса лекций Сухомлинова ("ВВЕДЕНИЕ В АНАЛИЗ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ", Сухомлинов В.А. Часть V. Методология и система стандартов POSIX OSE), посвященным области применимости стандартов [52]:

  "Область применимости стандартов POSIX OSE (Open System Environment) – обеспечение следующих возможностей (называемых еще свойствами открытости) для разрабатываемых информационных систем:

  • Переносимость приложений на уровни исходных текстов (Application Portability at the Source Code Level), т.е. предоставление возможности переноса программ и данных, представленных на исходных текстах языков программирования, с одной платформы на другую.
  • Системная интероперабельность (System Interoperability), т.е. поддержка взаимосвязанности между системами.
  • Переносимость пользователей (User Portability), т.е. обеспечение возможности для пользователей работать на различных платформах без переобучения.
  • Адаптируемость к новым стандартам (Accommodation of Standards), связанным с достижением целей открытости систем.
  • Адаптируемость к новым информационным технологиям (Accommodation of new System Technology) на основе универсальности классификационной структуры сервисов и независимости модели от механизмов реализации.
  • Масштабируемость прикладных платформ (Application Platform Scalability), отражающая возможность переноса и повторного использования прикладного программного обеспечения применительно к разным типам и конфигурациям прикладных платформ.
  • Масштабируемость распределенных систем (Distributed System Scalability), отражающая возможность функционирования прикладного программного обеспечения независимо от развития топологии и ресурсов распределенных систем.
  • Прозрачность реализаций (Implementation Transparency), т.е. сокрытие от пользователей за интерфейсами систем особенностей их реализации.
  • Системность и точность спецификаций функциональных требований пользователей (User Functional Requirements), что обеспечивает полноту и ясность определения потребностей пользователей, в том числе в определении состава применяемых стандартов."

  Это позволяет решать следующие задачи:

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

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

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

  Существуют также групповые имена стандартов POSIX1, POSIX2 и т.д. Например, POSIX1 связан со стандартами на базовые интерфейсы ОС (Р1003.1х, где вместо х либо пусто, либо символы от a до g; таким образом, в этой группе 7 документов), а POSIX3 – методы тестирования (два документа – Р2003 и Р2003n).

  Похожие публикации:

  1. Как сделать зачеркнутый текст в канве
  2. Похожие приложения как спотифай
  3. Как удалить пробел в конце строки java
  4. Чем отличается частный канал от публичного в телеграмме