6 какие трансляторы были созданы раньше интерпретаторы или компиляторы: интерпретаторы и компиляторы — Студопедия - Управленческое образование

Содержание

интерпретаторы и компиляторы — Студопедия

Практически во всех трансляторах (и в компиляторах, и в интерпретаторах) в том или ином виде присутствует большая часть перечисленных ниже процессов: лексический анализ; синтаксический анализ; семантический анализ; генерация внутреннего представления программы; оптимизация; генерация объектной программы. Транслятор — это программа, которая переводит входную программу на исходном (входном) языке в эквивалентную ей выходную программу на результирующем (выходном) языке. В работе транслятора участвуют всегда три программы: 1) сам транслятор является программой обычно он входит в состав системного по вычислительной системы. То есть транслятор — это часть по. Он представляет собой набор машинных команд и данных и выполняется компьютером, как и все прочие программы в рамках ос. 2)исходными данными для работы транслятора служит текст входной программы — некоторая последовательность предложений входного языка программирования. Этот файл должен содержать текст программы, удовлетворяющий синтаксическим и семантическим требованиям входного языка. 3)выходными данными транслятора является текст результирующей программы. Результирующая программа строится по синтаксическим правилам, заданным в выходном языке транслятора, а ее смысл определяется семантикой выходного языка. Важным требованием в определении транслятора является эквивалентность входной и выходной программ т.е совпадение их смысла с точки зрения семантики входного языка (для исходной программы) и семантики выходного языка (для результирующей программы). Чтобы создать транслятор, необходимо, прежде всего, выбрать входной и выходной языки. С точки зрения преобразования предложений входного языка в эквивалентные им предложения выходного языка транслятор выступает как переводчик. Результатом работы транслятора будет результирующая программа в том случае, если текст исходной программы является правильным — не содержит ошибок с точки зрения синтаксиса и семантики входного языка. Если исходная программа неправильная, то результатом работы транслятора будет сообщение об ошибке. Кроме понятия

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

Назначение трансляторов, компиляторов и интерпретаторов

Первыми компиляторами были компиляторы с языков ассемблера или, как они назывались, мнемокодов. Мнемокоды превратили текст программы, написанный на языке машинных команд в более-менее доступный пониманию специалиста язык. Создавать программы стало значительно проще, но исполнять сам мнемокод ни один компьютер неспособен, соответственно, возникла необходимость в создании компиляторов. Следующим этапом стало создание языков высокого уровня. Они представляют собой промежуточное звено между чисто формальными языками и языками естественного общения людей. От первых им досталась строгая формализация синтаксических структуру предложений языка, от вторых — значительная часть словарного запаса, семантика основных конструкций и выражений. Появление языков высокого уровня существенно упростило процесс программирования. Однако преобладают компьютеры традиционной, архитектуры, которые умеют понимать только машинные команды, поэтому вопрос о создании компиляторов продолжает быть актуальным. Компиляторы создавались и продолжают создаваться не только для новых, но и для давно известных языков. С тех пор как большинство теоретических аспектов в области компиляторов получили свою практическую реализацию (это произошло в конце 60-х годов), развитие компиляторов пошло по пути их дружественности пользователю, разработчику программ на языках высокого уровня. Логичным завершением этого процесса стало создание систем программирования — программных комплексов, объединяющих в себе кроме непосредственно компиляторов множество связанных с ними компонентов по.на сегодняшний день компиляторы являются неотъемлемой частью любой вычислительной системы. Без их существования программирование любой прикладной задачи было бы затруднено, а то и просто невозможно. Да и программирование специализированных системных задач, как правило, ведется если не на языке высокого уровня, то на ассемблере, следовательно, применяется соответствующий компилятор. Компиляторы обычно несколько проще в реализации, чем интерпретаторы. По эффективности они также превосходят их — очевидно, что откомпилированный код будет исполняться всегда быстрее, чем происходит интерпретация аналогичной исходной программы. Кроме того, не каждый язык программирования допускает построение простого интерпретатора. Однако, интерпретаторы имеют одно существенное преимущество — откомпилированный код всегда привязан к архитектуре вычислительной системы, на которую он ориентирован, а исходная программа — только к семантике языка программирования, которая гораздо легче поддается стандартизации. Первыми компиляторами были компиляторы с мнемокодов. Их потомки — современные компиляторы с языков ассемблера — существую практически для всех известных вычислительных систем. Они предельно жестко ориентированы на архитектуру. Затем появились компиляторы с таких языков, как fortran, algol-68,. Они были ориентированы на большие эвм с пакетной обработкой задач. Из вышеперечисленных языков, только fortran продолжает использоваться по сей день, поскольку имеет огромное количество библиотек различного назначения. На рынке программных систем доминируют компиляторы языков с и c++. Первый из них родился вместе с операционными системами типа unix, а затем перешел под ос других типов. Второй удачно воплотил в себе пример реализации идей объектно-ориентированного программирования на хорошо зарекомендовавшей себя практической базе. Изначально интерпретаторам не предавали существенного значения, поскольку почти по всем параметрам они уступают компиляторам. Тем не менее сейчас ситуация несколько изменилась, поскольку вопрос о переносимости программ и их аппаратно-платформенной независимости приобретает все большую актуальность с развитием сети интернет. Самый известный сейчас пример — это язык java (сам по себе он сочетает компиляцию и интерпретацию), а также связанный с ним javascript. Кроме того, язык html, на котором зиждется протокол http — это тоже интерпретируемый язык.

Этапы трансляции. Общая схема работы транслятора

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

Понятие прохода. Многопроходные и однопроходные компиляторы

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

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

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

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

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

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

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

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

Интерпретатор — это программа, которая воспринимает входную программу на исходном языке и выполняет ее. Основное отличие интерпретаторов от трансляторов и компиляторов заключается в том, что интерпретатор не порождает результирующую программу, а просто выполняет исходную программу. Термин «интерпретатор» (interpreter) означает «переводчик». Простейшим способом реализации интерпретатора можно было бы считать вариант, когда исходная программа сначала полностью транслируется в машинные команды, а затем сразу же выполняется. В такой реализации интерпретатор, мало бы, чем отличался от компилятора с той лишь разницей, что результирующая программа в нем была бы недоступна пользователю. Недостатком такого интерпретатора было бы то, что пользователь должен был бы ждать компиляции всей исходной программы прежде, чем начнется ее выполнение. По сути, в таком интерпретаторе не было бы никакого особого смысла — он не давал бы никаких преимуществ по сравнению с аналогичным компилятором. Поэтому подавляющее большинство интерпретаторов действует так, что исполняет исходную программу последовательно, по мере ее поступления на вход интерпретатора. Тогда пользователю не надо ждать завершения компиляции всей исходной программы. Более того, он может последовательно вводить исходную программу и тут же наблюдать результат ее выполнения по мере ввода команд. При таком порядке работы интерпретатора проявляется существенная особенность, которая отличает его от компилятора, — если интерпретатор исполняет команды по мере их поступления, то он не может выполнять оптимизацию исходной программы. Следовательно, фаза оптимизации в общей структуре интерпретатора будет отсутствовать. В остальном же она будет мало отличаться от структуры аналогичного компилятора. Далеко не все языки программирования допускают построение интерпретаторов, которые могли бы выполнять исходную программу по мере поступления команд. Для этого язык должен допускать возможность существования компилятора, выполняющего разбор исходной программы за один проход. Кроме того, язык не может интерпретироваться по мере поступления команд, если он допускает появление обращений к функциям и структурам данных раньше их непосредственного описания. Отсутствие шага оптимизации ведет к тому, что выполнение программы с помощью интерпретатора является менее эффективным, чем с помощью аналогичного компилятора. Т.о, интерпретаторы всегда проигрывают компиляторам в производительности. Преимуществом интерпретатора является независимость выполнения программы от архитектуры целевой вычислительной системы. В результате компиляции получается объектный код, который всегда ориентирован на определенную архитектуру. Для перехода на другую архитектуру целевой вычислительной системы программу требуется откомпилировать заново. А для интерпретации программы необходимо иметь только ее исходный текст и интерпретатор с соответствующего языка. Интерпретаторы существовали для ограниченного круга относительно простых языков программирования (basic). Высокопроизводительные профессиональные средства разработки программного обеспечения строились на основе компиляторов. Новый импульс развитию интерпретаторов придало распространение глобальных вычислительных сетей. Такие сети могут включать в свой состав эвм различной архитектуры, и тогда требование единообразного выполнения на каждой из них текста исходной программы становится определяющим. Поэтому с развитием глобальных сетей и распространением всемирной сети интернет появилось много новых систем, интерпретирующих текст исходной программы. В современных системах программирования существуют реализации по, сочетающие в себе и функции компилятора, и функции интерпретатора — в зависимости от требований пользователя исходная программа либо компилируется, либо исполняется (интерпретируется). Некоторые современные языки программирования предполагают две стадии разработки: сначала исходная программа компилируется в промежуточный код, а затем этот результат компиляции выполняется с помощью интерпретатора данного промежуточного языка. Примером интерпретируемого языка может служить html (hypertext markup language) — язык описания гипертекста или языки java и javascript — сочетают в себе функции компиляции и интерпретации.

Как были сделаны первые компиляторы?

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

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

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

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

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

Сегодня первый компилятор для нового языка часто пишется на C, но когда язык достигает определенной зрелости, он часто переписывается «сам по себе». Первый компилятор Java был написан на C, но позже переписан на Java. Первый компилятор C # был написан на C ++, но недавно он был переписан на C #. Компилятор / интерпретатор Python написан на C, но проект PyPy — это попытка переписать его на Python.

Хотя не всегда возможно написать компилятор / интерпретатор для языка на самом языке. Интерпретатор JavaScript, написанный на JavaScript, существует, но компиляторы / интерпретаторы в современных браузерах по-прежнему написаны на C или C ++ по соображениям производительности. JavaScript, написанный на JavaScript, просто слишком медленный.

Но вам не нужно использовать C как «начальный язык» для компилятора. Первый компилятор F # был написан на OCaml, который является другим языком, наиболее тесно связанным с F #. Когда компилятор был готов, он был переписан на F #. Первый компилятор для Perl 6 был написан на Haskell (чистый функциональный язык, сильно отличающийся от Perl), но теперь имеет компилятор, написанный на C.

Интересным примером является Rust, где первый компилятор был написан на OCaml (теперь он переписан на Rust). Это примечательно, потому что OCaml, как правило, считается более высоким уровнем, чем Rust, который является языком систем ближе к железу. Так что это не всегда языки более высокого уровня, реализованные в языках более низкого уровня, это также может быть наоборот.

Компиляторы, интерпретаторы и трансляторы

← →
Cyrax © (2006-11-20 13:44) [0]

