Угу - Министерство Информации и Корпорация "Централизованные услуги"

Я тоже списал половину этого воскресного дня в убытки "полностью выходной день".

Если хотя бы одним глазком заглянете в описание 4e4th, то увидите, что он новые слова сразу кладет в флеш-память. Ещё интереснее переменные. Адрес кладется в флеш-словарь, а место в виде одной ячейки резервируется в ОЗУ.

Чтобы вновь введенные слова "запомнились" насовсем, есть специальное слово SAVE, которое прописывает ссылку на новый словарь в инфо-флеши.

Я между тем полез внутрь

Как много понаписали, может тема того не стоит. Придется и мне

Я столкнулся с фортом в середине 90-х. Заполучили от партнеров в штатах неплохую форт-систему с исходниками для мотороловских 8 битников. Для того времени очень приличное решение, с учетом однократной или ультрафиолетовой ROM в микроконтроллерах, отсутствия аппаратных отладчиков, производительности тогдашних ПК, и уровня компиляторов и сред разработок под С и подобное. На ней успешно написали все ПО контроллеров для нескольких разных приборов. Измерения, сбор данных, математика (вот это тяжело пишется на Forth), пользовательский интерфейс, обмен с ПК и т.п. Поэтому немного представляю особенности, достоинства и недостатки форта и отладки систем на нем применительно к микроконтроллерам для реальных проектов.

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

Я немного смотрел как развивается Forth за прошедшие годы. В целом по моему это «игры разума», и особого продвижения нет (я работал с системой 89 года выпуска, и она была даже поприличней многих нынешних), да и не будет.

Я не вижу большого смысла в применении Forth в чистом виде для микроконтроллеров класса MSP430 при наличии для них приличных С/С++ компиляторов и внутрисхемной отладки. Не видно выигрыша в скорости разработки и объеме результирующего кода. А проигрыш для меня очевиден в быстродействии, надежности и поддержке. И может это субъективно, но также огромный проигрыш в удобстве написания и отладке.

Многие аргументы, которые мелькают в статьях по Forth, выглядят для меня несерьезными.
«Маленький объем кода» - для МК нужно понаписать под три десятка килобайт, чтобы получить выигрыш над С, это очень приличный проект по размеру, и по моему опыту на С/С++ это сделать приятнее и быстрее. Можно ужимать интерпретатор, выбрасывая поля имени и «лишние» слова (приходилось это делать), но во многом теряется прелесть интерпретатора и отладки.
«Не нужно компилировать и прошивать» - приходится кросс-компилировать и прошивать, хотя бы потому что, для больших проектов это зачастую просто много быстрее и удобнее, чем скармливать по последовательному каналу текст Forth компилятору на неторопливом микроконтроллере.
Кстати, 4E4th кросс-компилировать с Форта не умеет, что вполне ожидаемо от простенькой системы на ассемблере, тут препроцессор нужен. Для учебных целей, для которых он позиционируется, и так, конечно, сойдет.

Сам язык, конечно, гибкий и позволяет многое. Но на моей практике при реальных ограничениях быстродействия и объема для моих микроконтроллерных задач как-то эта гибкость использовалась слабо. Зато ужас было писать на форте математику или обработку массивов и структур. И разбирать написанное тоже непросто.

Тема наличия встроенного интерпретатора-компилятора для меня отдельная, и здесь идеи Forth полезны и интересны.
Для ARM слышал об решениях с Lua, это мне кажется правильным и перспективным, объем памяти под это пока выглядит великоватым, но это пройдет.

Идеология форта красива сама по себе, осваивать его интересно, и возможно этим объясняется его некую популярность, в том числе и в учебных целях. Время, потраченное на Forth, не будет потерянным, но я бы не рассчитывал на него как практический инструмент серьезной работы в embedded.

