Jump to content

Переводчик (компьютерный)

(Перенаправлено с Оценщика )
Интерпретатор W3sDesign Шаблон проектирования UML

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

  1. Разобрать исходный код и напрямую выполнить его поведение;
  2. Перевести исходный код в какое-нибудь эффективное промежуточное представление или объектный код и немедленно выполнить его;
  3. Явное выполнение сохраненного предварительно скомпилированного байт-кода [1] созданный компилятором и интерпретатора сопоставленный с виртуальной машиной .

Ранние версии языка программирования Lisp и диалектов BASIC для мини- и микрокомпьютеров могут быть примерами первого типа. Perl , Raku , Python , MATLAB и Ruby являются примерами второго типа, а UCSD Pascal — примером третьего типа. Исходные программы компилируются заранее и сохраняются как машинно-независимый код, который затем компонуется во время выполнения и выполняется интерпретатором и/или компилятором (для JIT систем ). Некоторые системы, такие как Smalltalk и современные версии BASIC и Java , также могут сочетать два и три типа. [2] Интерпретаторы различных типов также были созданы для многих языков, традиционно связанных с компиляцией, таких как Algol , Fortran , Cobol , C и C++ .

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

Интерпретаторы использовались еще в 1952 году для облегчения программирования в рамках ограничений компьютеров того времени (например, нехватки места для хранения программ или отсутствия встроенной поддержки чисел с плавающей запятой). Интерпретаторы также использовались для перевода между машинными языками низкого уровня, что позволяло писать код для машин, которые все еще находились в стадии разработки, и тестироваться на уже существовавших компьютерах. [3] Первым интерпретируемым языком высокого уровня был Lisp . Lisp был впервые реализован Стивом Расселом на компьютере IBM 704 . Рассел прочитал статью Джона Маккарти «Рекурсивные функции символьных выражений и их машинное вычисление, часть I» и понял (к удивлению Маккарти), что функция eval в Лиспе может быть реализована в машинном коде. [4] Результатом стал работающий интерпретатор Лиспа, который можно было использовать для запуска программ на Лиспе или, точнее, «оценки выражений Лиспа».

Общая операция

[ редактировать ]

Интерпретатор обычно состоит из набора известных команд, которые он может выполнять , и списка этих команд в том порядке, в котором программист желает их выполнить. Каждая команда (также известная как Инструкция ) содержит данные, которые программист хочет изменить, и информацию о том, как изменить данные. Например, переводчик может прочитать ADD Books, 5 и интерпретировать это как просьбу добавить пять к Books переменная .

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

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

[ редактировать ]
Иллюстрация процесса связывания. Объектные файлы и статические библиотеки собираются в новую библиотеку или исполняемый файл.

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

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

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

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

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

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

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

Цикл разработки

[ редактировать ]

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

Распределение

[ редактировать ]

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

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

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

Эффективность

[ редактировать ]

Основным недостатком интерпретаторов является то, что интерпретируемая программа обычно работает медленнее, чем если бы она была скомпилирована . Разница в скоростях могла быть крошечной или большой; часто на порядок, а иногда и больше. Обычно запуск программы под интерпретатором занимает больше времени, чем запуск скомпилированного кода, но ее интерпретация может занять меньше времени, чем общее время, необходимое для ее компиляции и запуска. Это особенно важно при прототипировании и тестировании кода, когда цикл редактирования-интерпретации-отладки часто может быть намного короче, чем цикл редактирования-компиляции-запуска-отладки. [6] [7]

Интерпретация кода выполняется медленнее, чем запуск скомпилированного кода, поскольку интерпретатор должен анализировать каждый оператор в программе каждый раз, когда он выполняется, а затем выполнять желаемое действие, тогда как скомпилированный код просто выполняет действие в фиксированном контексте, определенном компиляцией. Этот анализ во время выполнения известен как «накладные расходы интерпретации». Доступ к переменным в интерпретаторе также медленнее, поскольку сопоставление идентификаторов с местами хранения должно выполняться неоднократно во время выполнения, а не во время компиляции . [6]

