Виртуальная стековая байт-машина

Захотел прикрутить к проекту виртуальную машину.
Чтобы писать скрипты, компилировать в байт-код и выполнять его на контроллере.

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

Начал с изучения статьи "Пишем интерпретатор скрипта и стековую машину" на хабре https://habrahabr.ru/post/223887/

0

Сообщение от Pymkvym Ну вот Pawn заинтересовал, но опять не найду ни описания языка, ни как прикрутить его к своему проекту!

Знаете, что такое синдром Блаба? :)
Грэм, Пол "Lysp: побеждая посредственность"

0

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

0

Pymkvym, штука в том, что не надо стек руками делать - он у вас уже есть. Т.е. код для прямой польской записи получается проще. Вот в железе обратная бы проще вышла, наверное.

0

Сообщение от Pymkvym Ну вот Pawn заинтересовал, но опять не найду ни описания языка, ни как прикрутить его к своему проекту!

http://we.iosyitistromyss.ru/STM32/prik ... stm32.html

ну и интерпретаторы:
https://github.com/zsaleeba/picoc
https://github.com/pmachapmom/LittleC

0

Сделать эмулятор МК-61)))) И просто и команд достаточно много. На нем даже почти шашки делать умудрялись)))

0

Сообщение от PRS Сделать эмулятор МК-61)))) И просто и команд достаточно много. На нем даже почти шашки делать умудрялись)))

Сейчас уже есть MK-151 :) а для него Калисто (диалект Форт языка поверх штатного языка)
но для HP50G, например, сделан проект NewRPL языка, но там ARM 200МГц процессор.

P.S. Сейчас уже доступен швейцарский калькулятор DM42 совместимый с ПО HP42S и эмулятором Frii42.
Железо в нём на базе STM32T476 контроллера на частоте 48/24 МГц (от USB|батареек) и экономичный ч.б экран 400x272.
Цена, правда, для российского потребителя получается не очень гуманной на данный кальк. Для Европы, наверное, нормальная.

0

Так нужно простое решение, а не всякие бейсики и форты. Вот система команд у МК как раз простая и вполне достаточная. Если нужно всегда можно добавить всякие prymt & plot.

0

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

eval: case get_token()
+: return eval()+eval()
*: return eval()*eval()
number: return number_value()
Это не совсем то, о чем я думал, но согласен, сама реализация тоже простая, хоть и рекурсивная, но в случае с обратной нотацией мы сразу получаем такой-же порядок, который будет использоваться при исполнении кода. Допустим у нас было выражение a + b которое превратилось в ab+, а соответствующий ему код выглядит как:
Вероятно при твоем подходе можно получить такой-же байт-код, вопрос скорее в том насколько просто из исходного выражения получить прямую и обратную польские нотации. А выражения могут быть сложными, у меня было 15 групп операций с разными приоритетами, а еще есть ассоциативность... Чтобы точно сказать насколько это сложно провернуть с прямой нотацией нужно было иметь с ней дело, тем более алгоритм сортировочной станции Дейкстры, который часто используют для обратной, там не работает, а рекурсивный спуск для большого количества операций становится сильно запутанным...

0

Ну да. Прямая польская запись - рекурсия во время выполнения. С использованием аппаратного стека - дёшево. Плюс предельно простой и прозрачный код.

Обратная - итеративное выполнение, но стек придётся делать свой, что минус. На си почти наверняка получится медленнее, чем обратная (из-за расходов на свой стек), на асме не уверен (там можно схитрить, как в некоторых реализациях forth, поменяв местами стек возвратов и стек данных), "в железе" (verilog) - явно проще и быстрее.
Да, ещё в форте обратная запись тянет за собой двухстековую архитектуру - за всё надо платить.

Компиляция выражений с приоритетами и ассоциативностью в прямую и обратную запись одинаково тривиальна. Строго тот же рекурсивный спуск, только для прямой записи вначале пишете функцию, потом аргументы, а для обратной вначале аргументы, потом функцию. AST одно и то же, просто "печатается" в другом порядке.

0

Сообщение от oomomstir Ну да. Прямая польская запись - рекурсия во время выполнения. С использованием аппаратного стека - дёшево. Плюс предельно простой и прозрачный код.