1. Трансляторы, компиляторы и интерпретаторы
Транслятор (в пер. с англ. — «переводчик») – это программа, принимающая на вход программу на одном языке и преобразующая её в программу на другом языке. Исходными и це-левыми языками могут быть как языки высокого уровня, так и низкого (промежуточный байт код или язык ассемблера), в том числе и машинный код.
Примеры трансляторов: assembler (язык ассемблера -> машинный код), дизассемблер (язык ассемблера -> машинный код), компиляторы и декомпиляторы языков высокого уровня, утилита, преобразующая pascal-код в C-код, javac (транслятор Java) и др.
Компилятор – это частный случай (разновидность) трансляторов. А именно, такой транслятор, который преобразует программу на некотором языке программирования в машинный код. В строгом понимании под машинным кодом следует понимать машинный код процессора. Именно такого понимания придерживаются авторы книги «PHP 5» Дмитрий Котеров и Алексей Костарев, рассматривающие процесс преобразования кода с языка высокого уровня на промежу-точный код (например, байт-код или p-код) как трансляцию (трансляцию в широком понимании, не относящейся к компиляции). С другой стороны, промежуточный код тоже можно рассматри-вать как машинный, только машиной уже является не процессор, а виртуальная машина (CLR для .NET и JVM для Java). Такая абстракция позволяет представить процесс преобразования кода с языка высокого уровня на промежуточный код как компиляцию (разновидность трансляции). Та-кой подход наиболее распространён. Универсальность первого подхода заключается в том, что он не противоречит второму подходу, поскольку компилятор – это транслятор.
Следует отметить, что процесс преобразования процессорного кода в промежуточ-ный нельзя рассматривать как компиляцию (это трансляция процессорного кода в промежуточ-ный), поскольку компиляция подразумевает обработку сверху вниз, т.е. от языка более высокого уровня к языку более низкого (тогда как трансляция может происходить в любом направлении, в том числе и на одном уровне (например, pascal -> С)).
Интерпретатор – это программа, «просматривающая» код на некотором языке про-граммирования и «выполняющая» одну его инструкцию за другой. Основной функцией про-грамм, транслирующих (в частности, компилирующих) и интерпретирующих код является та, ко-торая выполняется на последнем этапе работы таких программ. Поэтому программы, которые сначала транслируют (компилируют согласно второму подходу в понимании компиляторов) код на языке высокого уровня в промежуточный код, а затем его интерпретируют, называют интер-претаторами (с оптимизирующим транслятором (первый подход) или компилирующего типа (второй подход)).
Ключевые отличие интерпретаторов от компиляторов:
1. интерпретатор обнаруживает синтаксические ошибки только когда интерпретиру-ет данную инструкцию
2. интерпретируемые языки позволяют формировать и изменять команды в процессе выполнения программы (для компилируемых языков это возможно только на этапе работы пре-процессора с помощью макросов)
2. интерпретатор ещё и «выполняет» преобразуемый код (естественно, с помощью процессора)
В определении интерпретаторов также существует два подхода. Согласно первому подходу (авторы книги «PHP 5» Дмитрий Котеров и Алексей Костарев) интерпретаторы не явля-ются подмножеством трансляторов, поскольку интерпретаторы не выдают на выходе преобразо-ванного кода программы. Второй подход относит интерпретаторы к множеству трансляторов, по-скольку интерпретатор всё же транслирует инструкции в машинный код (которые сразу же вы-полняет процессор), хотя и не выдаёт преобразованный код программы.

Ниже приведена таблица, иллюстрирующая различия в подходах к пониманию трансляторов, компиляторов и интерпретаторов.

Строгий подход Абстрактный подход
Сторонники авторы книги «PHP 5» Дмитрий Ко-теров и Алексей Костарев Авторы большинства статей в Ин-тернете
Классификация программ, преобра-зующих программный код Трансляторы и интерпретаторы. Компиляторы – частный случай трансляторов Трансляторы.
Компиляторы и интерпретаторы – частные случаи трансляторов
Характеристика интерпретаторов, выполняющих предварительную трансляцию в промежуточный код Интерпретатор с оптимизирующим транслятором или интерпретирую-щий транслятор (с основной функци-ей интерпретации) Интерпретатор компилирующего типа

Чистые компиляторы: C, C++, Pascal, Assembler
Чистые интерпретаторы: Basic, JavaScript, JScript, командный язык DOS (выполняю-щий bat-файлы), shell (командный язык Unix), Python и его разновидности, JVM (виртуальная машина Java), PHP до версии 3, CLR (общеязыковая среда исполнения технологии .NET).
Интерпретаторы с оптимизирующей трансляцией: PHP с версии 4, Perl
Трансляторы в промежуточный код: .NET-языки (Visual C#, Visual J#, Visual Basic .NET, Visual C++ .NET), javac (транслятор Java).

______________________________________________________________
Зацените статью и, собственно, своё мнение (только не обо мне, а об изложенном)…

← →
Cyrax © (2006-11-20 13:46) [1]

Так, с таблицеё чё-то не вышло. Сейчас будет…

← →
Александр Иванов © (2006-11-20 13:50) [2]

Слишком много букв, причем о вещах, которые уже описаны в толстенных книгах.

← →
Игорь Шевченко © (2006-11-20 13:59) [3]

> Зацените статью

Графоманство

← →
Курдль © (2006-11-20 14:04) [4]

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

← →
KilkennyCat © (2006-11-20 14:04) [5]

ой.

← →
Cyrax © (2006-11-20 14:09) [6]

Игорь Шевченко © (20.11.06 13:59) [3]

Зато всё по полочкам…

Александр Иванов © (20.11.06 13:50) [2]
Слишком много букв, причем о вещах, которые уже описаны в толстенных книгах.

В этих толстенных книгах везде написано по-разному. Причём об одних и тех же вещах — то копмилятор, то транслятор (или интерпретатор). Толковых разьяснений я ещё не встречал (только это, которое сам сочинил).
Я что -гений ?:))

← →
boriskb © (2006-11-20 14:10) [7]

Cyrax © (20.11.06 13:44)

Дельная вещь.
Ты разобрался.
В голове улеглось
Чтобы лучше улеглось, все постарался систематизировано записать.
Я так часто делал.

Только на всеобщее обозрение не надо было выставлять.
🙂

← →
KilkennyCat © (2006-11-20 14:11) [8]

> Я что -гений ?:))

нет. ибо все гениальное — просто. а тут все слишком сложно. хотя можно было бы уложиться в два предложения.

← →
Джо © (2006-11-20 14:12) [9]

Много ошибок и неточностей. Например:
Чистые интерпретаторы: … JVM (виртуальная машина Java).
Ну, и см. [4] Курдль ©.

← →
Cyrax © (2006-11-20 14:14) [10]

boriskb © (20.11.06 14:10) [7]

Возможно, выпендрёж…
Впрочем, я хотел обсудить детали. Чтоб не писать всё заново — копирнул.
Вот 4-й пост — вот это и нужно…

← →
click (2006-11-20 14:22) [11]

с дефисами проблемы имхо…
а в остальном… чтош, мысли в слух тебе удалось весьма похвально отформатировать…

← →
Cyrax © (2006-11-20 14:27) [12]

Курдль © (20.11.06 14:04) [4]
Определение компилятора дано неточно (под это определение подходит и ассемблер).

Ну так чем ассемблер (не язык, а транслятор) не компилятор ??

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

Ну а это уже не чистые интерпретаторы…

Джо © (20.11.06 14:12) [9]
Много ошибок и неточностей. Например:
Чистые интерпретаторы: … JVM (виртуальная машина Java).

Что — не чистый ?

← →
Vga © (2006-11-20 14:35) [13]

> Джо © (20.11.06 14:12) [9]
> Много ошибок и неточностей. Например:
> Чистые интерпретаторы: … JVM (виртуальная машина Java)
> .
>
> Что — не чистый ?

Это виртуальная машина. Причем, вполне может и сперва откомпилировать код, а потом запускать (JIT-компиляция).

← →
Джо © (2006-11-20 14:39) [14]

> [12] Cyrax © (20.11.06 14:27)
> Что — не чистый ?

Совершенно верно. Равно как и технология .Net в которой также используется JIT-компиляция.

← →
Курдль © (2006-11-20 14:41) [15]

> Cyrax © (20.11.06 14:27) [12]
> Ну так чем ассемблер (не язык, а транслятор) не компилятор ??

Ассемблер отличается от компилятора тем, что он транслирует одно предложение ЯП строго в одну машинную команду.

Основным отличием интерпретатора является то, что он транслирует и сразу инициирует выполнение предложения за предложением.

← →
Курдль © (2006-11-20 14:43) [16]

> Джо © (20.11.06 14:39) [14]

> Vga © (20.11.06 14:35) [13]

Такие трансляторы называют Common-трансляторами.

← →
Vga © (2006-11-20 14:46) [17]

> [16] Курдль © (20.11.06 14:43)

А как называют трансляторы вроде lua, которая сперва компилирует программу в байткод своей VM, потом выполняет на ней без фокусов типа JIT?

← →
Cyrax © (2006-11-20 15:00) [18]

Курдль © (20.11.06 14:41) [15]
Ассемблер отличается от компилятора тем, что он транслирует одно предложение ЯП строго в одну машинную команду.

Одна команда asm -> одна команда процессора ? Это что — фокус ?
Но даже если взять какой-то гипотетический язык выше машкода, где
одна команда языка -> одна команда процессора, то это тоже будет компилятор…

Основным отличием интерпретатора является то, что он транслирует и сразу инициирует выполнение предложения за предложением.

Да, JVM — не чистый интерпретатор, т.к. компилит весь код в натив (JIT»ом), только потом его запускает…
Но вот JIT — чистый копмилятор…

← →
Anatoly Podgoretsky © (2006-11-20 15:04) [19]

> Cyrax (20.11.2006 15:00:18) [18]

Компилятор/Интерпритарор к ассемблеру не имеют отношения, есть и интерпритирующие ассемблеры.

← →
Курдль © (2006-11-20 15:05) [20]

> Cyrax © (20.11.06 15:00) [18]
> Одна команда asm -> одна команда процессора ? Это что — фокус ?

А ты не задумывался, почему не бывает «чистого» ассемблера, а он всегда с какими-то мерзкими добавочками типа «Ассемблер 386» или «Ассемблер РС»?

Дальше ты начинаешь утомлять. Я дал тебе точное определение и отличия трансляторов (возможно, они устарели).

← →
Cyrax © (2006-11-20 15:38) [21]

Anatoly Podgoretsky © (20.11.06 15:04) [19]
Компилятор/Интерпритарор к ассемблеру не имеют отношения, есть и интерпритирующие ассемблеры.

Интерпретирующий ассемблер — интерпретатор, компилирующий — компилятор (и транслятор)…

← →
oldman © (2006-11-20 18:39) [22]

> Транслятор (в пер. с англ. — «переводчик») – это программа,
> принимающая на вход программу на одном языке и преобразующая
> её в программу на другом языке.

Мдя…

← →
DrPass © (2006-11-20 18:44) [23]

> компилирующий — компилятор

А есть ли компилирующие ассемблеры? Компиляция подразумевает преобразование. Ассемблер по сути выполняет только подстановку — машинные коды вместо их символических обозначений

← →
oldman © (2006-11-20 18:46) [24]

> DrPass © (20.11.06 18:44) [23]
> Ассемблер по сути выполняет только подстановку — машинные коды вместо их символических обозначений

давно???

← →
Anatoly Podgoretsky © (2006-11-20 19:50) [25]

> DrPass (20.11.2006 18:44:23) [23]

MacroAssembler

← →
DrPass © (2006-11-21 00:07) [26]

> oldman © (20.11.06 18:46) [24]
> давно???

Изначально

> Anatoly Podgoretsky © (20.11.06 19:50) [25]

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

← →
MeF Dei Corvi © (2006-11-21 00:47) [27]

> Ассемблер по сути выполняет только подстановку — машинные
> коды вместо их символических обозначений

А подстановка не есть преобразование?
К тому же есть ассемблеры, анализирующие код на лишние недостижимые команды.
FASM, например, очень интересный ассемблер.
http://ru.wikipedia.org/wiki/FASM

Начало цифровой эпохи | Открытые системы. СУБД

60-е годы можно назвать для СССР началом цифровой эпохи — для появившихся отечественных машин М-20, М-220, М-222, БЭСМ-4 и БЭСМ-6 требовалась, как сейчас говорят, программная платформа из системного и прикладного ПО. Например, для первых алгоритмических языков Алгол и Фортран необходимо было срочно создать трансляторы [1], способные работать под ОС появляющихся ЭВМ.

Библиотека стандартных программ, ИС-2

