Стек байт-кода против трех адресов - PullRequest
8 голосов
/ 16 июня 2011

При проектировании интерпретатора байт-кода существует ли в наши дни консенсус в отношении того, является ли формат стека или трех адресов (или что-то еще?) Лучше?Я смотрю на эти соображения:

  1. Целевой язык - это динамический язык, очень похожий на Javascript.

  2. Производительность важна, но разработкаскорость и портативность на данный момент более важны.

  3. Поэтому реализация пока будет строго интерпретатором;JIT-компилятор может появиться позже, если позволяют ресурсы.

  4. Интерпретатор будет написан на C.

Ответы [ 5 ]

7 голосов
/ 16 июня 2011

Чтение Эволюция Lua и Реализация Lua 5.0 для того, как Lua сменила виртуальную машину на основе стека на виртуальную машину на основе регистров и почему она достигла производительности, делая это Это.

5 голосов
/ 14 июля 2011

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

1 голос
/ 16 июня 2011

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

Два языка, с которыми я работаю в настоящее время, - это C # и Java, поэтому я, естественно, склонен к их методологиям.Как известно большинству людей, обе они скомпилированы в байт-код, и обе платформы (CLR и JVM) используют JIT (по крайней мере, в основных реализациях).Кроме того, я бы предположил, что дрожания для каждой платформы написаны на C / C ++, но я действительно точно не знаю.

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


Учитывая это, я точно знаю, что оба CLRи JVM являются основанными на стеке архитектурами.Некоторые из преимуществ, которые я помню для стеков по сравнению с регистрами:

  1. Меньший сгенерированный код
  2. Упрощенные интерпретаторы
  3. Упрощенные компиляторы
  4. и т.д.

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

Некоторые преимущества архитектуры на основе регистров:

  1. Меньше инструкций должно быть выполнено
  2. Более быстрые интерпретаторы (следует из # 1)
  3. Можетлегче переводить в машинный код, так как большинство обычных аппаратных средств основано на регистрах
  4. и т. д.

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

0 голосов
/ 16 июня 2011

Посмотрите на интерпретатор байт-кода OCaml - он один из самых быстрых в своем роде.Это в значительной степени стековая машина, переводимая в многопоточный код при загрузке (используя вычисляемое расширение goto GNU).Вы также можете сгенерировать Forth-подобный многопоточный код, это должно быть относительно легко сделать.

Но если вы помните о будущей JIT-компиляции, убедитесь, что ваш стековый компьютер на самом деле не является полноценнымрекомендуемый стековый компьютер, но вместо этого форма сериализации дерева выражений (например, .NET CLI) - таким образом, вы сможете преобразовать свой байт-код "стека" в форму с 3 адресами, а затем в SSA.

0 голосов
/ 16 июня 2011

Если у вас в уме JIT, то байт-коды - единственный вариант.

На всякий случай взгляните на мой TIScript: http://www.codeproject.com/KB/recipes/TIScript.aspx и источники: http://code.google.com/p/tiscript/

...