А сам язык не расширяли надстройкой, например, для записи формул в обычном виде и необходимым "дизайном привычного вида"
Многие алгоритмы, Форт реализаций функций, уже собраны в проектах Форт библиотек Forth Foundation Library (FFL) The Forth Scientific Library Project Если посмотреть в i-Forth там очень много математики реализовано на Форт без "классического" синтаксиса, (может
это эффективнее (или оптимальнее по каким то критериям), чем может создать выполняемый код, например, какого-нибудь отдельно взятого Си компилятора)

P.S. Разбирать математику может оказаться действительно сложно без применения дополнительного инструментария. Но и в переложении
на С уровень реализации, без знания предмета, тоже не такое простое (если же возможно) действие. У математики свой язык оперирования
предметной областью, зачастую плохо перекладываемый на компьютерные языки общего назначения. Чему уж тут удивляться или огорчаться.


На Фoрте есть реализованные парсеры BNF с Форт поддержкой среды выполнения и другие "незатейливые" варианты разного парсинга. Может они могут уменьшить требуемый объём при применении для большой группы "классических" скриптовых языков?


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



Неплохой результатдля ужимания текста в именах слов даёт Radiх кодировка. (вроде 5-ть бит на символ)


Есть и такие варианты, поэтому это не контраргумент.



Может действительно приведённые вами параметры субъективны и не настолько очевидны для пользователей Форт, например, при выработке определённых методологий при создании кода? Иначе, как объяснить широкое использование Форт в NASA разработках?
То что Форт применяют на отличном от его основной архитектуре железе - это "возможно" минус. Но контроллеры, предположу, что возможно
бы выиграли в дизайне с аппаратной поддержкой двух стеков и 0-операндных команд (как бы они с ними поступали это уже на их усмотрение)
В FPGA реализации стекового процессора microcore введён режим и интерпритации шитого кода к тому же.


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

Так в чём пародокс "существования" Форта? На протяжении стольких десятилетий? Тупиковые идеи обычно не находят свою электоральную группу.
(или может @"Кесарю кесарево, а слесарю слесарево")

Мы не пытались особо расширять надстройками, во первых за неимением у нас таковых готовых, а во вторых потому, что каждая обертка, которая будет обеспечивать сколь нибудь более привычный вид формул и т.п., будет раздувать код и, главное, снижать производительность (там и так неторопливо считается из-за интерпретатора). Если это конечно не препроцессор. И так выбрасывали плавающую точку из-за размера и скорости (обычное дело для МК).
Библиотеки, про которые вы говорите, это для PC, хотя можно оттуда кое-что переносить и в МК. Их пишут на чистом форте для переносимости, и без особых расширений для читабельности.

Тут дело не в заумной математике и сложных алгоритмах. А в том, что даже простое выражение с несколькими аргументами, на форте выглядит абракадаброй, густо сдобренной неочевидными стековыми операциями. А уж если там массивы... Посмотрите как это выглядит в исходниках той же ffl, когда справа в комментариях короткая понятная нотация привычного вида, а справа текст форт на несколько строк. Или вот простой расчет выражения от пяти переменных

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


Это действительно много, у нас проекты были такого порядка. Про то и речь, что для меньшего объема экономии кода нет, а большой попробуй напиши на форте. Лучше сэкономленное время потратить на раздумья по правильной структуре и алгоритмах, можно выиграть больше


А для Forth с его @!+"<>? и т.п. его хватит?


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


Я искал Форт-систему под свои задачи в конце 90-х, ничего достойного не всплыло. Потом стало не актуально, С/С++ взамен. Тем более, что кое-какое наследство от Форта осталось.
А с чем сравнивать?

RADIX50 это не пять бит на симовл (что невыгодно, пропадает один бит в 16-битном слове). Там 050 (т.е. 40 в десятичной системе счисления) символов кодируется, 40*40*40 = 64000, до 65535 немного пропадает. Но кодирование требует умножения (а раскодирование деления, но если только новые имена кодировать и потом сравнивать со словарными статьями, то раскодировать не надо). Но все равно набор символов сильно ограничен.

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


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


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