Первой в ИПМ после машины «Стрела» появилась ЭВМ М-20, одна из самых мощных в 1959 году серийно выпускаемых машин в мире [2]. Система представления чисел — двоичная с плавающей запятой, 45 разрядов на коды чисел; оперативная память — 4096 45-разрядных слов; производительность — 20 тыс. операций в секунду. Вспоминает П. П. Головистиков, один из разработчиков М-20: «Начали работать над машиной трое: Сергей Алексеевич Лебедев, Михаил Романович Шура-Бура и я. Лебедев разрабатывал идеологию машины и ее структуру, Шура-Бура — систему команд и занимался проработкой математических вопросов, я перерабатывал их решения и требования в конкретные схемы». В результате был принят ряд новаторских на тот момент (1958 год) решений: система команд — трехадресная; допустимо совмещение выполнения арифметической операции с выборкой из оперативной памяти следующей команды; допустимо совмещение операций процессора с операциями ввода-вывода данных.

Весь 1958 год М-20 налаживалась в СКБ-245, куда были командированы инженеры ИПМ для отладки узлов машины. Для приемки машины были написаны две тестовые программы. Кроме того, для ЭВМ «Стрела», работавшей в то время в ИПМ, был создан эмулятор МС («М-20 на Стреле»), позволяющий заранее отлаживать программы для М-20. Однако основная работа по программному обеспечению для М-20 началась с создания библиотеки стандартных программ (СП). Начиная с августа 1958 года, еще до установки машины, группе выпускников механико-математического факультета МГУ было поручено создать библиотеку стандартных программ: ввод-вывод на внешние устройства, переводы чисел из двоичной в десятичную систему счисления и обратно, тригонометрические функции, логарифм, операции с матрицами и др. Кроме того, нужно было разработать интерпретирующую систему, которая бы заведовала этой библиотекой, — в результате была создана интерпретирующая система ИС-1.

Шура-Бура тщательно следил за экономией памяти и тактов работы М-20, поскольку библиотечная система навсегда отнимала у счетных задач ее часть и поэтому обязана была работать быстро. Вскоре стало ясно, что ИС-1 тратит лишние такты и занимает много памяти, поэтому, отказавшись от излишнего универсализма и виртуозно используя систему команд М-20, Шура-Бура за одно воскресенье написал новую интерпретирующую систему ИС-2. Организация СП была сохранена в том же виде, что и в ИС-1, но получилась более понятной и удобной. Например, часто используемые куски прикладных расчетных программ можно было оформить как стандартные программы и обращаться к ним через ИС-2.

Система сразу получила широкое признание и фактически стала предвестником будущих ОС, выполняя динамическое связывание, подкачку и смену используемых подпрограмм, причем все это делалось с мизерными накладными расходами и весьма скромными запросами на память. Высокая эффективность ИС-2 и продуманный интерфейс с основной программой сделали ее неотъемлемой частью комплекта поставки M-20.

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

Когда в конце 1958 года первый экземпляр М-20 привезли в ИПМ, она уже была освоена как инженерами, так и программистами, а для математиков начались семинары по системе команд и ИС-2. Надо сказать, что М. В. Келдыш следил за изучением, как бы сейчас сказали, основ информатики всеми сотрудниками института, издав, например, в апреле 1961 года приказ о сдаче техминимума.

Программа техминимума для М-20

В 1965 году в ИПМ появилась полупроводниковая машина БЭСМ-4 [3], совместимая с М-20, но имевшая больше памяти, и для нее Шура-Бура и его сотрудники модернизировали систему ИС-2 (новое название — ИС-22) и библиотеку стандартных программ.

Алгол-60, ТА-2

Вскоре после установки М-20 поступили сообщения о новом языке Алгол-58, толчком к разработке которого стало появление в 1957 году языка Фортран. В США к нему отнеслись прохладно, а в Европе приняли с энтузиазмом. Разумеется, Алгол в конце концов пробился и к американским компьютерам, но так и не одолел Фортран, стартовавший первым и уже завоевавший рынок. Американцы настаивали на языке, который был бы близок к уже используемым ими на своих компьютерах, а европейцев интересовали не столько компьютеры, сколько мощь языка при решении сложных математических задач.

Как только появилось сообщение об Алголе, три коллектива отечественных программистов взялись за создание трансляторов для машины М-20: группа из ОКБ-1 трудилась над транслятором ТА-1 под руководством С. С. Лаврова, группа из ИПМ создавала транслятор ТА-2 (М. Р. Шура-Бура и Э. З. Любимский), группа из СО АН (А. П. Ершов) работала над транслятором Альфа [4]. Разработчики ТА-2 взяли за основу полный вариант языка Алгол-60. Авторы ТА-1 и Альфа-транслятора отказались от рекурсивных процедур и некоторых других трудно реализуемых элементов языка. Главные задачи этих групп — скорость трансляции (ТА-1) и эффективность получаемого кода (Альфа-транслятор).

ТА-2 создавался сотрудниками отдела программирования ИПМ, и особых трудностей работа не вызывала за исключением программирования блока процедур — наиболее сложной части транслятора. Реализация рекурсивности и учет всех типов параметров, определенных в описании Алгола-60, требовали от программистов высокой квалификации и изобретательности. К весне 1963 года транслятор был готов к эксплуатации, и в июне все разработчики ТА-2 отправились в Киев на Международную конференцию социалистических стран — «Методы автоматического программирования и машинные языки» c докладами и с транслятором на магнитных лентах. Разработчики Альфа-транслятора привезли с собой тест «Man or Boy», написанный Дональдом Кнутом, тогда еще малоизвестным программистом. Тест, как вспоминал Дмитрий Корягин, «проверял потенцию рекурсивности, обеспечиваемую транслятором». Если транслятор допускал более чем 10-уровневую рекурсивность, то он получал оценку «Man», в противном случае — «Boy». ТА-2 с этим тестом справился, доказав свою мужественность. Однако для реализации рекурсии требовался большой объем памяти, а возможности М-20 были весьма скромными (около 20 Кбайт), поэтому программным путем было реализовано поле «математической памяти» (виртуальной памяти) со сплошной адресацией, включающей как оперативную, так и внешнюю память, правда, за это нужно было платить увеличением времени доступа к данным. Для того времени это было очень важное решение — автор программы на Алголе мог не знать емкостей отдельных блоков внешней памяти и соотношения их скоростей, а его программа все равно работала правильно.

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

КЭВМ

Параллельно с работами по Алголу началось движение за создание ассоциации пользователей ЭВМ М-20 — на учредительном собрании членов ассоциации весной 1961 года Шура-Бура был избран председателем совета ассоциации, а в июле ассоциация решением Президиума АН СССР получила статус юридического лица и официальное название «Комиссия по эксплуатации вычислительных машин М-20» (КЭВМ).

Заседание Комиссии по эксплуатации вычислительных машин под председательством М. Р. Шура-Бура, Колонный зал Дома союзов

В поставляемые вместе с машиной библиотеки и трансляторы ИС-2, ТА-1 и ТА-2 со временем вносились исправления, а с появлением новых ЭВМ, совместимых с М-20 (М-220, М-220М, М-222) потребовалась модификация библиотек, ИС-22 и трансляторов (ТА-1М, ТА-2М, транслятор с Автокода на БЭСМ-4 и М-220 — авторы Ю. М. Баяковский и Т. Н. Михайлова). Совершенствовалась и операционная система ОС 4/220 для БЭСМ-4 и М-220. Новинки и исправления распространялись на лентах и перфокартах через координирующую группу КЭВМ, члены которой организовывали консультации, семинары и помогали в установке трансляторов. В 1969 году было выполнено сравнительное тестирование ТА-1М, ТА-2М и Альфа, позволившее КЭВМ сформулировать рекомендации при выборе транслятора для конкретной машины.

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

АЛМО

Конец 50-х — начало 60-х годов ознаменовались не только активным созданием трансляторов — начался лавинообразный процесс языкотворчества. И среди системных программистов, создававших трансляторы в машинных кодах, возникла идея специализированных языков для создания трансляторов и других больших систем. Такой язык должен быть машинно ориентированным и одновременно языком-посредником. Для того чтобы создать трансляторы с M языков на N машин нужно написать M*N трансляторов, а с использованием языка-посредника достаточно M трансляторов с исходного языка на язык-посредник и N трансляторов с языка-посредника на N машин. Первой такой попыткой был язык UNCOL [5], разработанный Мэлвином Конвеем в 1958 году, а у нас были созданы языки АЛМО (ИПМ), Эпсилон и Сигма (СО АН СССР).

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

Первым был создан компилятор АЛМО-БЭСМ-4, затем транслятор Комплекс Алгол, транслятор Фортран-АЛМО, а затем начал создаваться транслятор Алгамс-АЛМО. Комплекс Алгол — это транслятор с Алгола и средства отладки, позволяющие получить информацию о месте аварийного останова в терминах языка и предпринять некоторые действия (например, сделать необходимые выдачи). Алгамс-АЛМО — транслятор с языка Алгамс, дополненного рекурсивными процедурами. Алгамс был разработан в 1963–1966 годах Группой по автоматизации программирования для машин среднего типа (ГАМС), созданной комиссией многостороннего сотрудничества Академий наук социалистических стран. В основу Алгамса был положен язык Алгол с ограничениями, облегчающими процесс трансляции. Фортран-АЛМО — транслятор с языка Фортран IV. Несколько позже началась работа по созданию транслятора Форшаг-АЛМО, который наряду с выполнением функций, присущих обычным трансляторам, позволял вести пошаговую, пооператорную трансляцию программы на Фортран IV в диалоговом режиме.

Компилятор АЛМО-БЭСМ-4 заработал в 1968 году, а АЛМО-БЭСМ-6 был готов к 1970 году. Компиляторы АЛМО появлялись и на других машинах — например, на машине СПЭМ, созданной в Военно-космической Академии (ВИКИ) им. А. Ф. Можайского в Ленинграде.

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

Система программирования на базе языка АЛМО получила название Универсальной. В среднем времена счета, полученные по готовым программам различных задач, для трансляторов Универсальной системы были не хуже, чем для трансляторов, написанных вручную. Более того, для трансляторов Фортран-АЛМО и Форшаг времена счета были даже лучше, чем для транслятора Фортран-Дубна. В трансляторы Универсальной системы не включались алгоритмы оптимизации циклов, вследствие чего в готовой программе не используется эффективная команда окончания цикла. Это значит, что использование АЛМО в качестве языка для написания транслятора и двойная трансляция не приводили к замедлению работы.

Следует отметить, что система программирования на базе языка АЛМО — явление уникальное в мировой программной инженерии, ведь язык UNCOL так и остался теоретическим языком и система трансляторов на его основе не появилась. Создание машинно ориентированного языка и действующей системы трансляторов на его основе, несомненно, было значительным достижением.

ОС ИПМ

Первый серийный экземпляр БЭСМ-6 появился в ИПМ во второй половине 1966 года и был установлен в зале, где раньше стояла «Стрела». Вместе с машиной была поставлена первая для БЭСМ-6 ОС Диспетчер-68 (Д-68), а позднее появились Мониторная система ДУБНА, ОС ДИСПАК и ОС ИПМ.

Для БЭСМ-6 в ИПМ сразу был разработан язык Автокод с транслятором БЕМШ (по первым буквам фамилий авторов: Бочкова З. Ф., Езерова Г. Н., Михелев В. М., Штаркман В. С.). Автокод — язык символьного кодирования, рассчитанный на специалистов, знакомых со структурой и системой команд машины. В Автокоде введены мнемонические обозначения команд, символическая адресация объектов программы. Предусмотрены различные способы задания данных и констант, распределения памяти. Поддерживалась перемещаемость оттранслированных программ, запись их в архив автокодных программ (АРАП), возможность связи на уровне меток нескольких независимо транслированных кусков в одну программу с помощью редактора внешних связей (РВС) и загрузчика. Сначала БЕМШ был подключен к Д-68, а впоследствии входил в состав математического обеспечения ОС ИПМ, ОС ДИСПАК и Мониторной системы ДУБНА. Однако Автокод оставался машинно-ориентированным языком, обеспечивающим перевод «один в один» предложения, составленного в символах, в машинную команду, поэтому очень скоро был создан язык описания макрокоманд более высокого уровня.

