Easyelectronics.ru

всё так. 99% продвинутого использования Excel это формулы в ячейках. это пользователи любят и ценят.
ссылку на проект Excel to code я выше уже дал. Куда примитивнее... и редактор готовый есть, и умение им польлзоваться в наличии.

Есть и такой языковой концепт-проект Thyrd на слиянии визуального программирования с использованием дизайна таблиц
Может кому то окажутся интересным его идеи. :)

P.S. Забавно, кто то на mirknig разместил ссылку на одну из книг по Forth (Форт) :)

Если планируется делать с прицелом на пользователя - то я бы делал в графическом виде. Посмотрите на FBD.
У вас железка имеет весьма ограниченный набор источников событий и выходных сигналов. Что там по входу, две кнопки да ИК-приёмник? А на выходе - МР3 плеер для озвучки событий да ИК-светодиод? Плюс несколько дополнительных таймеров для отсчёта дополнительных игровых задержек.
Сделать набор блоков, которые имеют входы и выходы. А соединять их между собой - задача пользователя.
И никаких скриптов и парсеров :)

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

О блоках тоже думал, но это, наверно - уже второй этап.
А так все верно - по сути нужно описать поведение системы при наступлении различных событий, коих действительно - немного.
Обрабртчики событий, так скажем + инициализация глобальных (системных) переменных.

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

А поскольку имеется SD карта и доступ к её содержимому по USB - пользователи будут легко обмениваться скриптами.
Или на сценарную игру - записали скрипт соответствующий - вот тебе новый сценарий игры.
Такие мечты...

Все эти FBD или Click&Go довольно просты, там этап компиляции полностью отсутствует, чтобы такое написать никакие книги по компиляторам читать не нужно.
Если исходник в виде текстового файла, то просто берешь очередную строку, разбиваешь на токены, первый - это команда, остальное - аргументы. Хочешь сразу выполняешь, хочешь сохраняешь в виде бай-кода... Рабочий прототип можно за вечер написать, в чем проблема то? :)

Пилю потихоньку виртуальную машину для байт-кода (оптокода).
Пока на компе.
Вот думаю - какие команды могут пригодиться?
Пока такие реализовал
typedef enum optoCode {
NOP=0,
PUSH,
POP,
SUM,
DONE,
MINUS,
DIVISION,
JUMP,
INIT_VAR,
LOAD_SYS_VAR,
STORE_SYS_VAR,
COMPARE,
JUMP_IF_EQUALLY

} tOptpCode;

Эти работают уже.

Типы данных пока это целые числа, символы (char) и строки.
Нужны ли массивы?

Так выглядит "программа" в оптокодах
uint32_t bytecod[]={LOAD_SYS_VAR,1,PUSH,5,SUM,STORE_SYS_VAR,1,INIT_VAR,VM_INTEGER,0,55, INIT_VAR, VM_CHAR, 1, 'Y', INIT_VAR, VM_STRING, 3, 'H','e','l','l','o','!','\0',PUSH,23,PUSH,34,SUM,PUSH,5,SUM,PUSH,3,MINUS,PUSH,3,DIVISION,JUMP,40,NOP,NOP,PUSH,5,PUSH,5,COMPARE,JUMP_IF_EQUALLY,0,DONE,'};

Почитал немного про скриптовый язык Pawn - был удивлен, как интуитивно пришел к некоторым решениям, используемым в Pawn.
Например - там есть такое понятие как cell (ячейка) - её величина зависит от разрядности контроллера.
У 32-битных её размер 4 байта.
Я так же решил не дробить "слово" контроллера и работаю с блоками данных в 4 бита.


Решил писать на С++
Нет никакого перебора switch() case
Есть массив с адресами функций, соответствующих оптокодам.
tFuncDef const VM::LSL_funcList[]={{LSL::nop},{LSL::push},{LSL::pop},{LSL::sum},{LSL::done},{LSL::minus},{LSL::division},{LSL::jump}, {LSL::init_var},
{LSL::load_sys_var},{LSL::store_sys_var},{LSL::compare},{LSL::jump_if_equally},{LSL::jump_if_more}};

Оптокод - есть индекс соответствующей функции в массиве.
Сразу вызывается нужная функция по указателю.
void VM::exec_optocod(tOptpCode optocod)
{

pF=LSL_funcList[optocod].funcAddress;
pF(&bytecod[VM::CP]);
}

так что работать должно быстро.

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

Гиблое дело. Шансы на успех меньше чем государственной лотереи.
Успех в моём понимании - повсеместное внедрение и использование конечного продукта.
Чтобы оценить масштаб бедствия - рекомендую взглянуть на GCC. Компилятор - который может собирать самого себя.

Вторников. Стек, или Путешествие туда и обратно

P.S. Свежая статья с Хабра Байт-машина для форта (и не только) по-индейски

А компилятор для какого языка, собственно, хочется получить? Пока у тебя только 3 математических операции реализовано, даже умножения почему-то нет, банальные flag = !flag и то не напишешь, но откуда нам знать, может так и задумано :)

я просто оставлю это здесь:
https://github.com/rswier/c4/blob/master/c4.c

Должен быть простой язык для описания игровой логики лазертаг устройств.
Много чего не написано, я только пытаюсь сориентироваться - что по чём.
Движок работает, нужно определиться с необходимым набором команд.

Советую посмотреть на лисп и форт, это самые простые для реализации языки. Еще Tcl довольно простой.
Но проще взять что-нибудь готовое.

Это слишком общее описание... Ну ладно, в принципе если довести количество математических операций до некоего приемлемого минимума, то тебе не хватает команд для работы с функциями и стеком. Пара каких-то CALL, один вызывает встроенные функции по индексу, второй по адресу, но сохраняя адрес возврата на стеке, плюс нужен RET. Если у функции есть аргументы, они перед вызовом пушатся на стек, а после вызова его нужно вернуть в прежнее положение, обычно просто прибавляют или отнимают значение равное количеству аргументов. При наличии локальных переменных аналогичным образом резервируют место на стеке и перед выходом из функции он также восстанавливается, дополнительно для работы с такими переменными нужен еще один набор Push/Pop и, насколько я понимаю, твои LOAD_SYS_VAR/STORE_SYS_VAR выполняют аналогичные функции по отношению к глобальным переменным. Компилятор на который _pv ссылку давал похожим образом поступает, только там встроенные функции в виде отдельных команд.

Это интерпретатор языка Си?

Вызов подпрограмм безусловно нужен, вчера размышлял об этом.
На счёт сохранения результатов в стеке - не уверен.
Можно же через переменные все делать.
Все равно ведь результат будем присваивать переменной, так это можно и в самой подпрограмме сделать.
Пусть будут процедурами.

Компилятор.

И в чём смысл?

а если всё-таки в код посмотреть? его там совсем немного.

Подумал - можно язык сделать максимально близким к оптокоду.
Вычисления - в польской нотации.

Выложили проект на github, а описания - ноль.
Моветон!

Да совсем озверели, там, о ужас, не то что скетча для ардуиныпроекта для моего любимого IDE нет, даже Makefile не потрудились приложить, и теперь совершенно непонятно как же это всё собрать!!!

Даже комментариев практически нет.
Оно стоит того, чтобы я время тратил на изучение?
Извлекать логику программы из исходников чтобы понять, что же она в итоге делает - так себе развлечение, на любителя...
Если хотите заинтересовать кого то своим проектом - будьте добры, не поленитесь, сделайте нормальное описание.
Ковыряться в чужих портянках не у каждого есть желание и время.