Самое смешное, что задача решается в лоб по инструкции на видео за 10 минут и 50 бакинских на железо и софт. И сиди себе спокойно на IL программируй свою логику сколько хочешь.
https://m.youtube.com/watch?v=_MeQBfQObgk

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

ну расбери с линуксом это тоже не совсем тот путь который мне подходит.

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

у Страуструпа в книжке есть пример калькулятора на сотню строк, с разбором любых выражений со скобочками и переменными, добавить туда ||, &&, ~ для логической арифметики в стиле С, когда 0 = false. И если хочется именно "скомпилировать", чтобы не парсить каждый раз, надо вместо непосредственно вычисления сложить все операции и значения в стэк и потом просто пройтись по нему и выполнить.
кода для этого написать надо куда меньше чем в этой теме нафлужено.

собственно на первой же странице RabidRabbit всё уже рассказал как сделать.

о-о-о-о, всё ясно. повидал я таких:
> Сделать то-то. Задача лёгкая, но мне некогда. Потому ценник низкий.

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

да легко, давайте небольшую реальную задачу, $20 и будет вам программа и интерпретатор под неё

И это еще Огурцов реально по-Божески заряжает. Так то я слыхал, обычно со ста тыщ рублей ценник начинается! ))))))))))))))))))
Рекомендую немедленно соглашаться!

казалось бы причём тут зарядка, это ж чисто на пиво, дабы не скучать
а за стотыщ я вам шарп со студией 16 и фреймворком 6.0 напишу

Я вам показал интерпретатор, парсер и отладчик для ПЛК в одном флаконе - это то, к чему вы собираетесь идти. Распбери с линуксом там только одна из платформ. Не нравится - возьмите другую.

Это называется "обратная польская нотация". Удобна для обработки стековой машиной.

Вам уже всё разжевали и даже в рот положили. И правильно указали - что у Вас проблемы уже с парсингом.
Выражения удобно парсить в формат записи обратной польской нотацией. И в ней уже обрабатывать выражения. Скобки проходятся рекурсией.
В обратной польской нотации раньше задавались выражения для программируемых калькуляторов, если кто помнит такие девайсы....
Выражение в обычной записи (a*b+c*(d-e)) в обратной польской нотации будет выглядеть: ab*cde-*+ - это уже удобно для обработки исполнительным алгоритмом и уже без скобок.


Не обязательно 2 операнда. 2 - это для бинарных операций. Для унарных - 1 операнд.

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

Самое необходимое (и достаточное) условие для решение любой задачи - не мощный камень или язык, а мощная голова...

это Вы свою имеете ввиду я так понимаю?

Судя по "постановке задачи" ТС, это похоже на интерпретатор бейсика в "онлайн" режиме,
когда каждая строка выполняется по энтеру.

В PLC системах, один из языков программирования - IL ( Instruction lang.) полностью соотв-ий ассемблеру.
Кроме ASM - есть ST - сильно похожий на C

Тоисть, ТС не следует изобретать очередной лисапет, а (если задача учебно-тренировочная)
разработать свой компилятор ассемблера (включающий парсер) на выходе которого будет сгенерирован
машинный код (это будет круто),

или
промежуточный код (как в Java) - для последующего исполнения вирт. машиной "MyPLC"

или
текст-код, например например на ASM MSP430 для последующей компиляции "настоящим" компилятором ASM430
и заливки реального кода в процессор, где уже "живет" "Операционная система MyPLC"
(тоже круто). Так работают реальные системы разработки для промышленных контроллеров.

При разработке своего контроллера я подумал побольше и сделал так.
Любая логическая функция из N переменных описывается таблицей истинности из 2^N строк.
Если переменные пронумерованы, то и на результат можно ссылаться числом.
Например, для 5 переменных имеем 32 результата.
Зная значения всех 5 переменных, мы можем получить номер бита в 32-битном хранилище результата.

В байткодах это выгладит так:

TABLE5(result_value)
VAR0
VAR1
VAR2
VAR3
VAR4
GETRESULT

Компилятор должен преобразовать сложное логическое выражение к таблице истинности и получить правильный resul_value.

честно говоря я мало что понял.

Я так понял, что у вас задача "програмировать задачи - состояния на выходе в зависимости от условий на входе." в первом посте, а не разработка интерпретатора для своего языка программирования. Среда разработки выше была создана именно с целью решения задачи из вашего первого сообщения. По-моему вы больно ошибетесь, если будете думать, что она "почти решена". Помимо описанного выше - что насчет типов переменных? Как вы собираетесь описывать весь этот язык в документации? Для каких пользователей?

Вы таблицу истинности представляете?

Просто это типичный случай, который я описал в "Гайке М3". ТС кажется, что как только он "определит гайку", то все остальное получится само по себе. Причем он даже не понимает, что он хочет делать интерпретатор или компилятор... Так же как и не понимает, почему ему хочется обрабатывать сложные скрипты а не простые, обработанные компилятором. Не понимает, что в любом случае, в системе управления будет хост. И еще лучше хост удаленный. А это значит, что валить компиляцию в микроконтроллер - не имеет смысла.
А уж его высказывания все это только и подтверждают. Я читаю эту переписку не как техническую, а как пример общения с глухим и диким, не вежливым и ужасно самонадеяным....