Может стоило не только решать "насущные" задачи, но и подумать как с помощью сильных сторон Форта подстроить синтаксис/семантику/
генерацию кода для уменьшения, хотя бы процесса "прототипирования"


Не понял вопрос, например в 16бит (ячейку) утрабуется 3символа и останется 1бит (например как признак ограничитель длины строки)
В две 16битных ячейки уже 6символов и.т.д. Для многих команд Форта может хватить одой ячейки (16 бит)


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


За неимением профессональных средств сравнивать можно только любительские или полупрофессиональные. Для контроллеров
уровень тех и других может оказаться недостаточным. (для LPC есть прошивка без компиляции от MPE Ltd) А так этот вопрос
требует отдельного исследования, хотя достойные варианты для рассмотрения и начальной работы существуют.
Допилить, например, ff303 (в моём случае) вполне возможно, но выбор конкретного Форта дело сугубо индивидуальное. А так как для
PC их очень много, то какие то решения можно и применить для контроллеров (для контроллеров, тоже не малое количество)


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

И действительно - отвратительно
Прогнал с карандашиком на бумажке, понял , что туфта ( несоответствие м\у выполняемыми операциями и стековыми комментариями ), переписал по своему,
опираясь на N = { L1*[X2-X] + L2*[X-X1] } / [X2-X1]

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


Смею предположить что в приведенном фрагменте Х - некая измеряемая величина,
L1 L2 - видимо какието коэффициенты, X2 X1 - вероятно, граничные значения параметра Х,
в таком случае (наверняка) L1 L2 X1 X2 хранятся в constant\value\variable виде,
и ничто не мешает иметь



На мой "извращенный" взгляд, стало нагляднее, впрочем - дело вкуса.

Хотя и несогласен, я принимаю и уважаю Вашу точку зрения, которую, возможно утрируя, представляю так:
"
Форт - прикольная и любопытная вещица, наподобие "сферического коня в вакууме",
использование которой - бесперспективно, ведет в тупик и способствует "извращению умов".
"
Но есть люди, которые исследуя Forth и применяя его, испытывают ни с чем несравнимое "интеллектуальное удовлетворение",
конечно же неуместное при массовом потоковом производстве...

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

Наверно, у вас есть неточность, M* - 32 битный результат, если еще помню. Извиняюсь, привел плохой пример, но суть поясняет - как сложно некоторые простые вещи пишутся на форте. Разворачивать добавляя слова можно, но ясности и простоты может и не добавить, и производительность не улучшит. То же и про оптимизацию "жонглированием", необходимость таковой никак не есть достоинство языка.

Я не настолько категоричен, "пусть цветут все цветы". Просто хотел поправить некоторые не очень грамотные суждения о сильных сторонах Forth, применительно к микроконтроллерной практике.
Форт концептуально красив, возня с ним доставляет удовольствие. Действительно, единственный компилятор, который мне по силам написать. Действительно, "живая" интерактивная система почти сразу, можешь одновременно писать и на ассемблере и на своем метаязыке.
Но как рациональный выбор инструмента для реальных задач, за некоторым исключением, Forth ИМХО плохой вариант.

Мне сложно судить хорош ли форт для обучения. Это смотря чему обучатся. Если программированию, то зачем на микроконтроллере? Если устройству МК, то почему форт, а не ассемблер или С плюс JTAG? Если с азов, то нотация и стековые навороты форта запудрят новичку мозги. Хотя с другой стороны, я сам когда-то учился программировать на стековой машине советского калькулятора, с сомнительным как видим результатом

Из практических советов порекомендовал бы искать форт-систему, написанную на самом Forth, с исходниками. Разумеется портированную на нужный МК через форт-ассемблер. Глаже решаются вопросы кросс-компиляции, и не нужно использовать другие языки при модификации системы.
Солидно выглядит MPE Forth cross compiler Увы, не бесплатно.