В 1967 году был опубликован «Проект системы математического обеспечения БЭСМ-6» (технические условия), включавший Универсальную систему программирования и операционную систему ОС ИПМ. При разработке ОС ИПМ широко использовались принятые в обществе механизмы взаимодействия: все задачи рассматривались как члены коллектива, которые могут вступать друг с другом в различные отношения — от совершенной изоляции до полного разделения всех ресурсов. Каждый ресурс (память, файл, устройство) имел своего хозяина, который мог его отдавать или сдавать в аренду любой другой задаче, оговаривая соответствующие права использования. Обмен сообщениями между задачами обладал всеми особенностями почтовых отправлений, включая уведомление о вручении. Каждая задача могла открывать до восьми процессов, для управления которыми использовался аппарат событий, а также прямые команды открытия, закрытия, прерывания и пуска. Одни задачи могли вызывать другие, выстраивая таким образом деревья подчинения произвольной глубины. При вызове подчиненной задачи можно было определить режим управления, при котором главной задаче в любой момент были доступны любые ресурсы подчиненной.

Отладка ОС ИПМ шла трудно — в институте была лишь одна машина БЭСМ-6, на ней считались прикладные задачи математических отделов, сотрудники которых полагали, что если есть уже какая-то операционная система, то ее достаточно, однако Келдыш был другого мнения. Профессор А. К. Платонов вспоминает: «Мстислав Всеволодович вызвал меня и сказал: “Вы освободите БЭСМ-6, не мешайте Михаилу Романовичу делать ОС ИПМ”, а мы в то время готовились к пуску на Луну, соревнуясь с американцами. Я попытался что-то горячо возразить, но он тихо сказал: “Вы не спорьте, вы выполняйте!” — это были самые жесткие слова, какие я от него услышал».

Стабильная версия ОС ИПМ появилась в 1970 году и успешно эксплуатировалась все 70-е годы, разделяя время с ОС ДИСПАК, причем некоторые задачи могли считаться только на ОС ИПМ — например, задачи отдела А. А Самарского: в ОС ИПМ была реализована виртуальная память, чего в ДИСПАК в то время не было. В проекте ОС ИПМ впервые в мире были сформулированы подходы к разработке операционных систем, намного опередившие свое время, — многие современные ОС построены сегодня на принципах, впервые предложенных в проекте системы математического обеспечения БЭСМ-6.

РЕФАЛ

В. Ф. Турчин — создатель языка РЕФАЛ

В конце 1964 года в ИПМ пришел Валентин Федорович Турчин, который в 33 года уже был известным физиком-теоретиком, соавтором известных сборников «Физики шутят» и «Физики продолжают шутить», а также автором комедии «Защита диссертации» по мотивам защиты диссертации «Качение бревна по наклонной плоскости с учетом сучковатости» на соискание ученой степени кандидата бревнологических наук в Научно-исследовательском институте бревен и сучков (НИИБС).

Турчин начал работу в ИПМ, выступив с докладом на тему «Метаалгоритмический язык для символьных преобразований», позже получивший название РЕФАЛ (АЛгоритмический язык РЕкурсивных Функций). Язык был воспринят тогда критически — зачем нужен еще один язык для символьных преобразований, когда уже есть, например, Лисп? Но Турчин считал, что РЕФАЛ больше подходит для таких символьных задач, как преобразование программ, алгебраические преобразования, доказательство теорем. Он организовал РЕФАЛ-семинар, куда привлек студентов МГУ, в 1968–1969 годах на БЭСМ-6 был запущен интерпретатор с языка, а затем и компилятор. Однако в 1972 году Турчин ушел из ИПМ, это случилось вскоре после того, как он написал «Письмо к вождям», которое подписали А. Д. Сахаров и Рой Медведев. Вскоре Турчин был вынужден уехать из страны, а подписанный к печати типографский набор его книги с описанием концепции метасистемного перехода «Феномен науки» был рассыпан. Вместе с тем, как и АЛМО и ОС ИПМ, язык РЕФАЛ намного опередил свое время и сегодня оказался весьма эффективным, например для символьной обработки [6].

***

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

Литература

Галина Езерова, Энгелина Луховицкая. Первый компилятор // Открытые системы.СУБД. — 2013. — № 7. — С. 52–53. URL: http://www.osp/ru/os/2013/07/13037356 (дата обращения 18.09.2014).
Наталья Дубова. Очерки истории советской вычислительной техники // Открытые системы.СУБД. — 1999. — № 1. — С. 69–76. URL: http://www.osp.ru/os/1999/01/179659 (дата обращения 18.09.2014).
Вера Карпова, Леонид Карпов. Первая БЭСМ: начало пути // Открытые системы.СУБД. — 2007. — № 10. — С. 74–79. URL: http://www.osp.ru/os/2007/10/4706915 (дата обращения 18.09.2014).
Наталья Черемных, Ирина Крайнева. Альфа-язык и транслятор // Открытые системы.СУБД. — 2014. — № 6. — С. 39–41. URL: http://www.osp.ru/os/2014/06/13042317 (дата обращения 18.09.2014).
Тед Льюис. О Java по Гамбургскому счету // Открытые системы.СУБД. — 1997. — № 6. — С. 18–22. URL: http://www.osp.ru/os/1997/06/179299 (дата обращения 18.09.2014).
Александр Речинский, Виктор Горбунов, Леонид Эйсымонт. Суперкластер с глобально адресуемой памятью // Открытые системы.СУБД. — 2011. — № 7. — С. 21–25. URL:http://www.osp.ru/os/2011/07/13010476 (дата обращения 18.09.2014)

Галина Езерова ([email protected]), Энгелина Луховицкая ([email protected]) — сотрудники ИПМ им. М. В. Келдыша РАН (Москва).

Поделитесь материалом с коллегами и друзьями

Разработка компиляторов — тест 3

Главная / Программирование / Разработка компиляторов / Тест 3 Упражнение 1:

Номер 1

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

Ответ:

&nbsp(1) в одну машинную инструкцию&nbsp

&nbsp(2) в несколько машинных инструкций&nbsp

&nbsp(3) в пустую машинную инструкцию&nbsp

&nbsp(4) в произвольную машинную инструкцию&nbsp

Номер 2

Трансляторы бывают следующих типов:

Ответ:

&nbsp(1) compiler&nbsp

&nbsp(2) interpreter&nbsp

&nbsp(3) analysis&nbsp

&nbsp(4) synthesis&nbsp

Номер 3

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

Ответ:

&nbsp(1) analysis&nbsp

&nbsp(2) synthesis&nbsp

&nbsp(3) interpreter&nbsp

&nbsp(4) begin&nbsp

Упражнение 2:

Номер 1

Можно сказать, что результатом работы интерпретатора является:

Ответ:

&nbsp(1) «программа»&nbsp

&nbsp(2) «код»&nbsp

&nbsp(3) «число»&nbsp

&nbsp(4) «исполняемый файл»&nbsp

Номер 2

Для интерпретатора верны следующие утверждения:

Ответ:

&nbsp(1) анализирует программу на входном языке&nbsp

&nbsp(2) создает промежуточное представление&nbsp

&nbsp(3) не создает никакой новой программы&nbsp

&nbsp(4) выполняет операции, содержащиеся в тексте программы&nbsp

Номер 3

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

Ответ:

&nbsp(1) входом компилятора &nbsp

&nbsp(2) выходом компилятора&nbsp

&nbsp(3) процессом компиляции&nbsp

&nbsp(4) процессом интерпретации&nbsp

Упражнение 3:

Номер 1

Крайне важной частью процесса трансляции является:

Ответ:

&nbsp(1) исправление ошибок, допущенных во входной программе&nbsp

&nbsp(2) игнорирование ошибок, допущенных во входной программе&nbsp

&nbsp(3) точная диагностика ошибок, допущенных во входной программе&nbsp

Номер 2

Объектная программа может быть:

Ответ:

&nbsp(1) последовательностью абсолютных машинных команд&nbsp

&nbsp(2) последовательностью перемещаемых машинных команд&nbsp

&nbsp(3) программой на языке ассемблера&nbsp

&nbsp(4) программой на некотором другом языке&nbsp

Номер 3

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

Ответ:

&nbsp(1) редактором сегментов&nbsp

&nbsp(2) редактором связей&nbsp

&nbsp(3) редактором объектов&nbsp

&nbsp(4) редактором наборов&nbsp

Упражнение 4:

Номер 1

Подход при котором применяется трансляция программы в ассемблер:

Ответ:

&nbsp(1) упрощает конструирование компилятора&nbsp

&nbsp(2) сокращает технологическую цепочку выполнения программы&nbsp

&nbsp(3) удлиняет технологическую цепочку выполнения программы&nbsp

&nbsp(4) усложняет конструирование компилятора&nbsp

Номер 2

Преимуществами трансляции в ассамблер являются:

Ответ:

&nbsp(1) уровень ассемблера выше, чем у машинного кода&nbsp

&nbsp(2) использование ассемблера позволяет отследить целый ряд ошибок&nbsp

&nbsp(3) порождаемый текст на ассемблере значительно читабельней, чем машинный код&nbsp

Номер 3

Для представления компилятора мы можем использовать так называемые:

Ответ:

&nbsp(1) P-диаграммы&nbsp

&nbsp(2) T-диаграммы&nbsp

&nbsp(3) R-диаграммы&nbsp

&nbsp(4) S-диаграммы&nbsp

&nbsp(5) E-диаграммы&nbsp

&nbsp(6) D-диаграммы&nbsp

Упражнение 5:

Номер 1

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

Ответ:

&nbsp(1) для различных языков&nbsp

&nbsp(2) для целевых платформ&nbsp

&nbsp(3) при создании новой компьютерной архитектуры&nbsp

Номер 2

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

Ответ:

&nbsp(1) метод раскрутки&nbsp

&nbsp(2) метод генерации&nbsp

&nbsp(3) использование кросс-трансляторов&nbsp

&nbsp(4) использование виртуальных машин&nbsp

&nbsp(5) компиляция «на лету»&nbsp

Номер 3

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

Ответ:

&nbsp(1) 1969&nbsp

&nbsp(2) 1970&nbsp

&nbsp(3) 1971&nbsp

&nbsp(4) 1972&nbsp

&nbsp(5) 1973&nbsp

Упражнение 6:

Номер 1

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

Ответ:

&nbsp(1) метод раскрутки&nbsp

&nbsp(2) метод упаковки&nbsp

&nbsp(3) метод генерации&nbsp

&nbsp(4) метод распаковки&nbsp

Номер 2

Под переносимой (portable) программой понимается программа, которая:

Ответ:

&nbsp(1) может без перетрансляции выполняться на одной платформе&nbsp

&nbsp(2) не может без перетрансляции выполняться на нескольких платформах&nbsp

&nbsp(3) может без перетрансляции выполняться на нескольких платформах&nbsp

Номер 3

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

Ответ:

&nbsp(1) конвертерами&nbsp

&nbsp(2) генераторами&nbsp

&nbsp(3) кросс-компиляторами&nbsp

&nbsp(4) исполнителями&nbsp

Упражнение 7:

Номер 1

Одна из первых широко известных виртуальных машин была разработана в 70-х годах Н. Виртом:

Ответ:

&nbsp(1) при написании компилятора Pascal-P&nbsp

&nbsp(2) при написании компилятора Pascal&nbsp

&nbsp(3) при написании компилятора Simula-P&nbsp

&nbsp(4) при написании компилятора Simula&nbsp

Номер 2

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

Ответ:

&nbsp(1) Java&nbsp

&nbsp(2) C++&nbsp

&nbsp(3) C&nbsp

&nbsp(4) Fortran&nbsp

Номер 3