Существуют различные компромиссы между скоростью разработки при использовании интерпретатора и скоростью выполнения при использовании компилятора. Некоторые системы (например, некоторые Lisps ) позволяют интерпретируемому и скомпилированному коду вызывать друг друга и совместно использовать переменные. Это означает, что после того, как программа протестирована и отлажена в интерпретаторе, ее можно скомпилировать и, таким образом, получить выгоду от более быстрого выполнения, пока разрабатываются другие процедуры. [ нужна ссылка ] Многие интерпретаторы не выполняют исходный код в его нынешнем виде, а преобразуют его в более компактную внутреннюю форму. Многие интерпретаторы BASIC заменяют ключевые слова однобайтовыми , токенами которые можно использовать для поиска инструкции в таблице переходов . [6] Некоторые интерпретаторы, такие как интерпретатор PBASIC , достигают еще более высокого уровня сжатия программы за счет использования побитовой, а не байтовой структуры памяти программы, где токены команд занимают около 5 бит, номинально хранятся «16-битные» константы. в коде переменной длины, требующем 3, 6, 10 или 18 бит, а операнды адреса включают «битовое смещение». Многие интерпретаторы BASIC могут хранить и считывать свое собственное токенизированное внутреннее представление.

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

Регрессия

[ редактировать ]

Интерпретацию нельзя использовать в качестве единственного метода выполнения: хотя интерпретатор сам по себе может быть интерпретирован и т. д., где-то в самом низу стека необходима непосредственно исполняемая программа, поскольку интерпретируемый код по определению не является тем же самым, что и интерпретируемый код. машинный код, который может выполнить ЦП. [8] [9]

Вариации

[ редактировать ]

Интерпретаторы байт-кода

[ редактировать ]

Существует целый спектр возможностей интерпретации и компиляции, в зависимости от объема анализа, выполняемого перед выполнением программы. Например, Emacs Lisp скомпилирован в байт-код , который представляет собой сильно сжатое и оптимизированное представление исходного кода Lisp, но не является машинным кодом (и, следовательно, не привязан к какому-либо конкретному оборудованию). Этот «скомпилированный» код затем интерпретируется интерпретатором байт-кода (сам написанным на C ). Скомпилированный код в данном случае является машинным кодом виртуальной машины , который реализован не аппаратно, а в интерпретаторе байт-кода. Такие компилирующие интерпретаторы иногда также называют компретерами . [10] [11] В интерпретаторе байт-кода каждая инструкция начинается с байта, поэтому интерпретаторы байт-кода имеют до 256 инструкций, хотя не все из них можно использовать. Некоторые байт-коды могут занимать несколько байтов и быть сколь угодно сложными.

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

Потоковые интерпретаторы кода

[ редактировать ]

Интерпретаторы потокового кода аналогичны интерпретаторам байт-кода, но вместо байтов они используют указатели. Каждая «инструкция» представляет собой слово, указывающее на функцию или последовательность инструкций, за которым, возможно, следует параметр. Интерпретатор многопоточного кода либо выполняет выборку инструкций и вызывает функции, на которые они указывают, либо извлекает первую инструкцию и переходит к ней, и каждая последовательность инструкций заканчивается выборкой и переходом к следующей инструкции. В отличие от байт-кода, здесь нет эффективного ограничения на количество различных инструкций, кроме доступной памяти и адресного пространства. Классическим примером многопоточного кода является код Форта , используемый в системах с открытой прошивкой : исходный язык компилируется в «F-код» (байт-код), который затем интерпретируется виртуальной машиной . [ нужна ссылка ]

Интерпретаторы абстрактного синтаксического дерева

[ редактировать ]

В диапазоне между интерпретацией и компиляцией другой подход заключается в преобразовании исходного кода в оптимизированное абстрактное синтаксическое дерево (AST), затем выполнение программы в соответствии с этой древовидной структурой или использование ее для генерации собственного кода « точно в срок» . [12] При таком подходе каждое предложение необходимо анализировать только один раз. Преимущество по сравнению с байт-кодом заключается в том, что AST сохраняет глобальную структуру программы и отношения между операторами (которые теряются в представлении байт-кода), а при сжатии обеспечивает более компактное представление. [13] Таким образом, использование AST было предложено как лучший промежуточный формат для JIT-компиляторов, чем байт-код. Кроме того, это позволяет системе выполнять лучший анализ во время выполнения.

Однако для интерпретаторов AST вызывает больше накладных расходов, чем интерпретатор байт-кода, из-за узлов, связанных с синтаксисом, не выполняющих полезной работы, менее последовательного представления (требующего обхода большего количества указателей) и накладных расходов при посещении дерева. [14]

Компиляция точно в срок

[ редактировать ]