А ТС-у нужны только логические функции? Или и арифметические тоже?
Я когда-то давно, когда писал свой типа компилятор ну и парсер выражений для него, реализовал поддержку всех операций, что есть в си (с таким-же синтаксисом).
Ничего сложного там нет. Сложно стало когда я попытался сделать ещё фазу оптимизации полученного кода после этого
У меня в выражениях поддерживались все сишные операции, скобки, переменные (были только численно-логические (только одного типа), или строковые (с меньшим списком операций)),
константы числовые/строковые, константы литеральные.
Мой компилятор компилил текстовые выражения в байт-код, который выполнялся на этапе выполнения.
Это для я делал скриптовый компилируемый на лету после старта ПО язык в одной из своих программ.

Об этом объяснено еще пару страниц назад, да только все бесполезно...

Утверждается, что (param1 && input1) || (param2 && (input2 || input3)) соответствует таблица истинности из вложенного файла.
Из значений переменных собираем индекс:
n = (param1 << 4) + (param2 << 3) + (input1 << 2) + (input 2 << 1) + (input3 << 0);
Затем получаем результат:
((0xFEF0EE00) >> n) & 1
Т.е. для вычисления (param1 && input1) || (param2 && (input2 || input3)) нам достаточно знать одно волшебное 32-битное число 0xFEF0EE00.
Причем, для меня важным моментом было время вычисления логической функции любой сложности из максимум 5 переменных.
При таком подходе оно фиксировано и минимально (не зависит от вида функции и от значений переменных).
А самое главное, легко описывается байт-кодом и элементарно вычисляется.

Теперь понятно?

да. это интересно.
но условие (param1 && input1) || (param2 && (input2 || input3)) не статическое, оно может поменяться на скажем (param2 || input3) && (param4 || (input5 || input6))
или скажем переменных будет больше 5

ааа...понимаю.. с ростом параметров наша таблица серьезно вырастает…
да. это круто. интересный подход. а как мы заполняем результат функции в true table - 0xFEF0EE00?

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

Насчет логических условий с бОльшим числом переменных могу сказать, что я за долгие годы с такими не встречался (максимум 4).
Но кто сказал, что таблицы нельзя каскадировать?

adnega, неужели в наше время, микропроцессорные ресурсы такие ценные, что пришлось так извращаться?

оличное решение проблемы. я восхищен, не побоюсь этого слова.
правда не знаю смогу ли я победить некоторые недостатки:
при 8 параметрах наша таблица станет монструозной
програмно получать получать "магическое число"
но тем не менее - сильное решение. спасибо.

как правильно заметил товарищ jcxz - мощная голова - и можно найти элегантное решение без фортов и джэсонов.

Такое решение называется Look up table, где n - адрес, а магическое число - биты по этому адресу. Используется в ПЛИСах уже не знаю сколько.

Конечно, нет. Просто я привык к таблицам истинности и для меня на порядок проще набросать ее, нежели городить пятиэтажные логические формулы.
Кста, иногда решаю обратную задачу - по таблице истинности написать и упростить логическое выражение.
И самая ирония в том, что затем рисую в схемном редакторе схему, соответствующую этой логической формуле на стандартных элементах,
а компилятор "упихивает" ее в LUT внутри ПЛИС ))

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

А теперь немножко расширим подход. Запланируем "таблицу" в 256 значений, соответственно, "волшебное число" будет состоять не из 4-битных полей, а из 8-битных, т.е из байт. "Bолшебное число" не будем ограничивать размерами, а запишем в байтовый массив произвольной длины. А в самой таблице будем держать адреса функций, которые будут выполняться, когда в массиве встретится соответствующий байт. В результате мы получим заготовку для простейшей Форт-машины, а байтовый массив будет содержать то, что называется "программой из байт-кодов".

Для того, чтобы окончательно оформить Форт-машину, сначала зададимся вопросом; а как функции, вызываемые по своим байт-кодам, будут обмениваться информацией друг с другом? И придем к выводу, что проще всего использовать стек, откуда функции будут брать исходные данные для вычислений, и куда они будут класть результаты. Затем задумаемся, а хорошо ли, что наши программы выполняются линейно, в порядке расположения байт-кодов в массиве? Нехорошо, надо бы предусмотреть возможность изменения порядка выполнения байт-кодов при помощи самих байт-кодов. Заведем байт-коды для условной и безусловной передачи управления в произвольное место программы, а также вызовы подпрограмм, состоящих из байт-кодов, и возврата из подпрограмм. Для хранения адресов возврата заведем еще один стек, назовем его "стек возвратов".

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

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

"Скелет" этого варианта?
Кросс Форт на C: FVM factory

Ну да. Жаль, автор давно забросил этот проект. Был бы он в нормальной форме, то задача создания встроенного интерпретатора решалась бы за 5 минут. А так его полдня чистить и править надо, прежде чем заработает, скажем, под CodeBlocks.

Всегда есть надежда и вероятность вернуться к "допиливанию" заброшенных (или отложенных для продвижения будущих целей) авторских идей. (на том же sourceforge)
В тематике Форт их достаточно много, даже при "отсутствии" Форт программистов, как одной из движущих сил IT сообщества.

P.S. На sourceforge мне был интересен из Форт с С в связке F-- проект.

был бы весьма интересен проект под шарп
и причем, если это будет таки интерпретатор, то с выполнением бинарника от i86, чтобы не замарачиваться с кросс-компиляцией

Одно не пойму - если автор не знает, чего он хочет, чем не устраивает интерпретатор бэйсика?

А что такое Бэйсик или Форт против языков PLC или даже просто голой LUT? "Это как плотник супротив столяра" (с). Не надо его ни в чем убеждать, он и сам "таких советов может каждый день выдавать пачками". Вот Изаграф ему бы наверное подошел, но только бесплатный.

Изаграф = Codesys = TwinCAT = Beremiz = среда разработки/интерпретатор/парсер/отладчик/исполнитель языков МЭК 61131-3 на различных платформах.