Разработка стековой виртуальной машины и компилятора под неё (часть I)

[kuza2000]

Некоторое время назад делал что-то родственное habr.com/ru/post/431932
Материал остался еще на одну статью, заключительную, с тестами. Никак руки не дойдут написать.

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

[Basheyev]

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

[Basheyev]

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

[iboltaev]

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

[kuza2000]

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

[iboltaev]

switch-based диспетчеризация — не лучший способ написать интерпретатор. Помимо того, что компилятор может не соптимизировать switch в таблицу, на каждую инструкцию байт-кода приходится минимум 2 перехода: в начало цикла и по адресу обработчика инструкции. Direct-threading подход заметно лучше, там в каждом обработчике идет чтение следующей инструкции и переход, так что одна инструкция — один переход. Еще есть на основе базовых блоков диспетчеризация, но это уже к компиляции ближе.
Вот тут можно почитать (применительно к java-байткоду): webdocs.cs.ualberta.ca/~amaral/cascon/CDP05/slides/CDP05-berndl.pdf
Это если будете развивать дальше эту историю.

[Basheyev]

О супер! Спасибо.

[JerryI]

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

UPD: а, уже ответили...

[Worky]

Поздравляю! Вы написали свою Forth машину!

[axe_chita]

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

[Basheyev]

Готово - https://m.habr.com/ru/post/560986/

[axe_chita]

Спасибо, будем читать!

[tonyk_av]

switch-case работают медленней, чем вызов функций-обработчиков через массив указателей на функции. С ростом числа опкодов это становится заметней. Хотя показанный способ будет понятней читающим.

ИМХО, полезней было бы реализовать интерпретатор байт-кода для виртуальной машины, соответствующей стандарту МЭК 61131-3 и написать транслятор с языка ST.

[Basheyev]

Спасибо! Даже не подозревал о существовании такого стандарта. Почитаю.

[tonyk_av]

Так это стандарт на программирование промышленных ПЛК. Просто если нет разницы на чём разминать мозги, то можно было бы попробовать сделать что-нибудь полезное с далеко идущими последствиями.