Еще больше стирает различие между интерпретаторами, интерпретаторами байт-кода и компиляцией JIT-компиляция, метод, при котором промежуточное представление компилируется в собственный машинный код во время выполнения. Это обеспечивает эффективность выполнения собственного кода за счет времени запуска и увеличения использования памяти при первой компиляции байт-кода или AST. Самый ранний опубликованный JIT-компилятор обычно приписывают работе над LISP Джоном Маккарти в 1960 году. [15] Адаптивная оптимизация — это дополнительный метод, при котором интерпретатор профилирует работающую программу и компилирует ее наиболее часто выполняемые части в собственный код. Последнему методу уже несколько десятилетий, и он появился в таких языках, как Smalltalk, в 1980-х годах. [16]

В последние годы компиляция «точно в срок» привлекла всеобщее внимание разработчиков языков: Java , .NET Framework , большинство современных реализаций JavaScript и Matlab теперь включают JIT-компиляторы. [ нужна ссылка ]

Интерпретатор шаблонов

[ редактировать ]

Еще более размытым различие между компиляторами и интерпретаторами делает специальная конструкция интерпретатора, известная как интерпретатор шаблона. Вместо того, чтобы реализовывать выполнение кода с помощью большого оператора переключения, содержащего все возможные байт-коды, при работе со стеком программного обеспечения или обходом дерева, интерпретатор шаблонов поддерживает большой массив байт-кода (или любое эффективное промежуточное представление), сопоставленный непосредственно с соответствующим собственные машинные инструкции, которые могут выполняться на аппаратном обеспечении хоста как пары ключ-значение (или, в более эффективных конструкциях, прямые обращения к собственным инструкциям), [17] [18] известный как «Шаблон». Когда конкретный сегмент кода выполняется, интерпретатор просто загружает или переходит к отображению кода операции в шаблоне и напрямую запускает его на оборудовании. [19] [20] Благодаря своей конструкции интерпретатор шаблонов очень сильно напоминает JIT-компилятор, а не традиционный интерпретатор, однако технически он не является JIT-компилятором, поскольку он просто переводит код с языка на собственный, вызывает один код операции за раз. время, а не создавать оптимизированные последовательности исполняемых инструкций ЦП из всего сегмента кода. Благодаря простой конструкции интерпретатора, заключающейся в простой передаче вызовов непосредственно аппаратному обеспечению, а не их реализации напрямую, он намного быстрее, чем любой другой тип, даже интерпретаторы байт-кода, и в некоторой степени менее подвержен ошибкам, но в качестве компромисса его труднее реализовать. поддерживаться из-за того, что интерпретатору приходится поддерживать перевод на несколько различных архитектур вместо независимой от платформы виртуальной машины/стека. На сегодняшний день единственными существующими реализациями интерпретатора шаблонов широко известных языков являются интерпретатор официальной эталонной реализации Java, виртуальная машина Java Sun HotSpot. [17] и интерпретатор Ignition в механизме выполнения javascript Google V8.

Самопереводчик

[ редактировать ]

Самоинтерпретатор — это интерпретатор языка программирования, написанный на языке программирования, который может интерпретировать сам себя; примером является интерпретатор BASIC, написанный на BASIC. Самоинтерпретаторы связаны с самостоятельными компиляторами .

Если для интерпретируемого языка не существует компилятора , создание самоинтерпретатора требует реализации языка на основном языке (который может быть другим языком программирования или ассемблером ). Имея такой первый интерпретатор, система загружается , и новые версии интерпретатора могут быть разработаны на самом языке. Именно таким образом Дональд Кнут разработал интерпретатор TANGLE для языка WEB де-факто стандартной TeX системы набора текста .

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

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

Некоторые языки, такие как Лисп и Пролог, имеют элегантные самоинтерпретаторы. [21] Много исследований самоинтерпретаторов (особенно рефлексивных интерпретаторов) было проведено на языке программирования Scheme , диалекте Lisp. Однако в целом любой тьюринг-полный язык позволяет написать собственный интерпретатор. Lisp является таким языком, потому что программы Lisp представляют собой списки символов и другие списки. XSLT является таким языком, поскольку программы XSLT написаны на XML. Подобластью метапрограммирования является написание предметно-ориентированных языков (DSL).