Если есть нужна портируемая на разные МК система или желательная связка форта с С (вот тут сила), то лучше брать систему, полностью реализованную на С. Может быть типа pForth - Portable Forth in 'C'
Я использую подобные решения, их легче всего адаптировать под себя. Сам форт конечно будет работать медленнее.

Да, Вы правы.Это не неточность, а грубая ошибка, которая свидетельствует о том что бардак на стеке - недопустим.
Но, если бы я писал не "умозрительный" а реальный пример, я бы просто протестировал это слово в диалоге с форт-системой на реальных данных.
А сейчас мне стыдно - так облажаться на весь почтенный форум...
А М* - это из Вашего примера.
А второй вариант реализации Вашего примера - форту как то более близок ( я бы сказал - роднее)
Впрочем, это моя, сугубо личная, точка зрения.
PS. Я действительно облажался в первом "примере" со стековыми манипуляциями, мне стыдно.
Первым желанием было - отредактировать текст, но оставил "как есть",пусть эта "лажа" послужит всем примером - "Форт не прощает ошибок".

Может тогда определить область где c Фортом "уместно" "возиться", а куда, кому и кем (чем) путь закрыт.. И не стоит сопоставлять
умение написать "простейший" Форт компилятор с единственной задачей достойной для его применения.

Пока, что кроме "неочевидных" умений по применению набора операций в словах, и отличающегося синтаксиса от общих принципов построения общих языков, мало ИМХО, что прозвучало. При этом для использования или не использования дополнительно локальных переменныхе нет трудностей.
К тому же, например "излишне cтруктурирование" синтаксиса, может ограничить способ поиска приемлемого решения задачи. (не знаю, как точно мыслит программист, но предположу, что удобно решать задачу в рамках необходимой последовательности действий, чем бы она ни была)
Форт имея "простейший" синтаксис способен решать (или всё же с помощью грамотного пользователя) любые задачи используя "минимальные" ресурсы. Мнимым ограничением может представляться, зачастую, необходимость использования "инородного" материала без его преобразования (в том виде как дан) при решении необходимой задачи.


Сложно в целом всегда определять оптимальный путь введения, в ту или иную область знаний. И применение например С со звёздочками,
взятием адреса. пост или пре декремента переменной и др. не так уместны при изучении азов существующих МК. Для МК, чем ближе, проще
к пониманию устройства и принципов функционирования МК тем лучше.

P.S. Не знаю поможет ли с пониманием программирования "подрастающему" поколению эксперименты с Форт программированием
в моде Red Power 2 для игры Minecraft, но хочется верить в формирование правильных основ программинга.

Идеи языка Форт
Красиво сказано. Нравится. А стек и польская нотация - "это не баг, это - фича"

Я вот подумал - а ведь можно сделать JIT-компиляторы для любой архитектуры с абстрактного (но стандартизированного!) форта.
Тогда стек может стать виртуальным, как и связанные с ним издержки.

(под PC уже реализовано )

Кстати, только что получилась логическая цепочка: forth->CIL->mono-> что бы вы думали? LLVM!
Попробую покопать в этом направлении.

Можно сразу попробовать forth->LLVM byte code LLVM Мощная виртуальная машина для встраивания в ваши приложения
P.S. Ещё по теме Курс п платформе NET
У меня было некоторое желание "покопаться" алгоритмах кодогенерации VFХ (forth от MPE) и в I-Forth, но для RISC контроллеров
это может быть не так пригодно или пойти по пути полуручной оптимизации по шаблонам пробовал кодогенерацию из LLC C в SPF4

P.S. Есть в документации LLVM пример стекового языка Stacker: An Example Of Using LLVM

У форта все нормально со сруктурами
Каждый раз с удовольствием использую "нестандартное" слово --
Простота и "элегантность" его определения

Наглядность ( на мой взгляд ) описания структур

и применения

C/C++ за оператор goto в свое время полоскали-полоскали, чуть ли не источник всех ошибок в нем видели. Тогда как Forth за его выкрутасы и убить мало!

