roboforum.ru

[galex1981]

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

[Angel71]

может есть смысл взять иксмегу или что-то на подобии 128/256й меги? или нужен именно интерпретатор? интерпретаторы в природе какие-то уже есть, может и писать ничего не прийдётся

[Vooon]

eLua?

[AndreiSk]

pico C?

[Michael_K]

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

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

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

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

[galex1981]

Согласен в том, что скорость выполнения программы будет небольшая, я расчитывал на то, что код, выполняемый МК будет большой

[Michael_K]

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

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

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

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

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

[galex1981]

А если вариант загружать программу во внешнюю ОП а затем МК исполнять ее оттуда будет (конечно МК будет скорее всего что то из Мега128)...

[Michael_K]

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

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

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

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

[boez]

На арм надо переходить, он фон-неймановский, а не гарвардский как AVR

Ну а еще вот жаба какая-то есть: http://www.harbaum.org/till/nanovm/index.shtml