Клайв Гиффорд представил [22] мера качества самоинтерпретатора (собственное отношение), предел отношения между компьютерным временем, затраченным на запуск стека из N самоинтерпретаторов, и временем, затраченным на запуск стека из N - 1 самоинтерпретаторов, когда N стремится к бесконечности. Это значение не зависит от запускаемой программы.

В книге «Структура и интерпретация компьютерных программ» представлены примеры метациклической интерпретации схемы и ее диалектов. Другими примерами языков с самоинтерпретатором являются Форт и Паскаль .

Микрокод

[ редактировать ]

Микрокод — это очень часто используемый метод, «который устанавливает интерпретатор между аппаратным обеспечением и архитектурным уровнем компьютера». [23] По сути, микрокод представляет собой слой инструкций аппаратного уровня, которые реализуют инструкции машинного кода более высокого уровня или внутреннюю последовательность конечных автоматов во многих элементах цифровой обработки . Микрокод используется в центральных процессорах общего назначения , а также в более специализированных процессорах, таких как микроконтроллеры , процессоры цифровых сигналов , контроллеры каналов , контроллеры дисков , контроллеры сетевых интерфейсов , сетевые процессоры , графические процессоры и в другом оборудовании.

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

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

Компьютерный процессор

[ редактировать ]

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

Понимание производительности переводчика

[ редактировать ]

Интерпретаторы, например, написанные на Java, Perl и Tcl, теперь необходимы для широкого спектра вычислительных задач, включая бинарную эмуляцию и интернет-приложения. Производительность интерпретаторов по-прежнему вызывает беспокойство, несмотря на их адаптивность, особенно в системах с ограниченными аппаратными ресурсами. Усовершенствованные подходы к инструментированию и отслеживанию позволяют получить представление о реализациях интерпретаторов и использовании ресурсов процессора во время выполнения посредством оценки интерпретаторов, адаптированных для набора команд MIPS и языков программирования, таких как Tcl, Perl и Java. На характеристики производительности влияет сложность интерпретатора, о чем свидетельствуют сравнения с скомпилированным кодом. Понятно, что производительность интерпретатора в большей степени зависит от нюансов и потребностей интерпретатора в ресурсах, чем от конкретного интерпретируемого приложения.

Приложения

[ редактировать ]
  • Интерпретаторы часто используются для выполнения командных языков и связующих языков, поскольку каждый оператор, выполняемый на командном языке, обычно представляет собой вызов сложной процедуры, такой как редактор или компилятор. [ нужна ссылка ]
  • Самомодифицирующийся код можно легко реализовать на интерпретируемом языке. Это связано с истоками интерпретации в Лиспе и исследованиями искусственного интеллекта . [ нужна ссылка ]
  • Виртуализация . Машинный код, предназначенный для аппаратной архитектуры, можно запускать с помощью виртуальной машины . Это часто используется, когда предполагаемая архитектура недоступна или, среди прочего, для запуска нескольких копий.
  • Песочница . Хотя некоторые типы песочниц полагаются на защиту операционной системы, часто используется интерпретатор или виртуальная машина. Фактическая аппаратная архитектура и первоначально запланированная аппаратная архитектура могут совпадать, а могут и не совпадать. Это может показаться бессмысленным, за исключением того, что песочницы не обязаны фактически выполнять все инструкции обрабатываемого исходного кода. В частности, он может отказаться выполнять код, который нарушает любые ограничения безопасности , в которых он работает. [ нужна ссылка ]
  • Эмуляторы для запуска компьютерных программ, написанных для устаревшего и недоступного оборудования, на более современном оборудовании.

См. также