Компиляторы языка Java генерируют:

Ответ:

&nbsp(1) бит-код&nbsp

&nbsp(2) объектный код&nbsp

&nbsp(3) байт-код&nbsp

Упражнение 8:

Номер 1

Для того, чтобы увеличить скорость работы приложений, была разработана технология:

Ответ:

&nbsp(1) compiling&nbsp

&nbsp(2) Just-In-Time compiling&nbsp

&nbsp(3) Just compiling&nbsp

&nbsp(4) Fats compiling&nbsp

Номер 2

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

Ответ:

&nbsp(1) «компилятор+интерпретатор+JIT-компилятор»&nbsp

&nbsp(2) «интерпретатор+JIT-компилятор»&nbsp

&nbsp(3) «компилятор+интерпретатор»&nbsp

&nbsp(4) «компилятор+интерпретатор+JIT-компилятор+интепретатор»&nbsp

Номер 3

Процесс создания компилятора можно свести к решению нескольких задач, которые принято называть:

Ответ:

&nbsp(1) compilation steps&nbsp

&nbsp(2) compilation phases&nbsp

&nbsp(3) compilation rounds&nbsp

&nbsp(4) compilation stages&nbsp

Упражнение 9:

Номер 1

Обычно компилятор состоит из следующих фаз:

Ответ:

&nbsp(1) лексический анализ&nbsp

&nbsp(2) синтаксический анализ&nbsp

&nbsp(3) видозависимый анализ&nbsp

&nbsp(4) оптимизация&nbsp

&nbsp(5) генерация кода&nbsp

Номер 2

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

Ответ:

&nbsp(1) фазы синтаксического анализа&nbsp

&nbsp(2) фазы видозависимого анализа&nbsp

&nbsp(3) фазы генерации кода&nbsp

&nbsp(4) фазы лексического анализа&nbsp

Номер 3

На этапе лексического анализа обычно выполняются такие действия, как:

Ответ:

&nbsp(1) удаление комментариев&nbsp

&nbsp(2) обработка директив условной компиляции&nbsp

&nbsp(3) игнорирование комментариев&nbsp

&nbsp(4) обработка операторов&nbsp

Упражнение 10:

Номер 1

После синтаксического анализа можно считать, что исходная программа преобразована:

Ответ:

&nbsp(1) в некоторое промежуточное представление&nbsp

&nbsp(2) в некоторое промежуточное состояние&nbsp

&nbsp(3) в объектное представление&nbsp

&nbsp(4) в исполняемый файл&nbsp

Номер 2

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

Ответ:

&nbsp(1) операциям&nbsp

&nbsp(2) операндам&nbsp

&nbsp(3) классам&nbsp

&nbsp(4) подклассам&nbsp

Номер 3

Видозависимый анализ иногда называют:

Ответ:

&nbsp(1) semantic analysis&nbsp

&nbsp(2) syntax analysis&nbsp

&nbsp(3) lexical analysis&nbsp

&nbsp(4) code optimization&nbsp

Упражнение 11:

Номер 1

Обязательность описания переменных может служить примером:

Ответ:

&nbsp(1) предварительных условий&nbsp

&nbsp(2) контекстных условий&nbsp

&nbsp(3) дополнительных условий&nbsp

&nbsp(4) временных условий&nbsp

Номер 2

Наиболее распространенными оптимизациями являются:

Ответ:

&nbsp(1) константные вычисления&nbsp

&nbsp(2) уменьшение силы операций&nbsp

&nbsp(3) выделение общих подвыражений&nbsp

&nbsp(4) чистка циклов&nbsp

Номер 3

На этапе генерации кода необходимо решить множество следующих сопутствующих проблем:

Ответ:

&nbsp(1) распределение памяти&nbsp

&nbsp(2) распределение регистров&nbsp

&nbsp(3) распределение блоков&nbsp

&nbsp(4) распределение стеков&nbsp

Упражнение 12:

Номер 1

Какие фазы иногда объединяют вместе под названием front-end?

Ответ:

&nbsp(1) лексический анализ&nbsp

&nbsp(2) синтаксический анализ&nbsp

&nbsp(3) видозависимый анализ&nbsp

&nbsp(4) некоторые оптимизации&nbsp

Номер 2

Процесс обработки всего, возможно, уже преобразованного, текста исходной программы называется:

Ответ:

&nbsp(1) passes&nbsp

&nbsp(2) control&nbsp

&nbsp(3) analysis&nbsp

&nbsp(4) audit&nbsp

Номер 3

Backpatching - это:

Ответ:

&nbsp(1) внутренний интерфейс&nbsp

&nbsp(2) техника «заплат»&nbsp

&nbsp(3) внешний интерфейс&nbsp

&nbsp(4) тестирование программы&nbsp

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

Спасибо!

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

Конечно же, это очень соблазнительно.

Вопрос — не пробовали делать псевдо-translated, копируя в буфер кода куски, ограниченные парами меток?

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

Не существует портабельного (да и вообще хоть какого-то надёжного) способа определить длину тела функции в Си. Адрес начала функции получить тривиально, а вот конец — нет. Использование адресов меток вместо функций может быть и помогло; но я боюсь, что компилятор начнёт переставлять метки, объединять их и т.п., особенно на уровнях оптимизаций, отличных от -O0. Может быть, какие-то компиляторные барьеры расставить удастся, не знаю.
Тела функций не получается конкатенировать, так как в коде процедур точек выхода может быть несколько. Очень часто компилятор преобразует код вида

    void f() {
        if (a) {
            code1;
        } else {
            code2;
        }
    }

в следующий машинный код:

f:
cmp a, 0
je alternative
code1
ret ; <--- exit 1
alternative:
code2
ret ; <--- exit 2

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

То есть, в промежуточном коде надо как-то найти все инструкции ret и заменить их на jmp single_exit. Что, согласитесь, нетривиально, учитывая различную длину ret и jmp.

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

В общем, если компилятор не «приручен», то его вывод будет с трудом подвергаться дальнейшим трансформациям.

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

Почему первый компилятор был написан раньше первого интерпретатора?

Обмен стеков

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

anguyen спрашивает:

Первый компилятор был написан Грейс Хоппер в 1952 году, а интерпретатор Лиспа был написан в 1958 году учеником Джона Маккарти Стивом Расселом.Написание компилятора кажется намного более сложной задачей, чем интерпретатор. Если это так, то почему первый компилятор был написан за шесть лет до первого интерпретатора?

См. Полный исходный вопрос и все ответы здесь.

Euphoric ответов (78 голосов):

Написание компилятора кажется гораздо более сложной задачей, чем создание интерпретатора.

Это может быть правдой сегодня, но я бы сказал, что 60 лет назад этого не было.Несколько причин, почему:

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

Связано: «Интерпретируемое и скомпилированное: полезное различие?»

mctylr ответы (35 голосов):

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

В то время лучшие пользовательские интерфейсы в основном ограничивались перфокартами и телетайпами. В 1961 году система SAGE стала первым дисплеем с электронно-лучевой трубкой (ЭЛТ) на компьютере.Таким образом, интерактивная природа переводчика не была предпочтительной или естественной до гораздо более позднего времени.

Многочисленные компьютеры в 1950-х годах использовали переключатели на передней панели для загрузки инструкций, и на выходе были просто ряды ламп / светодиодов. Любители даже использовали переключатели на передней панели и светодиоды в 1970-х годах. Возможно, вы знакомы с печально известным Altair 8800.

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

Ограничения памяти все еще были основным фактором, когда группа, возглавляемая Джоном Бэкусом из IBM, создала компилятор FORTRAN в 1954-57 годах.Этот инновационный компилятор был успешным только потому, что он был оптимизирующим компилятором.

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

Дополнение

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

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

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

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

История

— Почему первый компилятор был написан до первого интерпретатора?

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

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

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

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

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

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

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

Успех

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

Интерпретируемые и компилируемые языки программирования

: в чем разница?

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

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

Хорошо… но что на самом деле означает ?

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

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

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

