Какие стратегии отправки кода операции используются в эффективных интерпретаторах?
Вы можете сделать это через readLines
allLines <- readLines(con = file('~/file.DAT'), 'r')
grepB <- function(x) grepl('^B',x)
BLines <- filter(grepB, allLines)
df <- as.data.frame(strsplit(BLines, ";"))
. Если ваш файл содержит заголовок, вы можете указать
names(df) <- strsplit(allLines[1], ";")[[1]]
7 ответов
Существует ряд бумаг по разным видам депеши:
M. Антон Эртл и Дэвид Грегг, Оптимизация точности предсказания косвенных переходов в интерпретаторах виртуальных машин , в материалах конференции ACM SIGPLAN 2003 по проектированию и реализации языков программирования (PLDI 03), стр. 278-288, Сан-Диего, Калифорния, июнь 2003 г.
М. Антон Эртл и Дэвид Грегг, Поведение эффективных интерпретаторов виртуальных машин на современных архитектурах ,
Перед запуском чего-либо проверьте Lua.
Это является маленьким (150 КБ), чистый ANSI C, работы над чем-либо имеющим компилятор C. Очень быстро.
И самый важный - исходный код является чистым и читаемым. Стоящий проверки.
Косвенная поточная обработка является стратегией, где каждая реализация кода операции имеет свое собственное JMP к следующему коду операции. Патч к интерпретатору Python выглядит примерно так:
add:
result = a + b;
goto *opcode_targets[*next_instruction++];
opcode_targets отображает инструкцию в байт-коде языка к местоположению в память о реализации кода операции. Это быстрее, потому что предиктор ответвления процессора может сделать другой прогноз для каждого байт-кода, в отличие от a switch оператор, который имеет только одну команду перехода.
Компилятор должен поддерживать вычисленный goto для этого для работы, который главным образом означает gcc.
Прямая поточная обработка подобна, но в прямой поточной обработке массива кодов операций заменяется указателями на реализации кода операции как так:
goto *next_opcode_target++;
Эти методы только полезны, потому что современные процессоры являются конвейерными и должны очистить свои конвейеры (медленные) на ответвлении mispredicted. Разработчики процессора вставляют предсказание ветвлений, чтобы избежать необходимости очищать конвейер как часто, но предсказание ветвлений только работает на ответвления, которые, более вероятно, выберут деталь путь.
Одна большая победа должна сохранить исходный код в промежуточной форме, вместо того, чтобы восстановить лексический анализ и анализировать во время выполнения.
Это может расположиться полностью от просто хранения маркеров через поточный код стиля Forth и на JIT-компиляции.
Вопрос немного неопределенен. Но, кажется, что Вы спрашиваете о записи интерпретатора.
Интерпретаторы обычно используют традиционные компоненты парсинга: лексический анализатор, синтаксический анализатор и абстрактное синтаксическое дерево (AST). Это позволяет разработчику читать и интерпретировать допустимый синтаксис и создавать древовидную структуру из команд со связанными операторами, параметрами, и т.д.
Однажды в форме AST, весь вход маркируется, и интерпретатор может начать выполняться путем пересечения дерева.
Существует много опций, но я недавно использовал ANTLR в качестве парсера-генератора, который может создать синтаксические анализаторы на различных выходных языках, включая C/C++ и C#.
Сравнительное тестирование является хорошей техникой при создании чего-либо быстро на данной платформе (платформах). Протестируйте, совершенствуйте, протестируйте снова, улучшитесь.
Я не думаю, что можно получить любой лучший ответ. Существует партия методов для создания интерпретаторов. Но я даю Вам подсказку, не делайте торговли offs, просто выбирайте то, что Вы действительно нуждаетесь и преследуете те цели.