Ага, полная демократия. На том и стоим. Каждый может видеть "свои" интересные и не так что бы моменты.



Конструкция
: name create .... does> ... ;
Одна из базовых возможностей (находка Форт) по формированию произвольных данных c именем (чаще всего в "кодофайле")
во время трансляции программы (слова между CREATE ...и... DOES> ) и обработка их словами после does> адрес данных которых
передаётся на стек (неявно для пользователя) словам после маркерного слова does> при вызове сформированного по имени слова (сформированного словом CREATE и дальнейшей последовательностью действий до слова-ограничителя DOES>).
Слово CREATE при вызове name берёт следующее слово из входного потока при исполнении созданного определения.

Понятно или необходимо лучшее объяснение?

В книге Баранова/Ноздрунова этот момент описан как мощный базовый принцип по частичной параметризации кода
(вроде так) При этом, слова после does> могут сделать "всё что угодно при исполнении" (впрочем как и при трансляции слова) т.к. имеют доступ к текущим данным на стеке и "ресурсам" в Форт системе, а также к контексу вызова данного слова. (контекст вызова для Форт слов может изменяться, и соответственно слова могут "подстраиваться" под контекст вызова, иметь ограничения по контексту использования или активно менять существующий контекст)

Простейшее определение Форт слова CONSTANT можно ввести так

и вариант использования


положит на стек число 12345

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





Как не странно, на практике применение Forth давало довольно безошибочный результирующий код, как у меня, так и у коллеги. Видимо, потому, написание на форте требовало предельной мобилизации всех сил организма
Если серьезно, то помимо мобилизации и погружения, играла роль и интерактивность, и то что на форте удобнее писать короткими простыми словами. Само собой получается идеологически ближе к TDD. Ну и просто писали меньше и медленнее.

Хотя бытующее утверждение, что "Форт не скрывает ошибки...поскольку ошибки мгновенно «обрушивают» программу" , по моему очень сомнительно. Это примерно как сказать, что работа с указателями не скрывает ошибок, поскольку ошибочное обращение мгновенно выдаст исключение доступа к памяти.

Пропаганда ага

вот, лажу исправил

Народ! если вас будут убеждать что на форте только так и приходится писать программы, знайте - вас обманывают. Ни один фортер в здравом уме и трезвой памяти не станет творить такое без особых на то причин ( например - защита от "реверс-инжениринга"). ( по мнению Криса Касперского программы на форте с трудом поддаются "хакингу")
Если случается такой мозголомный ужас - имеет смысл задуматься - " А верно ли я подошел к решению задачи?"
Впрочем, об этом лучше читать уже рекомендованное - Thinking Forth

А вроде как наоборот - во многие системы входят слова для "дизфорта", вываливающие исходники по имени слова.
Да что далеко ходить - сборки .net, не прошедшие обфускацию, вываливают все свои потроха по первому требованию

Сборки Net, Java показывают легко свои "потроха", если не убрана отладочная информация (в другом варианте могут быть проблемы,
скорее всего)
Статя Криса Касперски Защита игр от взлома (статья в журнале хакер) проясняющая некоторые моменты. (Особо действенный способ выполнять программу в рамках эмулируемого и ивестного "только" разработчику программы процессора) А как оно всё реально эффективно...

P.S. Для развития интересна статья к прочтению Криса Касперски Языки, которые мы потеряли (Форт тоже упоминается)
И также стоит ознакомитья с исследовательской статьёй приведённой в книге Брукса Мифический Человеко месяц
начиная с главы.16 (online) Серебряной пули нет — сущность и акциденция в программной инженерии (русское издание данной книги, вроде 2002года )



Такое, только, в моём понимании:

1. Если выполнение будет происходить на "чисто" стековом процессоре (например графический процессор Вводная инфа: Gameduino Игровой адаптер для контролеров)
2.Других возможностей нет "по быстрому" добавить необходимую математику на "регистровой" реализации Форт, например в ассемблере.
или требуется некоторая компактность занимаемого места кодом. (а надстройки (или "инородные"инструменты) по кодогенерации или кросс-компиляции кода не используются)
3. Проверить "абстрактные" оптимизационные возможности на данном коде на разных Форт системах..
4. Из интереса (любви) к чистому искусству.(здесь есть некоторые оправданные аналоги Graphicals Haiku in Forth и код, возможно, с минимумом переделок использовать для этого.
...

"Хорошая идея - приложить к этому делу Форт. Вот его преимущества: простота реализации Форт-машины, компактность p-кода, довольно высокая производительность, сложность декомпиляции и ни на что непохожесть. Форт стоит особняком от всех языков, совсем не стремясь соответствовать человеческим привычкам, "здравому смыслу" и "логике". Разобраться в его идеологии с нуля будет непросто. Хакеру придется нарыть кучу литературы и запастись терпением. Даже если ему не наскучит, разработчик защиты получит хорошую фору по времени, ну а там... мыщъх что-нибудь придумает!"
Защита игр от взлома Автор: ©Крис Касперски ака мыщъх

Увы, не сильно лучшего хватает, как уже упоминал, и в библиотеках расширений. Это не только извращения программистов, это отчасти свойство языка, ну провоцирует он к "мозголомству". И еще, когда глубоко погрузился в написание на форте, это уже не кажется ужасом, все понятно и прозрачно. До тех пор пока погрузился
Проблемы с хакингом это во многом следствие неочевидности и сложности для восприятия базового синтаксиса и сложных стековых манипуляций (общепризнанная слабость языка). И тоже самое будет с пониманием кода другим программистом. Плюс бесконечное расширение новыми понятиями и новой лексикой, на выходе может легко дать текст на "птичьем" языке, малопонятном для других разработчиков (проблема для любого программного языка, но для форта такое расширение в гораздо большей степени "и нужно, и можно"). Скажут, что должно в идеале решатся правильной методой программирования, но (это уже как битый руководитель) лучше бы было жизнеспособно и без оной. Тем более для зачастую простых с программной точки зрения микроконтроллерных задач.
Поэтому для командной работы (мы сейчас в основном только так и работаем, что правильно) я Forth поостерегусь применять, кроме случаев действительной нужды в нем.


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

P.S. Сам не пробовал, но вроде исходный текст форт восстанавливается по скомпилированному бинарному коду (для некоторых систем). Вот где разгул для хакинга. Не так давно паролил часть слов интерпретатора, дающих доступ к памяти и "потрохам", когда пошли активные поставки изделий в Китай. Больше для очистки совести.
Это к недостаткам Forth никак не не отношу.

И я также познавал азы протоассемблера, имея микро опыт в радиолюбительстве это и приводит некоторых людей к микроконтроллеру. Выходит Форт -- некоторое возвращение к истокам от современного Си ?

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


Можно согласится, если нет привычки восприятия Форт программ. У меня проблем с восприятием и изменением чужого Форт кода особых не было. (всё в рабочем порядке), при этом те вещи которые не надо изменять, "легко" вычленяются из кода и не рассматриваются детально (Форт код действительно, в этом случае, минимально "защищает" себя от изучения.) Стековые маниуляции не так сложны и многочислены (зачастую типовое шаблонное использование) и "достаточно" наглядны в "коротких" интервалах кода. (но комментарии и правила оформления кода не помешают)


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


Полностью поддерживаю и стараюсь использовать, по возможности и необходимости, разные дополнительные инструментальные и не только средства.


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


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


Может и не возвращение, но как повод "переосмыслить" некоторые вещи полезен и в сравненнии с Си.


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

Вопрос к знатокам форта.

Дано:
#define ADC10DTC0_ 0x0048 /* ADC10 Data Transfer Control 0 */

Требуется преобразовать в:
0x0048 constant ADC10DTC0_

То есть перетасовать порядок следования слов. Можно это как-нибудь реализовать?

Самое простое, без обработки входного потока и "извращений"

P.S. Вспомнилось, попутно, обcуждение простых действий по преобразованию постфикса ассемблера в инфикс
Число ли?
В devel SPF4, вроде есть ещё варианты для #define

А для чего ноль в начале и запятая в конце? (в смысле, обязательно ли)

Первая часть сработала


Правда, случайно переопределил */, ну да ладно..

А вот вторая - ни в какую. Рестартится, правда warm.


В последней строке написал abc и нажал Enter

В этом варианте обязательно, 0 произвольное число чтобы не произошло исчерпания стека при выполнениии #define
(т.к. первым действием слово дописывает данные в поле кода "условно предыдущего слова")
а запятая, чтобы последняя константа тоже получила своё число.

Таки извратился

Осталось придумать, кто будет ; дописывать в конце каждой строки

Чегт, ещё одна засада!

Как бы объяснить, что 0x == hex

Может, в этом варианте для 4e4h попробовать использовать последовательность [ LITERAL ] вместо запятой в дефине
т.к. устройство данного Форта может отличаться от общей модели с неразделяемой памятью.

P.S. Числа можно из входного потока например брать по такой схеме

Вместо NeхtWord вероятно есть слово WORD
и тогда : NextWord ( -- addr len ) WORD COUNT ;
и далее с возможными вариациями

ok, попробую
Хотя, полюбому матчасть учить.
Слова есть такие:


Все-таки ABC прописалось, но выполняет что-то загадочное

Может не дописывать ; а дополнительно (принудительно) или POSTPONE ; или [
Для определения 0х проще всего пересобрать Форт систему c изменённым NUMBER определителем, если это
слово не векторизовано. А так, скорее всего, придётся читать в слове входной поток SOURCE TIB >IN или работа со строками и определять 0х и переключившись в шестнадцатиричную систему вводить остаток слова как цифру.

P.S. Как то так можно попробовать.


а если так прикинуть?

у, шайтан!



Не, это я поторопился



Ну да ладно, хватит наводок на выходные

Из этих слов сначало необходимо убрать "общепринятые" (стандартные) и посмотреть на введённые варианты 4e4th слов.
P.S. Особо посмотреть на работу с разной памятью в контроллере.


А так? Для компиляции в тело кода могут быть введены аналоги слов , @
и вероятно стоит использовать слово LITERAL для компиляции чисел со стека внутри слова
Бывает, что тело кода отделяют от заголовков (хранимых отдельно) и связь между частями слова можно установить словами CFA>NFA >BODY
навыки в "боди-билдинге" данной Форт системы могут помочь понять, что не "срослось"

P.S. Жаль нет матчасти под рукой, надо идти покупать, заказывать или сделать симулятор МSP430 или приспособить существующий,
а в Proteus-е вроде есть MSP430.


Что предсказуемо т.к. создалось пустое слово



Чем помочь с словами?

P.S. Можно непосредственно изменить буфер входного потока записав вместо 0х например H с пробелом, при этом
: H HEX ;

прошу пардону, это не флуд, это - "поэтическая минутка" в топик,
графоманское рукоблудие:

Есть. В коробочке лежат. Могу поделиться, на выбор - MSP430F235 либо MSP430F149, ( 235-х у меня несколько) ( либо отдам оба сразу ).
Но, - ни обвязки ни макетки ни программатора ни коммуникаций. В хорошие руки - не жалко. Ваш выбор.

Скачал (через техасских инструментов) какойто iar workbench kickstart ( EW430-5511 ) с ограничением по объёму кода в 4 Кбайт.
Похоже для сборки camelforth430 не годиться. Что делать?
( 30-дневную версию не предлагать: копаться буду долго, и мне не нужна неожиданное "опа!", когда "уже вот-вот" )

Или это ограничение только на кодогенерацию компилятора С ? Просветите, темный я.

Спасибо, но думаю с моими "не совсем прямыми руками" и базовыми знаниями архитектуры MSP430, в данном вопросе, это не выход
(пока на столе лежит, по случаю купленный, Atмega 8535)


Как вариант, ограничиться объёмом кода Форт ядра в 4 Кбайт
А Си обязательно использовать?

8K Flash - маловато будет. Для amforth'a.
Илья на робофоруме на таком http://devicter.ru/goods/Arduino-Nano-V3-ATmega amforth гоняет.
Строит что-то с часами (ds1307), однопроводными http://devicter.ru/goods/sensor-temperatur...chnyj?from=MDg3 ,
rfid считывателем пластиковых карт http://devicter.ru/goods/datchik-schityvan...-kart?from=MDg3
и, кажется GSM модемом. с интересом наблюдаю.


Свят-свят, ассемблер, только ассемблер Верблюжьи исходники - на асме.

Для встроенного варианта Форт системы, может быть и мало, но есть ещё кросс-компиляция с "убиранием" в целевом коде
не задействованных слов. (а текущий базис рабочих слов, можно при необходимости и постепенно прошивать) и управление выполнением целевого кода в кросс-среде + использовать не один, а два и более (может и разных), например, контроллеров (варианты их совместного использования можно продумать) кол-во интерфейсов и линий ввода/вывода будет больше и можно распределить "вычилительные" задачи удобно.


Тогда может проще их "пересобрать", например, с использованием SPF4 (с пониманием ассемблерных команд у MSP30 всё неплохо) были вроде
уже сделаны некоторые варианты от Михаила.

Да, буду пересобирать camelforth430 сам. Кросс пока не интересует. Интересует полноценная форт-система на кристалле. Аналогичная amforth"у.
Вот MrYuran говорит: нет прерываний. Будем поглядеть что можно сделать. Опять же, round-robin multitasker. А так же встроенный ассемблер. Но это уже кажется невпихуемо. Или впихуемо, но несуразно для 16 Кбайт у F235-го.
Вот, както так, почти "свой" форт, но не сразу...

Kickstart обязан собирать camelforth430, форт-система на ассемблере, а ограничение по коду только для С. Под эту среду он же и сделан.


Прерывания форту ортогональны, вектора в camelforth430 перенесены в RAM и заглушены. Нужно написать свой обработчик на ассемблере. Если есть форт-асссемблер, то можно обработчики ваять прямо в интерпретаторе.

ИМХО 16К флеша для MSP430 для забав с фортом более чем достаточно, скорее всего в любом варианте. На меньшее для начала лучше не ориентироваться.

В принципе форт-систему можно запустить на IAR и из-под эмулятором, без железки. Терминал в отладчике C-Spy есть, нужно только stdio прикрутить. В ограниченной версии может не выйти из-за ограничений по C.

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

Немного не по теме, но пост показался интересным RetroBSD on Maximite
Первым в запуске удостоился вниманием Форт, после пары игрушек

2 dynamic-wind
Нажмите для просмотра прикрепленного файла

Имеется в репозитории в виде файла was4.f, а также в виде асм-модуля

Ещё у немцев на сайте есть интересные примеры, в т.ч дизасм



DAS - я так понимаю, дизасм.
Вместе с асмом 2,5 кила из оставшихся восьми.

Мне проблема на данном этапе видится несколько в другом. Очень мало ОЗУ оставили пользователю, несколько десятков байт.
Без переразметки ничего более-менее путного не создать.
Логично было бы урезать стеки и особенно входной буфер, заодно будет стимул вводить как можно более короткие слова.

В качестве лирического отступления:
Принес в выходные платку ланчпада домой, показал 10-летнему сыну, как "мозги для нашего будущего робота".
Несколько строчек в терминале

произвели неизгладимое впечатление: "круто, он учится понимать новые слова!"

Действительно, стеки можно сократить, раза в четыре...