roboforum.ru

Возникла идея реализовать интерпретатор исходного кода для МК AVR. Поясняю: для того чтобы МК AVR выполняли программу которая может занимать много больше чем вмещает в свою flash память МК, есть идея реализовать чтение файлов-исходников (написанных на Ассемблере, Бейсике или C - пока не решил на каком языке) располагающихся на Sd-карте и интерпретация команд с этого файла МК. Хотелось бы услышать мнения по этому поводу

eLua?

Лучше всего для интерпретации ИЗ ИСХОДНИКОВ подойдет форт.
Ну, бейсик, с некторыми натяжками - еще куда ни шло.
Си-интерпретатор исходников вещь вообще темная
- все упрется в то, насколько вы хотите урезать Си.

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

С внешней последовательной флэшкой/карточкой и интерпретатором "из исходника"
вы производительность проца убьете не просто в ноль, а в глубокий минус

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

Ну вот вы представьте ваш "интерпретатор" встретил конструкцию
"a = my_functinon(b,c);"

В "чистом" интерпретаторе ему придется прошаривать весь исходный код с поиском подстрок в поисках функции my_function и ее объявления (чтобы узнать в какой тип преобразовать переменные b и с) вместе с разбором дефайнов, инклюдов и (не дай бог конечно) библиотек. И так на каждую строчку - там AVR-ка подохнет строки молотить и буферизировать.

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

Тогда уж проще целиком JIT-компилятор писать. Отдельная тема - безопасная обработка ошибок в интерпретаторе
(он же заранее кагбе не может знать, есть там синтаксические ошибки или нет), сборщик мусора и т.д.

Поэтому я и пишу, что байт-код - это удобный компромисс.

galex1981 писал(а):А если вариант загружать программу во внешнюю ОП...

А зачем? Если программа в исходнике полезет в 64К, то скомпилированная явно и "со свистом"
поместится в 256к (мега2560, например).

Дело же не в том внешнее у вас озу или внутреннее, дело в принципе
Варианты:
- Ужасно тормозить, прошаривая весь исходник в поисках каждой переменной и функции, и не зная ничего о синтаксических ошибках, которые программист ему подложил.
- Страшно напрягшись, сделать встроенный JIT-компилятор, который сначала прошарит исходник пару раз, найдет ошибки, скомпилирует в свой промежуточный код, куда-то его положит и уже его будет интерпретировать.
- Чуть менее напрягшись, сделать внешний компилятор в байт-код, который (байт-код, а не компилятор) занимает мало места и удобно интерпретируется.

Ну можно что-то из этих вариантов намешать-скрестить и намутировать...