Comments 10
Спасибо за публикацию!
Ну вот что интересного в том, чтобы интерпретатор делать switch-ом?
Интересно было бы почитать дальнейшее развитие:
(Важно! Не сарказм или ради писанины. Эти моменты уже долгое время занимают мои мысли. Так как пишем смесь бейсика и асм.)
Что, если захочется в аля VGA буфер. Но чтоб совместимо с адр. пр. где его нет.
Стек переносим или нет. Размер жёсткий или нет.
Сколько выделяем памяти на песочницу? По желанию, чанками по запросу, без ограничений?
Учитывая верхние пункты, как делить адресные пространства для множеств таких "Тини АСМ программ"?
Динамичное и статичное связывание учитывая верхний пункт.
Взаимодействие песочниц между собой. Вызовы, передачи данных (Это важно, так как позволяет реализовывать библиотеки).
Соглашение о вызовах.
Пусть сам "язык" будет примитывным, наипростейшим. Но для виртуальной машины даже на поигратся все верхние пункты необходимы.
За статью спасибо!
Буду действительно признателен рассмотрению этих моментов в след. статьях.
Форт "изобрели"? ))
Напомнили старые времена, когда мы +- такое же делали в рамках курсовых в универе=))
как по мне, код написан не самым удачным образом
при компиляции нет никакой вообще диагностики, на какой строке и почему упало
плохое управление ресурсами через многочисленный копи-паст строчек типа hashtab_free()
я бы описывал инструкции табличным способом по максимуму, например, к мнемонике и коду добавлял бы еще и количество аргументов, а лучше еще и указатель на функцию-обработчик инструкций, тогда не нужны были бы макароны с условной компиляцией
и так далее
Со всеми пунктами полностью согласен. На рефакторинг завёл задачу: https://github.com/number571/cvm/issues/1
_ (удалено)
Стековая виртуальная машина на языке Си