Скомпилированные языки
Скомпилированные языки преобразуются непосредственно в машинный код, который может выполнять процессор. В результате они, как правило, быстрее и эффективнее выполняются, чем интерпретируемые языки. Они также дают разработчику больше контроля над аппаратными аспектами, такими как управление памятью и использование ЦП.
Для скомпилированных языков требуется этап «сборки» — сначала их нужно скомпилировать вручную.Вам нужно «перестраивать» программу каждый раз, когда вам нужно внести изменения. В нашем примере с хумусом весь перевод написан до того, как он попадет к вам. Если первоначальный автор решит, что он хочет использовать другой вид оливкового масла, весь рецепт нужно будет снова перевести и отправить вам повторно.
Примерами чистых компилируемых языков являются C, C ++, Erlang, Haskell, Rust и Go.
Интерпретируемые языки
Интерпретаторы запускают программу построчно и выполняют каждую команду.Здесь, если автор решает использовать другой вид оливкового масла, он может вычеркнуть старое и добавить новое. Затем ваш друг-переводчик может передать вам это изменение, когда оно произойдет.
Интерпретируемые языки когда-то были значительно медленнее, чем компилируемые языки. Но с развитием своевременной компиляции этот разрыв сокращается.
Примеры распространенных интерпретируемых языков: PHP, Ruby, Python и JavaScript.
Небольшое предупреждение
Большинство языков программирования могут иметь как скомпилированные, так и интерпретируемые реализации — сам язык не обязательно компилируется или интерпретируется.Однако для простоты их обычно называют таковыми.
Python, например, может выполняться либо как скомпилированная программа, либо как интерпретируемый язык в интерактивном режиме. С другой стороны, большинство инструментов командной строки, интерфейсов командной строки и оболочек теоретически можно отнести к интерпретируемым языкам.
Преимущества и недостатки
Преимущества компилируемых языков
Программы, которые компилируются в собственный машинный код, обычно быстрее, чем интерпретируемый код.Это связано с тем, что процесс трансляции кода во время выполнения увеличивает накладные расходы и может привести к замедлению работы программы в целом.
Недостатки компилируемых языков
Наиболее заметными недостатками являются:
Дополнительное время, необходимое для завершения всего этапа компиляции перед тестированием
Зависимость сгенерированного двоичного кода от платформы
Преимущества интерпретируемых языков
Интерпретируемые языки имеют тенденцию к быть более гибким и часто предлагать такие функции, как динамический набор текста и меньший размер программы.Кроме того, поскольку интерпретаторы сами выполняют исходный программный код, сам код не зависит от платформы.
Недостатки интерпретируемых языков
Наиболее заметным недостатком является типичная скорость выполнения по сравнению с компилируемыми языками.
1,7. Терминология: интерпретатор и компилятор — Python для всех
Python — это высокоуровневый язык , предназначенный для относительно легко для людей читать и писать и для компьютеры для чтения и обработки.Другие языки высокого уровня включают Java, C ++, PHP, Ruby, Basic, Perl, JavaScript и многие другие. Настоящий оборудование внутри центрального процессора (ЦП) не понимает любой из этих языков высокого уровня.
ЦП понимает язык, который мы называем машиной язык . Машинный язык очень простой и, откровенно говоря, очень утомительно писать, потому что он представлен все нулями и единицами:
001010001110100100101010000001111 11100110000011101010010101101101 ...
Машинный язык на первый взгляд кажется довольно простым, учитывая, что есть только нули и единицы, но его синтаксис еще сложнее и намного сложнее сложнее, чем Python.Так что очень немногие программисты когда-либо пишут машину язык. Вместо этого мы создаем различные переводчики, чтобы программисты могли писать на языках высокого уровня, таких как Python или JavaScript, и эти переводчики переводят программы на машинный язык для актуальных выполнение ЦП.
Поскольку машинный язык привязан к компьютерному оборудованию, машина язык не переносится через разные типы аппаратное обеспечение. Программы, написанные на языках высокого уровня, можно перемещать между разные компьютеры с использованием другого интерпретатора на новой машине или перекомпилировать код для создания версии на машинном языке программа для новой машины.
Эти переводчики языков программирования делятся на две общие категории: (1) интерпретаторы и (2) компиляторы.
Интерпретатор считывает исходный код программы как написано программистом, анализирует исходный код и интерпретирует инструкции на лету. Python — это интерпретатор, и когда мы запуская Python в интерактивном режиме, мы можем ввести строку Python (предложение) и Python обрабатывает его немедленно и готов к вводу другого линия Python.
Некоторые строки Python говорят Python, что вы хотите, чтобы он запомнил некоторая ценность на потом. Нам нужно выбрать имя, чтобы это значение было запомнили, и мы можем использовать это символическое имя для получения значения потом. Мы используем термин переменная для обозначения меток мы используем для ссылки на эти сохраненные данные.
>>> х = 6 >>> print (x) 6 >>> у = х * 7 >>> print (y) 42 >>>
В этом примере мы просим Python запомнить значение шесть и использовать label x , чтобы мы могли получить значение позже.Мы проверяем что Python действительно запомнил значение, используя печать . Затем мы просим Python получить x , умножьте его на семь и положите вновь вычисленное значение в и . Затем мы просим Python распечатать значение на данный момент в y .
Несмотря на то, что мы вводим эти команды в Python по одной строке за раз, Python рассматривает их как упорядоченную последовательность операторов с более поздними операторы, способные извлекать данные, созданные в более ранних операторах.Мы напишите наш первый простой абзац с четырьмя предложениями в логическом и осмысленный порядок.
Интерпретатор может иметь интерактивный разговор, как показано выше. Компилятор необходимо передать всю программу в файл, а затем запустить процесс перевода исходного кода высокого уровня на машинный язык а затем компилятор помещает полученный машинный язык в файл для последующего исполнения.
Если у вас есть система Windows, часто эти исполняемые машинные языки программы имеют суффикс «.H \ xe8 ….
Нелегко читать или писать на машинном языке, поэтому приятно, что мы иметь интерпретаторов и компиляторов , которые позволяют писать на языках высокого уровня, таких как Python или C.
Теперь, когда мы обсуждаем компиляторы и интерпретаторы, вы следует немного поинтересоваться самим интерпретатором Python. Какие на каком языке написано? Он написан на компилируемом языке? Когда мы типа «питон», что именно происходит?
Интерпретатор Python написан на языке высокого уровня под названием «C».Вы можете посмотреть фактический исходный код интерпретатора Python по перейдя на www.python.org и проложив свой путь к их исходный код. Итак, Python — это сама программа, и она скомпилирована в Машинный код. Когда вы установили Python на свой компьютер (или поставщик установил его), вы скопировали копию машинного кода переведенного Python программу в вашу систему. В Windows исполняемый машинный код для Сам Python, скорее всего, находится в файле с именем вроде:
Это больше, чем вам действительно нужно знать, чтобы быть программистом на Python, но иногда стоит ответить на эти мелкие назойливые вопросы прямо на начало.
Q-3: Сопоставьте каждый термин с его определением. Что означают эти термины?
Машинный язык
Язык программирования с использованием двоичных или шестнадцатеричных инструкций, на которые компьютер может напрямую отвечать.
Переводчик
Программа, которая анализирует и выполняет каждую строку кода.
Переменная
Элемент, который содержит значение во время работы программы.
Компилятор
Программа, преобразующая инструкции в машинный код, чтобы они могли быть прочитаны и выполнены компьютером.
В чем основные отличия
В этом руководстве объясняются основные различия между компилятором и интерпретатором, а также преимущества и работа компиляторов и интерпретаторов:
Здесь различия между компилятором и интерпретатором проиллюстрированы в табличной форме для лучшего понимания. В конце статьи мы рассмотрим преимущества компилятора перед интерпретатором. Мы также рассмотрим преимущества интерпретатора перед компилятором.
В этой статье также приведены ответы на некоторые часто задаваемые вопросы о компиляторах и интерпретаторах. Давайте начнем с понимания основной концепции.
Компилятор и интерпретатор: основные различия
Компьютерные программы написаны на понятных человеку языках, называемых языками высокого уровня. Некоторыми примерами языков высокого уровня являются C, Java, C ++ и т. Д. В этих языках используются слова английского языка, поэтому их легко выучить и использовать.
Однако инструкции, данные компьютеру на любом языке высокого уровня, не могут быть поняты компьютером напрямую. Это потому, что компьютер понимает только язык нулей и единиц (также называемый двоичным кодом).
Таким образом, код, написанный на любом из языков высокого уровня, необходимо преобразовать в машинно-понятный код, чтобы он был понят компьютером. Этот машинно-понятный код — не что иное, как язык, который понимает компьютер, и называется машинным языком.
Поскольку людям было бы очень сложно предоставлять инструкции на машинном языке, поэтому программы пишутся на языке высокого уровня, а затем конвертируются в машинный язык. Компиляторы и интерпретаторы — это компьютерные программы, которые преобразуют код, написанный на языке высокого уровня, в машинный язык.
Рекомендуемая литература = >> Основы компьютерного программирования
Что такое компилятор
Компиляторы — это программы, которые преобразуют код, написанный на языке программирования высокого уровня, в код машинного языка перед его выполнением.Это позволяет компьютеру понять инструкции, которые были даны ему через программный код. После перевода компьютер выполняет инструкции для создания желаемого результата.
Следует отметить, что для компилятора, чтобы скомпилировать код высокого уровня в код машинного языка, код не должен содержать ошибок. Однако, если в высокоуровневом коде есть синтаксическая ошибка, он останется таким, потому что компилятор не может идентифицировать или исправить эту ошибку.Таким образом, в этом случае скомпилированный код не будет сгенерирован.
Работа компилятора
Компилятор сразу переводит программу, написанную на языке высокого уровня, в машинно-понятный код.
Машинно-понятный код известен как объектный код.
Код объекта представляет собой комбинацию двоичного числа (0 и 1).
Программа, написанная на любом языке высокого уровня, также известна как исходная программа или программа, написанная в исходном коде.
Один и тот же объектный код может выполняться каждый раз, когда необходимо запустить высокоуровневую программу. Нет необходимости каждый раз компилировать программу, если не было изменений в исходном коде.
Из-за генерации промежуточного кода компиляторам требуется больший объем памяти.
Компиляторам требуется больше времени для анализа исходной программы.
Что касается общего выполнения программы, компиляторы обычно работают быстрее.
C и C ++ являются примерами языков, в которых исходная программа компилируется перед выполнением.
Что такое переводчик
Интерпретаторы — это также программы, которые преобразуют код, написанный на языке высокого уровня, в код машинного языка, однако это преобразование происходит во время выполнения кода. Таким образом, каждая строка кода преобразуется в машинный язык, который затем понимается компьютером и, наконец, выполняется, чтобы дать нам желаемый результат.
Пока интерпретатор преобразует программу высокого уровня в код машинного языка, любая ошибка, с которой он сталкивается в синтаксисе, отображается для строки кода перед переходом к следующей строке кода.
Работа переводчика
Интерпретатор переводит программу, написанную на языке высокого уровня, в машинно-понятный код по одной строке за раз во время выполнения программы.
При преобразовании программы в машинно-понятный код не генерируется промежуточный код.
Программа на языке высокого уровня, также известная как исходная программа, должна интерпретироваться каждый раз, когда программа должна быть выполнена.
Поскольку не создается промежуточный код, интерпретаторам не требуется большой объем памяти.
Интерпретаторам требуется меньше времени на анализ исходной программы, поскольку вся программа сразу не транслируется в машинный код.
Учитывая общее выполнение программы, интерпретаторы обычно работают медленно.
Javascript, PHP, Ruby и Perl — это примеры языков, в которых интерпретируется исходный код.
Компилятор против интерпретатора
В таблице ниже описаны основные различия между ними:
Преимущества: интерпретатор над компилятором
Преимущества интерпретатора перед компилятором приведены ниже:
Отладка интерпретируемой программы сравнительно проста, поскольку за один раз транслируется и выполняется одна строка кода.
Интерпретатор сообщает об ошибках для одной строки кода за раз, поскольку перевод и выполнение происходят одновременно.
Интерпретаторы
эффективно используют память, поскольку не происходит временного хранения транслированного кода, в отличие от компилятора, где объектный код временно хранится на диске.
Интерпретатор анализирует по одной строке за раз, поэтому ему требуется меньше времени для анализа исходной программы; Компилятор анализирует всю программу за один раз, поэтому для анализа требуется больше времени.
Преимущества: компилятор над интерпретатором
Преимущества компилятора над интерпретатором:
Поскольку компиляторы анализируют программу перед ее компиляцией, это обеспечивает выявление и исправление всех ошибок до того, как будет сгенерирован скомпилированный код.
Промежуточный код также известен как сгенерированный объектный код, который затем может использоваться каждый раз при запуске программы, что устраняет необходимость каждый раз компилировать исходную программу.
Компиляция программы обычно выполняется быстрее, чем ее интерпретация.
Часто задаваемые вопросы
Q # 1) В чем разница между компилятором и интерпретатором?
Ответ: Хотя компиляторы и интерпретаторы выполняют одну и ту же работу по переводу высокоуровневой программы на машинный язык, разница заключается в способе перевода. В случае компилятора вся программа преобразуется в машинный код за один раз, тогда как в случае интерпретатора трансляция происходит по одной строке кода за раз, при этом любая обнаруженная ошибка (ошибки) сообщается / сообщается одновременно.
Q # 2) Работает ли компилятор или интерпретатор быстрее?
Ответ: Трансляция кода с помощью компилятора выполняется быстрее по сравнению со временем трансляции, которое занимает интерпретатор для того же фрагмента кода.
Q # 3) Что такое компилятор и его типы?
Ответ: Компиляторы — это программы перевода, которые преобразуют программный код высокого уровня в код машинного языка, чтобы компьютер мог его понять. В зависимости от того, как происходит процесс перевода, компиляторы бывают следующих типов:
Однопроходные компиляторы
Двухпроходные компиляторы
Многопроходные компиляторы
Q # 4) Python — это компилятор или интерпретатор?
Ответ: Код Python интерпретируется, но перед интерпретацией исходный код сначала переводится в байт-код, который затем выполняется интерпретатором Python.Исходный код Python сохраняется в виде файла .py, который затем преобразуется в байт-код и сохраняется как расширение файла .pyc или .pyo .
Q # 5) Какие бывают три типа переводчиков
Ответ: Три типа переводчиков:
Компиляторы
Устные переводчики
Сборщики
Q # 6) Какие два типа низкоуровневого языка?
Ответ: Есть два типа языков низкого уровня:
Машинный язык
Язык ассемблера
Q # 7) В чем разница между компилятором и интерпретатором и ассемблером?
Ответ:
Компилятор: Это программа трансляции, которая преобразует полный программный код высокого уровня в машинный код за один раз.
Интерпретатор: Это также программа трансляции, которая преобразует полный программный код высокого уровня в машинный код, но по одной строке кода за раз.
Ассемблер: Это программа перевода, которая преобразует код, написанный на языке ассемблера, в машинный код.
Заключение
Мы надеемся, что эта статья помогла понять различия между интерпретаторами и компиляторами. В этой статье мы объяснили, зачем нужны компиляторы и интерпретаторы.В статье также были рассмотрены функции компиляторов и интерпретаторов.
Рекомендуемое чтение = >> Лучшие компиляторы Python
Для лучшего понимания мы представили различия между компилятором и интерпретатором в табличной форме. Также были кратко изложены преимущества компилятора перед интерпретатором. В то же время мы также объяснили преимущества интерпретатора перед компилятором.
Цель, типы, примеры и преимущества
Ресурсы переводчиков KS3 (14–16 лет)
Редактируемая презентация урока PowerPoint
Редактируемые раздаточные материалы для редакции
Глоссарий, который охватывает ключевые термины модуля
Тематические карты памяти для визуализации ключевые концепции
Печатные карточки, которые помогут учащимся активнее вспоминать и повторять уверенно
Редактируемая презентация урока в PowerPoint
Редактируемые раздаточные материалы для исправлений
Глоссарий, охватывающий ключевую терминологию модуля
Тематические карты разума для визуализации ключевых понятий
Печатные карточки, помогающие учащимся активнее вспоминать и повторять на основе уверенности
A викторина с сопровождающим ключом ответа для проверки знаний и понимания модуля
Переводчик — это процессор языка программирования, который преобразует компьютерную программу с одного языка на другой.Он берет программу, написанную в исходном коде, и преобразует ее в машинный код. Он обнаруживает и идентифицирует ошибку во время перевода.
Назначение переводчика
Он переводит программу на языке высокого уровня в программу на машинном языке, которую может понять центральный процессор (ЦП). Он также обнаруживает ошибки в программе.
Различные типы трансляторов
Существует 3 различных типа трансляторов, а именно:
Компилятор
Компилятор — это транслятор, используемый для преобразования языка программирования высокого уровня в язык программирования низкого уровня.Он конвертирует всю программу за один сеанс и сообщает об ошибках, обнаруженных после конвертации. Компилятору требуется время, чтобы выполнить свою работу, поскольку он сразу переводит код высокого уровня в код более низкого уровня, а затем сохраняет его в памяти.
Компилятор зависит от процессора и платформы. Но это было решено специальным компилятором, кросс-компилятором и компилятором от исходного кода к исходному. Перед выбором компилятора пользователь должен сначала определить архитектуру набора команд (ISA), операционную систему (ОС) и язык программирования, который будет использоваться для обеспечения его совместимости.
Интерпретатор
Как и компилятор, это транслятор, используемый для преобразования языка программирования высокого уровня в язык программирования низкого уровня. Он преобразует программу по очереди и сообщает об обнаруженных ошибках сразу во время преобразования. При этом легче обнаруживать ошибки, чем в компиляторе. Интерпретатор работает быстрее, чем компилятор, поскольку он немедленно выполняет код после прочтения кода.
Его часто используют в качестве инструмента отладки при разработке программного обеспечения, поскольку он может выполнять одну строку кода за раз.Интерпретатор также более портативен, чем компилятор, поскольку он не зависит от процессора, вы можете работать между аппаратными архитектурами.
Ассемблер
Ассемблер — это переводчик, используемый для перевода ассемблера на машинный язык. Он похож на компилятор для языка ассемблера, но интерактивен, как интерпретатор. Язык ассемблера сложно понять, поскольку это язык программирования низкого уровня. Ассемблер переводит язык низкого уровня, язык ассемблера, на язык еще более низкого уровня, которым является машинный код.Машинный код может быть понят непосредственно ЦП.
Примеры переводчиков
Вот несколько примеров переводчиков для каждого типа:
Переводчик Примеры
Компилятор Microsoft Visual Studio
Коллекция компиляторов GNU (GCC)
Общий бизнес-ориентированный язык (COBOL)
Интерпретатор OCaml
Обработка списков (LISP)
Python
Ассемблер Программа сборки Фортрана (FAP)
Программа сборки макросов (MAP)
Программа символьной оптимальной сборки (SOAP) и недостатки трансляторов
Вот некоторые преимущества компилятора:
Вся программа проверяется, поэтому системные ошибки отсутствуют.
Исполняемый файл усовершенствован компилятором, поэтому он работает быстрее.
Пользователю не нужно запускать программу на том же компьютере, на котором она была создана.
Вот некоторые недостатки компилятора:
Он медленно выполняется, так как вам нужно завершить всю программу.
Отладить непросто, поскольку ошибки отображаются в конце выполнения.
Специфично для оборудования, работает на определенном машинном языке и архитектуре.
Вот некоторые преимущества интерпретатора:
Вы обнаруживаете ошибки еще до завершения программы, поэтому вы учитесь на своих ошибках.
Программу можно запустить до ее завершения, поэтому вы сразу получите частичные результаты.
Вы можете работать с небольшими частями программы, а позже связать их в целую программу.
Вот некоторые недостатки Интерпретатора:
Возможны синтаксические ошибки на непроверенных скриптах.
Программа не усовершенствована и могут возникать ошибки данных.
Это может быть медленным из-за интерпретации при каждом выполнении.
Вот некоторые преимущества Ассемблера:
Символьное программирование легче понять, что экономит время для программиста.
Легче исправить ошибки и изменить инструкции программы.
Эффективность исполнения такая же, как у машинного языка.
Вот некоторые недостатки Ассемблера:
Он машинно-зависимый, не может использоваться в другой архитектуре.
Небольшое изменение дизайна может сделать всю программу недействительной.
Сложно обслуживать.
Более глубокий анализ компиляции и интерпретации | от Вайдехи Джоши | basecs
Более глубокий анализ компиляции vs.интерпретация
Возможно, нет ничего более приятного, чем видеть, как кусочки головоломки соединяются вместе. Так обстоит дело с настоящими головоломками, с которыми я довольно плохо разбираюсь, потому что я всегда теряю кусочки под диваном, и с более метафорическими головоломками, которые я обычно лучше решаю, когда не теряю кусочков в незнакомых местах.
Загадка обучения, безусловно, одна из наиболее сложных загадок. Изучать что-то новое сложно, потому что вы постоянно пытаетесь объединить идеи и конструировать концепции, не всегда зная, как эти части вписываются в единое целое.Может быть трудно попытаться осмыслить что-то новое, когда вы постоянно задаетесь вопросом, какое отношение это новое имеет к более широкой картине, с которой вы уже знакомы. Это немного похоже на поиск случайного кусочка пазла, а затем попытку найти части, которые подходят для него, но не обязательно знать, как эти кусочки вписываются в общую картину.
То же самое верно и для изучения определенной темы, например, информатики. Часто может казаться, что вы собираете немного информации — структуру данных здесь, алгоритм там — не всегда зная, как одна часть соединяется с другой.Я склонен думать, что это причина того, почему изучать информатику так сложно: просто не так много ресурсов, которые могут построить картину поля, в которой все эти идеально сочетающиеся друг с другом части.
Однако время от времени, если вы действительно достаточно долго придерживаетесь какой-либо темы, вы обнаружите, что некоторые части начинают сливаться. И когда мы вместе завершим эту серию, настало время, чтобы это наконец произошло!
Когда мы впервые начали эту серию почти год назад, самой первой темой, которую мы исследовали, было то, что часто считается «краеугольным камнем» информатики: двоичный код.Мы узнали, что по своей сути двоичный код — это язык, на котором говорит и понимает каждый компьютер. В конце концов, каждая из наших машин работает с нулями и единицами.
С тех пор мы исследовали различные структуры данных, такие как деревья, графы и связанные списки, а также алгоритмы сортировки и алгоритмы обхода или поиска. Пришло время, наконец, собрать все воедино — или, скорее, вернуть все обратно в двоичную систему.
Мы начали с исходного кода, и теперь мы здесь.
Мы объехали весь мир, когда дело доходит до основных концепций вычислений, а также информатики. Но есть один вопрос, на который мы еще не ответили, хотя вполне возможно, что мы думали об этом весь год: как, черт возьми, мы переходим от нашего кода к единицам и нулям нашего компьютера?
Что ж, прежде чем мы углубимся в , как код , который мы пишем, превращается в двоичный, давайте проясним, что мы на самом деле имеем в виду, когда используем термин двоичный в этом контексте.«Двоичный» код, который компьютер читает и понимает, обычно называется машинным языком или машинным кодом , который представляет собой набор инструкций, отдаваемых машине и выполняемых ее центральным процессором . (или CPU ).
Важно отметить, что существуют разные виды машинного кода, некоторые из которых представляют собой буквально 0 и 1, а другие — десятичные или шестнадцатеричные (о которых мы уже много знаем!).Независимо от того, в каком именно формате написан машинный язык, он должен быть довольно элементарным, потому что он должен быть понят компьютером или понятен. Вот почему машинные языки называются языками низкого уровня, потому что они должны быть достаточно упрощены, чтобы обрабатываться центральным процессором нашей машины, который, как мы уже знаем, представляет собой всего лишь набор внутренних переключателей.
Мы можем думать о языках низкого уровня как о «родных языках» нашего компьютера; машинный код должен быть непосредственно читаемым на нашей машине и никогда не должен быть им переведен.
Но как перейти от нашего кода к машинно-дружественной ( машинный код ) версии того же самого? Что ж, код, который мы пишем как программисты, и машинный код, который считывает процессор компьютера, — это не что иное, как два разных типа языков . Если задуматься, все, что нам действительно нужно, — это переводить между этими двумя языками.
Теперь возникает другая проблема: мы не знаем, как переводить наш код в машинный код! Ладно, шучу — это не , на самом деле проблема.Потому что у нас есть два полезных друга, которые могут нам здесь помочь.
Переводчики делают наш исходный текст понятным для наших машин!
Чтобы преобразовать исходный код в некоторый машиночитаемый машинный код в двоичном формате, нам нужно будет положиться на переводчиков, которые помогут нам сделать исходный текст понятным для наших машин.
Транслятор , который также иногда называют процессором языка программирования, является не чем иным, как программой, которая переводит исходный язык на целевой язык , сохраняя при этом логическую структуру код, который он переводит.
Мы уже немного знакомы с одним видом переводчика, хотя, возможно, еще не знаем его. Ранее в этой серии статей мы рассмотрели этапы лексического и синтаксического анализа (передняя часть) компилятора, а также различные структуры данных, участвующие в процессе.
Как оказалось, компилятор — это вид переводчика ! Есть еще один переводчик, имя которого часто упоминается вместе с именем компилятора, это интерпретатор .И компилятор, и интерпретатор делают код читаемым для наших компьютеров, но совершенно по-разному.
Но давайте сначала начнем с того, что мы уже знаем: компилятора.
Компилятор: определение.
Компилятор — это не что иное, как программа, которая берет язык высокого уровня — язык, на котором мы пишем наш код — и преобразует его в машинный код. У компилятора есть много движущихся частей (или, скорее, внутри него), включая, возможно, сканер, лексер / токенизатор и синтаксический анализатор.Но в конце концов, даже несмотря на свою сложность, это всего лишь программа, которая превращает наш код в машиночитаемый код.
Однако, несмотря на то, что его работа может показаться простой в такой форме, стоит выделить способ, которым компилятор выполняет эту важную задачу.
Как компилятор выполняет свою работу.
В большинстве случаев компилятор выполняет работу по преобразованию нашего кода в машинный код одним махом. Другими словами, компилятор переводит весь исходный код программиста до того, как исходный код может быть выполнен или запущен.Он берет наш исходный код и преобразует его в один файл, написанный в машинном коде. Это тот самый файл машинного кода, называемый исполняемым файлом и часто заканчивающийся расширением .exe , который фактически позволяет нам запускать исходный код, который мы написали.
Самая важная особенность компилятора — это тот факт, что он берет исходный текст и переводит его в двоичный машинный код «за один раз». Он возвращает переведенный, скомпилированный файл программисту, который сможет запустить свой код через полученный исполняемый файл.
Исполняемый файл, возвращаемый компилятором, может запускаться снова и снова после того, как он был переведен; компилятор не нужен для последующих повторных запусков!
После того, как компилятор преобразует весь исходный код в машинный код, работа компилятора завершена. Программист может запускать скомпилированный код столько раз, сколько хочет, с любыми входными данными, которые он хочет использовать. Они также могут делиться этим скомпилированным кодом с другими, без необходимости делиться своим исходным кодом.
Грейс Хоппер, © TechCrunch
Концепция этого конкретного переводчика — как и сам термин «компилятор» — была придумана знаменитой Грейс Хоппер еще в 1952 году при самых интересных обстоятельствах.
В то время Хоппер работал в Eckert-Mauchly Computer Corporation, помогая в разработке компьютера UNIVAC I в качестве математика в команде. По сути, она работала над превращением математического кода в собственный язык (язык системы A-0).
Однако у нее были идеи посерьезнее. Она хотела написать совершенно новый язык программирования, который бы использовал слова на английском языке, а не ограниченное количество математических символов. Однако когда она поделилась этой идеей со своими коллегами. Они застрелили ее и сказали, что ее идея невозможна, потому что «компьютеры не понимают английского». Но ее это не остановило.
После трех лет работы в этой команде Хоппер получила свой первый работающий компилятор. Но никто не поверил, что она действительно это сделала! В своей биографии Grace Hopper: Navy Admiral and Computer Pioneer она объясняет:
У меня был работающий компилятор, и никто не хотел его трогать.… Они осторожно сказали мне, что компьютеры могут делать только арифметические операции; они не умели делать программы.
Хорошо, что Грейс Хоппер не слушала ни одного из этих неверующих, потому что в конечном итоге она продолжила свою работу и разработала один из первых языков программирования высокого уровня, названный COBOL. Она также выиграла президентскую медаль свободы, среди многих, многих, многих других достижений.
В самом деле, если бы она прослушала всех этих людей, она, вероятно, никогда бы не подняла вычисления на совершенно новый уровень с ее ранней работой по созданию и проектированию самого первого компилятора.Работа Грейс Хоппер над первым компилятором заложила основу для другого переводчика, появившегося несколько лет спустя: интерпретатора.
В 1958 году, через несколько лет после работы Грейс Хоппер над компилятором, некоторые студенты Массачусетского технологического института были в лаборатории, работая с компьютером IBM 704, довольно новой технологией, которая была представлена всего четырьмя годами ранее. Один из этих студентов, Стив Рассел, вместе со своим профессором Джоном Маккарти работал над проектом под названием MIT Artificial Intelligence Project.
Рассел в то время работал с языком программирования Lisp, и он прочитал статью, написанную его профессором на эту тему. Ему пришла в голову идея преобразовать функцию eval в Лиспе в машинный код, что поставило его на путь создания первого интерпретатора Лиспа, который использовался для оценки выражений на языке - эквивалент запуска программы на Лиспе. в то время.
Стив Рассел, © mass: werk Действительно, работа Хоппера напрямую повлияла на изобретение Рассела.Первая версия интерпретатора Лиспа была скомпилирована вручную. В интервью Музею истории компьютеров в 2008 году Рассел объясняет, как компиляторы сыграли в его работе в Массачусетском технологическом институте: И я помню, что Джон [Маккарти] как бы приехал в один прекрасный день, в конце сентября или в октябре или что-то вроде этого, что с универсальным M-выражением, то есть интерпретатором Лиспа, записанным как M-выражение, и мы как бы посмотрели на него и сказали: «О да, это сработает», и я посмотрел на него и сказал: « О, это просто вопрос ручной компиляции, как это делал я.Я могу это сделать ». … Перед Рождеством у меня кое-что работало, это был полезный переводчик; нет сборщика мусора, но больших программ еще не было. Рассел и его коллеги собирались вручную скомпилировать первые две версии интерпретатора Лиспа. Сегодня большинство программистов даже не мечтают о компиляции кода вручную! Действительно, многие из нас взаимодействуют с интерпретатором и многократно используют его при разработке приложений - просто мы не всегда можем знать об этом. Итак, что именно - это интерпретатор? Пришло время дать официальное определение! Интерпретатор: определение. Интерпретатор также является переводчиком, как и компилятор, в том смысле, что он принимает язык высокого уровня (наш исходный текст) и преобразует его в машинный код. Однако он делает что-то немного другое: он фактически запускается, и выполняет код, который он переводит немедленно (встроенный) по мере его перевода. Мы можем думать о переводчике как о более «методичном» переводчике в семье.Вместо того, чтобы выполнять работу по переводу нашего кода на машинный язык за один раз, мы гораздо более систематизировали то, как он работает. Переводчик выполняет свою работу по частям. Он будет переводить часть нашего исходного текста за раз, а не переводить все сразу. Как переводчик выполняет свою работу. В отличие от компилятора, он не переводит все и не передает файл нам, программистам, для исполнения. Вместо этого интерпретатор будет переводить одну строку / раздел кода за раз.После того, как он завершит перевод одной строки, он возьмет ее версию с машинным кодом и немедленно запустит. Другой способ мышления заключается в том, что после того, как фрагмент кода был переведен интерпретатором, только тогда он может быть запущен. На первый взгляд это кажется довольно интуитивным, потому что, конечно, как интерпретатор может запустить строку кода, не зная, что это означает в двоичном / машинном коде? Но если мы подумаем об этом более глубоко, есть и другие последствия. Только после того, как интерпретатор успешно завершит выполнение одной строки кода, он фактически перейдет к следующей строке.Мы можем представить, насколько это может быть хорошо, а может и нет, в зависимости от того, что мы пытаемся сделать. Например, представьте, что мы хотим запустить нашу программу с 10 различными входами. Нашему интерпретатору пришлось бы запускать нашу программу 10 раз, интерпретируя ее построчно, для каждого из наших входных данных. Однако, если мы допустили фатальную ошибку в нашем коде, наш интерпретатор мог бы уловить ее для нас в тот момент, когда это произошло, потому что он буквально просто попытался запустить нашу (сломанную) строку кода после ее перевода! К настоящему времени мы могли бы начать видеть, как и у интерпретатора, и у компилятора есть компромиссы.В этой серии мы неоднократно видели, как разные инструменты имеют свои плюсы и минусы, и, вероятно, это отличительная черта в мире информатики. Продолжая эту тему, давайте взвесим фундаментальные различия между интерпретацией и компиляцией как методами перевода. Различия между интерпретацией и компиляцией и соответствующими трансляторами многое говорят нам о том, как реализованы эти две программы. Если мы сравним эти две методологии, мы начнем видеть, как они обе решают одну и ту же задачу, но принципиально разными способами. Иллюстрация ниже иллюстрирует это более наглядно. Компиляция против интерпретации: компромиссы. Возвращенный результат. В то время как компилятор берет некоторый исходный код и возвращает скомпилированный исполняемый файл, интерпретатор фактически переводит, а затем выполняет сам исходный код, возвращая результат перевода напрямую. Рабочая частота. Компилятор будет запущен только один раз, и его нужно будет вызвать снова, чтобы повторно транслировать исходный код, если он изменится.С другой стороны, интерпретатор снова запустится и переинтерпретирует исходный код при его изменении; переводчик «остается», чтобы постоянно переводить. Гибкость. Компилятор переводит исходный код за один раз, что означает, что исходный код больше не требуется после компиляции. Однако интерпретатору требуется исходный код для перевода и выполнения программы каждый раз, когда она запускается. Отладка. Компилятор обычно затрудняет определение ошибок в исходном коде, потому что вся программа уже переведена, и местоположение ошибки может быть нелегко идентифицировать в машинном коде. Однако с помощью интерпретатора выявлять ошибки проще, потому что он может определить местонахождение ошибки или ошибки и выявить эту проблему для программиста, написавшего код. Из-за этих основных различий скомпилированный код - код, который транслируется и запускается с использованием процесса компиляции - имеет тенденцию запускаться на бит быстрее , чем интерпретируемый код.Это связано с тем, что работа по переводу исходного текста в машинный код уже была сделана еще до того, как код когда-либо был выполнен. Скомпилированный код по сравнению с интерпретируемым кодом. С другой стороны, интерпретируемый код намного больше гибкий , поскольку интерпретатор остается в течение всего «процесса» перевода, чтобы читать и обрабатывать наш код. Гибкость в этом контексте означает возможность изменять наш код и сразу же запускать его после этого.Если мы внесем изменения, нет необходимости перекомпилировать наш код; интерпретатор просто воспользуется этой возможностью и переинтерпретирует код, сделав его гораздо более интерактивной формой перевода . Использование интерпретатора значительно упрощает проверку небольших (или больших!) Изменений в исходном файле. Преимущества компиляции по сравнению с интерпретацией. Однако, когда дело доходит до интерпретации, нам действительно нужен исходный код, чтобы иметь возможность делать что угодно. Определенно легче проверить изменения и отладить проблемы, но в первую очередь должен быть доступен исходный текст.В случае компиляции это не так. После того, как мы скомпилировали наш код в исполняемый файл, нам больше не нужно беспокоиться об исходном коде - если, конечно, нам не нужно перекомпилировать. Это часто может сделать компилятор «более безопасным» выбором, потому что наш исходный код не отображается; скорее, единственный выход - это сам исполняемый файл, который состоит только из 1 и 0, и никому не показывает , как мы написали наш код или что на самом деле сказал , поскольку на тот момент все это был машинный язык. Компиляция и интерпретация играют нашу роль не только как разработчики программного обеспечения, но и как его потребители. Простота и скорость компиляции в действии. Например, всякий раз, когда мы загружаем файл или запускаем программу из файла .exe , мы полагаемся на то, что создатели некоторого программного обеспечения скомпилировали для нас исполняемый файл. Используя компиляцию, мы можем легко распространять программу в виде исполняемого файла. Это позволит кому-то другому запускать тот же код, что и мы, но никогда не показывать им и не передавать им сам буквальный код.Потребителю скомпилированного файла никогда не нужно видеть исходный текст, потому что ему просто может быть предоставлен исполняемый файл для запуска на их собственной локальной машине. Однако проблема с распространением скомпилированного файла заключается в создании файлов, совместимых на разных платформах (например, в операционной системе Windows и OS X). Наша задача как программистов - убедиться, что наши скомпилированные исполняемые файлы успешно работают на различных платформах, а иногда это означает перекомпиляцию нашего кода! Эффективность и преимущества интерпретации в действии. С другой стороны, когда мы используем интерпретацию, мы можем распространять наш исходный код напрямую, вместо того, чтобы беспокоиться о специфичных для платформы исполняемых файлах или думать о том, как мы будем собирать двоичные файлы для использования всеми. Однако в этом случае нам потребуется, чтобы потребитель нашей программы загрузил интерпретатор - который часто на самом деле просто идет вместе с языком - и был уверен, что интерпретатор существует на их машине (ах). Получив интерпретатор, они смогут увидеть наш исходный исходный код, взять этот код, а затем полагаться на свою версию интерпретатора для его локального запуска. В этом сценарии мы полагаемся на интерпретатор для обеспечения совместимости на всех платформах, и нам, как программистам и потребителям, не нужно об этом думать. Кроме того, если что-то пойдет не так (либо что-то в исходном коде, которое мы написали, либо что-то, относящееся к его собственной платформе), потребитель нашего кода может выяснить, в чем проблема, гораздо легче, чем с помощью скомпилированного файла. Интерпретатор упростит отладку любых проблем, независимо от того, кто запускает наш код. Но, независимо от того, выбираем ли мы компиляцию или интерпретацию, конечная цель одна: говорить на языке, понятном нашим компьютерам! Как оказалось, в конце концов, на самом деле все являются двоичными кодами . Author: alexxlab Навигация по записям ← История возникновения экономики как науки: История развития экономической науки Банк огэ 2018: Открытый банк заданий ОГЭ → Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт Search for: Рубрики Биология География Гиа Егэ Информатика История Математика Обществознание Огэ Подготовка к ГИА Подготовка к ЕГЭ Подготовка к ОГЭ Подготовка Фипи Разное Русский Советы по обучению Уроки биологии Уроки географии Уроки информатики Уроки истории Уроки математики Уроки обществознания Уроки русского Уроки физики Уроки химии Физика Фипи Химия 2019 © Все права защищены. Карта сайта