Стек байтового кода против трех адресов

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

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

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

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

  4. переводчик будет написан на C.

8
bytecode compilation interpreter language-implementation

5 ответов

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

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

0

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

7

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

5

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

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

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

с этим из пути, я точно знаю, что и CLR и JVM являются стековые архитектуры. Некоторые из преимуществ, которые я помню для stack-based vs register-based, являются

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

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

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

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

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

1

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

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

0