Доброго времени суток!

Возникла идея написания интерпретатора Basic для МК AVR. Не буду говорить о мотивах, подтолкнувших меня на это дело. Возникло несколько вопросов перед решением данной задачи:



1. Нужно ли это кому нибудь.

2. А не изобретаю ли я велосипед.



Ну и еще несколько, которые появятся, если я реально за это возьмусь.

В ссылках на литературу именно эта ссылка и находится

Да, есть такое!

Все выше сказанное, конечно, очень интересно. Но, я, с вашего позволения, продолжу тему BASIC INTERPRETER FOR AVR :-)

Пока я делал наброски кода, параллельно обдумывал интерфейс связи с хостом. Хотелось бы сделать данную софтину как можно менее ресурсо прожорливую. В качестве внешнего интерфейса в AVR пока для меня видится USART. Вот только вопрос, надо ли задействовать аппаратный, или же применить программный... Хотя в этом случае придется задействовать один из счетчиков. Наверное, проще будет сделать оба варианта...Сам на свой вопрос и ответил... :-)

"Чернила для 6-го класса?" Разве что пустой причуды ради хотите написать его на ассемблере. Ресурсы по Бэйсику, http://www.nicholson.com/rhn/basic/

Сам интерпретатор может быть достаточно произвольным. Например, Атари Бэйсик компилировал бэйсик исходник в байт-код, который затем исполнялся виртуальной Форт-машиной. Все было написано на ассемблере 6502, но это когда ж было...

У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?

OFF:Ну конечно, куда мне до вас, акул электроники, мечтающих, забабахать что нибудь эдакое и новомодное. Да, из 6-го класса я вылез не так давно, и ВУЗ окончил совсем таки недавно. То что мне попадалось в сети и то, на что давались ссылки в этом топике я смотрел и анализировал, что то понравилось, от чего то отказался. Но мне это нужно, и я это напишу. Сдесь же я пытался получить какие то конструктивные советы, а не мечтания о новой ОСи



RE: У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?



Пока все ориентированно на AVR, по этому пишется на Асме - соответственно платформа все таки целевая. Хотя, когда выработаются жесткие конструкции в голове, может быть можно будет говорить и о переносимости, хотя таковой цели я не ставлю

prottoss - не злитесь и не обижайтесь. Просто использование AVR для ваших целей для многих кажется странным (и для меня), в то время как построение контроллера с интерпретатором - очень даже стоящая вещь.

Вероятно, это от жадности, но я хотел бы видеть проект не на васике и не на AVR - но проект ваш, и решать Вам.

Остальным остается только радоваться за Вас или сочувствовать Вам.

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

2 prottoss

Насчет исполнения, следует четко определиться, откуда будут поступать команды. На первый взгляд видиться УАРТ и внешняя память.
Второе наверное выбрать модель исполнения: ИМХО с байт-кодом связываться не стоит.Парсить текст.
Третье - типы данных.
Четвертое - операторы, имхо связываться с модификацией регистров не стоит - юзер может наделать беды. Лучше вызывать АПИ из флэша.

Если будут работать базовые - присваивание, ветвление, цикл и арифметика, поддерживаться целочисленные и строки пол-дела уже можно сказать сделано.

Идею именно Басика не поддерживаю, но в данном случае это не принципиально.


Гляньте вещь под названием yacc, возможно поможет.

Сообщение отредактировал beer_warrior - Apr 6 2006, 17:15

2 Evgeny_CD

Да почитывал, но там чисто теоретические изыски, а я в принципе хотел бы садиться и гнать код.
Сразу вопрос: Lua для eCos не нашел, где смотреть?

И еще 2 all:
Вчера на сон грядущий, перелистал еще раз руководство по tcl, с прикидкой на портирование, вроде бы если подрезать работу с файлами то получиться весьма мило, а если еще поддержать файлы -
с поддержкой на уровне фирмвари файлов-устройств, то вообще полный шоколад. Ну а далее полные Нью-Васюки embedded tk.
В связи с этим вопрос: водиться ли tcl/tk в исходниках???

**************** Ресурсы по LUA ***************************

*** порт LUA 5.0.2 для eCos
Реньше жил тут http://www.elatec.si , но сейчас его там нет

Выложил в местные закрома
/pub/OS/LUA_5.02_for_eCos_Port/lua5_0_2-ecos-040324.tgz

И сюда
http://rapidshare.de/files/17358631/lua5_0...40324.tgz_.html

Официальный релиз LUA, для которого написан этот порт
http://www.lua.org/ftp/lua-5.0.2.tar.gz

*** доки, инфа
http://lua-users.org/wiki/LuaDirectory - хороший сборник ресурсов
http://www.lua.org/pil/ - книга Programming in Lua
http://www.lua.org/docs.html - официальные доки по LUA

Выложил в местные закрома
/pub/DOC/Books/LUA/premier.press.game.programming.with.python.lua.and.ruby.ebook-lib.chm

*** проекты, использующие LUA
http://www.lua.org/uses.html

*** связь программ, написанных на С, со скриптовыми языками
http://www.swig.org

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of languages including common scripting languages such as Perl, PHP, Python, Tcl, Ruby and PHP. The list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), Java, Modula-3 and OCAML. Also several interpreted and compiled Scheme implementations (Guile, MzScheme, Chicken) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG may be freely used, distributed, and modified for commercial and non-commercial use.

LUA он тоже поддерживает.****** Tcl **************
http://tcl.sourceforge.net/

********** IMHO **************
Имеет смысл работать с LUA, ибо в силу простоты и хорошей доки ее можно портировать под что угодно, хоть под тот же uCOS.

Tcl гораздо сложнее.

Для интерфейса связи с хостом можно и SPI использовать. Возможность программирования
будет. Протокол может состоять минимум из трех команд записать ячейку, считать ячейку и запустить выполнение кода.
При разработке своей IDE рабочий прототип мне сэкономил время. Сейчас есть идея добавить
мультиязыковую поддержку в проект..( возможно Javа первый из кандидатов)

Сообщение отредактировал Kopa - Apr 7 2006, 03:43

Примеров Бейсиков достаточно приведено в Proteuse.

Это была цитата из Задорнова: "Дайте мне чернила для 6-го класса!" ©, что ассоциируется у меня с "бэйсик для AVR". Не имел намерения ни на что другое намекать.


Вопрос был о другом, не о переносимости. Интерпретатор находится а целевой платформе, т.е. на AVR. Вопрос в том где находится компилятор, тоже на AVR (резидентно) или на PC (кросс-компилятор). И тот и другой вариант возможны, но второй несравненно проще реализовать.

Я понимаю, скажем, почему тот же Атари-бэйсик был полностью резидентным - в то время PC не существовало. И почему он был написан на ассемблере - не было C для 6502. Но сейчас-то зачем огонь трением добывать, из спортивного интереса?

Это и/или bison смотреть обязательно. Вне зависимости будет в конце-концов синтаксис бейсика или нет.

Не перевелись на руси богатыри добывающие огонь трением!!!!
Один из проектов создания своей оси используя ассемблер http://meos.sysbin.ru
Я тут недавно в каком то топике давал ссылку на порт LCC при использовании форта.

Сообщение отредактировал Kopa - Apr 7 2006, 06:11