[ редактировать ]
  1. ^ В этом смысле ЦП также является интерпретатором машинных инструкций.
  2. ^ Хотя эта схема (объединяющая стратегии 2 и 3) использовалась для реализации некоторых интерпретаторов BASIC уже в 1970-х годах, например, эффективного интерпретатора BASIC ABC 80 .
  3. ^ Беннетт, Дж. М.; Принц, Д.Г.; Вудс, МЛ (1952). «Интерпретационные подпрограммы». Материалы Национальной конференции ACM, Торонто .
  4. ^ Согласно сообщению Пола Грэма в Hackers & Painters , стр. 185, Маккарти сказал: «Стив Рассел сказал, послушай, почему бы мне не запрограммировать эту оценку ..., и я сказал ему: хо-хо, ты путаешь теорию с практикой, эта оценка предназначена для чтения, а не для чтения». для вычислений. Но он пошел дальше и сделал это. То есть он скомпилировал eval из моей статьи в IBM 704 машинный код , исправив ошибку , а затем рекламировал это как интерпретатор Лиспа, что, безусловно, и было на тот момент. по сути, в той форме, которую он имеет сегодня...»
  5. ^ «Почему первый компилятор был написан раньше первого интерпретатора?» . Арс Техника . 8 ноября 2014 года . Проверено 9 ноября 2014 г.
  6. ^ Jump up to: а б с Эта статья основана на материалах, взятых из Interpreter в Бесплатном онлайн-словаре вычислительной техники до 1 ноября 2008 г. и включенных в соответствии с условиями «повторного лицензирования» GFDL версии 1.3 или более поздней.
  7. ^ «Компиляторы против интерпретаторов: объяснение и различия» . Цифровой гид IONOS . Проверено 16 сентября 2022 г.
  8. ^ Теодор Х. Ромер, Деннис Ли, Джеффри М. Фолькер, Алек Вулман, Уэйн А. Вонг, Жан-Лу Баер, Брайан Н. Бершад и Генри М. Леви, Структура и деятельность переводчиков
  9. ^ Теренс Парр, Йоханнес Любер, Разница между компиляторами и интерпретаторами. Архивировано 6 января 2014 г. в Wayback Machine.
  10. ^ Кюнель, Клаус (1987) [1986]. «4. Малые компьютеры – свойства и возможности» [4. Микрокомпьютер - Свойства и возможности. В Эрлекампфе, Райнер; Монк, Ханс-Иоахим (ред.). Microelectronics in der любительской практики [ Микроэлектроника для практического любителя ] (на немецком языке) (3-е изд.). Берлин: Военное издательство Германской Демократической Республики [ де ] , Лейпциг. п. 222. ИСБН  3-327-00357-2 . 7469332.
  11. ^ Хейн, Р. (1984). «Basic-Compreter für U880» [BASIC-компьютер для U880 (Z80)]. радио-фернсен-электроник [ де ] (на немецком языке). 1984 (3): 150–152.
  12. ^ Промежуточные представления AST , форум Lambda the Ultimate
  13. ^ Кистлер, Томас; Франц, Майкл (февраль 1999 г.). «Древовидная альтернатива байт-кодам Java» (PDF) . Международный журнал параллельного программирования . 27 (1): 21–33. CiteSeerX   10.1.1.87.2257 . дои : 10.1023/А:1018740018601 . ISSN   0885-7458 . S2CID   14330985 . Проверено 20 декабря 2020 г.
  14. ^ Surfin' Safari — Архив блога»Анонсируем SquirrelFish . Вебкит.орг (02.06.2008). Проверено 10 августа 2013 г.
  15. ^ Эйкок 2003 , 2. Методы JIT-компиляции, 2.1 Бытие, стр. 2. 98.
  16. ^ Л. Дойч, А. Шиффман, Эффективная реализация системы Smalltalk-80 , Материалы 11-го симпозиума POPL, 1984.
  17. ^ Jump up to: а б «openjdk/jdk» . Гитхаб . 18 ноября 2021 г.
  18. ^ «Обзор среды выполнения HotSpot» . Openjdk.java.net . Проверено 6 августа 2022 г.
  19. ^ «Демистификация JVM: варианты JVM, Cppinterpreter и TemplateInterpreter» . metebalci.com .
  20. ^ «Интерпретатор шаблонов JVM» . Программист Ищу .
  21. ^ Бондорф, Андерс. « Logimix: самостоятельный частичный оценщик Пролога ». Синтез и преобразование логических программ. Спрингер, Лондон, 1993. 214–227.
  22. ^ Гиффорд, Клайв. «Собственные отношения самоинтерпретаторов» . Блогер . Проверено 10 ноября 2019 г. .
  23. ^ Кент, Аллен; Уильямс, Джеймс Г. (5 апреля 1993 г.). Энциклопедия компьютерных наук и технологий: Том 28 – Приложение 13 . Марселя Деккера, Inc. Нью-Йорк: ISBN  0-8247-2281-7 . Проверено 17 января 2016 г.

Источники

[ редактировать ]
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 833f6cf64de5ff64fc71d7400bf9bd62__1722191400
URL1:https://arc.ask3.ru/arc/aa/83/62/833f6cf64de5ff64fc71d7400bf9bd62.html
Заголовок, (Title) документа по адресу, URL1:
Interpreter (computing) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)