Рекурсивный код по определению не может быть более простым и прозрачным, особенно если есть полтора десятка приоритетов и соответственно полтора-два десятка функций рекурсивно вызывающих друг друга в нужном порядке. Получил на вход число и побежал по цепочка до самого конца, потому что функция отдающая число находится именно там, потом выбрал +, а сложение ближе к началу цепочки, начинаем движение в обратную сторону... А алгоритмы на основе стека линейны, там скорее всего будет большой switch, причем приоритет операций тоже будет задаваться через switch или таблицу. На PC у меня алгоритм сортировочной станции работал быстрее рекурсивного спуска и он значительно нагляднее, а для Pymkvym явно в приоритете должна быть простота, потому что когда люди берутся писать компиляторы шансы довести это дело до чего-то осязаемого изначально не очень высоки :)

0

Спасибо всем за интересную дискуссию и информацию!
Решил начать с простого - с интерпретатора.
Вроде должно получиться.

Писать будут скрипты для обработчиков различных событий: нажатие на ту или иную кнопку, изменение статуса блютус соединения, прием по ИК каналу "выстрела", команды от пульта и прочее.

События могут иметь параметры: содержимое ИК пакета, команды пульта, новый статус соединения и пр.
Необходимые параметры будут доступны соответствующим скриптам-обработчикам.

Есть так же глобальные переменные, отвечающие за игровой процесс: уровень здоровья, количество патронов в обойме, остаток обойм, наносимый оружием урон (мощность оружия) и т.д.
Они так же будут видны.

Будут доступны таймеры с возможностью их настройки из скриптов - направление отсчета, интервал отсчета.

Кроме того, не все команды нужно выполнять каждый раз.
Инициализацию того же таймера нужно произвести разово.
Поэтому будет разделитель кода инициализации, который выполниться лишь раз, и циклическим кодом.
Например разделителем LOOP:

Будут команды сравнения.
Будет группировка блока команд фигурными скобками.
#- это комментарии, строки будут игнорироваться

Пока вроде всё, по ходу дела видно будет, чего добавить.

С разделителями команд не определился.
Проще, конечно: одна строка - одна команда.
Но может сделаю разделителем команд точку с запятой.

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

Примерный вариант скрипта - обработчика полученного "выстрела".

таймеру_считать_вниз_до 0 интервал_отсчета_таймера 1 LOOP: если_таймер_обнулен { отправить_ИК_сообщение_выдать_обоймы 2 задать_значение_таймера 120 воспроизвести_звук_удачного_завершения_о перации выйти_из_обработчика } воспроизвести_звук_ошибки ENDLOOP

Выдавать обоймы только своим

таймеру_считать_вниз_до 0 интервал_отсчета_таймера 1 LOOP: если_таймер_обнулен { если_равны цвет_команды_стрелявшего, цвет_команды_нашего_игрока { отправить_ИК_сообщение_выдать_обоймы 2 задать_значение_таймера 120 воспроизвести_звук_удачного_завершения_о перации выйти_из_обработчика } воспроизвести_звук_ошибки выйти_из_обработчика } воспроизвести_звук_ошибки ENDLOOP

0

А как создать генератор на базе mBlock (Scratch 2.0 )?

0

Создание модификации Скретч 2.0
https://ssratch.mit.edu/discuss/topys/40808/

0

Я чего подумал....
Что нам мешает за первый проход получить индексы команд и значения параметров и загнать их в оперативку?
Второй и последующие проходы гнать уже из оперативы, файл можно закрыть.

0

В качестве встроенной "виртуальной машины", часто, можно увидеть использование для встраивания в систему Lua.

0

Для упомянутого в треде калькулятора DM42 (STM32L476ZG ** 1024KByte FLASH, 96KByte RAM)
сделали новую RPN прошивку на Rust
https://github.com/D0ntPanic/rscalc

- Large RPN stack. The RPN stack is not limited to a fixed number of registers. - Accurate decimal floating point. Uses 128-bit decimal floating point with 34 digits of decimal precision. - Exact rationals with large integers. Integers and rational numbers are kept in an exact rational representation. Results can be displayed as exact fractions when possible, and the implementation never guesses the closest fraction. - Unit conversions. Supports conversions between common units. Utilizes the rational representation for unit conversions so that converting between them leads to no loss of precision. - RPN stack undo. Operations performed on the RPN stack can be undone with a deep undo buffer. - Works on dedicated calculator hardware. Designed to run on the excellent DM42 from Swiss Micros. This project has been optimized for highly efficient LCD rendering and memory usage to create a very responsive interface. This project is not an emulation and iterative improvement of the HP42 design like the default firmware, but is rather a ground-up modern redesign targeting the DM42 hardware.

0