Хотелось купить в ближайшем магазине промэлектроники (с "относительно" небольшой, для "разовой" покупки переплатой, смотрел ~249р), но возможно лчше сделать заказ у производителя.


Спасибо. Хорошая новость и статья, и обозначен интерес к "развёртыванию" тематики в данном направлении.
На Форте, вроде, в детском кружке при ЦКБ "Родник" делали робо-пса. (Подумал интересно, наверное сделать и робо-черепашку)

P.S. Примерно с этого момента
Похожие эксперименты на Форте для AVR на робофоруме (автор Chu зарегистрирован и на местном форуме)
Форт может составить серьёную конкуренцию текущему Ардуин направлению и снять некую "элитарность" в умении программирования.

P.S. А комментарии в коде ( // ) специально обозначены в Си варианте? (а не \ принятому в Форт)
Ещё, вначале, можно показать использование булевой алгебры изменив систему счисления на двоичную, 2 BASE !
и как изменяются биты в ячейках (CELL) при использовании операций AND OR ХОR
т.к. целевая аудитория читателей может быть разная.
При использовании дополнительного интерфейса отладки, например в IDE (комфортная скорость, в моём случае, была в пределах 38кбит./с при перезаливке
целевого образа программы в контроллере во флеш или ОЗУ)
Самих статей может быть очень много и получится неплохой учебник по Форт применению.
Интересно как будет изменяться ("прогрессировать") понимание возможностей применения Форт в МК и не только у "массового" читателя

Добавлю свои пять копеек, как бывший пользователь форта.
Успешно использовал его для нескольких микроконтроллерных проектов лет 15 назад.
До сих пор использую самодельные упрощенные форт-подобные системы (написанные на С), в основном как консольный скриптовый язык. В том числе и на MSP430. Некоторыми усилиями это можно было бы превратить в полноценную форт-систему, только зачем? ИМХО, сейчас уже не актуально.
Время Форта ушло, для мелких систем не нужен (или востребован крайне редко), для больших есть много уже упомянутых альтернатив, для учебных целей не очень из-за специфического синтаксиса. Сейчас может правильнее выбирать подходящую платформу, например, чтобы вместился Lua, а не маятся с фортом на MSP430.

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

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

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


Если бы это было так, как Вы описываете, то например можно было сделать вывод, что и реализация больших программ даже на ассемблере не приводит к компактности кода? Форт система в контроллере - это один из языковых базисов (подходов) для решения необходимой задачи, а "уменьшить" результирующее решение или взять контроллер "побольше","побыстрее" или реализовать, например в ПЛИС, это уже вторично. Но реализации например BIOS-а на Форте для PC и самих Форт систем может служить некоторым показателем компактности решений на идеях заложенных в язык.


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


И не только.

P.S. Помимо Форта на базовой идеи явного использования и доступности стека для программиста (в Форте есть и другие идеи) построено и появляется (например Factor) другие языки из серии конкатенавных (цепочечных). Не секрет, что в UNIX системах мощный подход для решения задач "сцепление" вход/выход разных программ.

Что-то я вообще потерял всякую логику.

Один говорит: Да вы, что, пацаны! Какие нахрен керосинки! 21 век на дворе!
Другой ему возражает: Да ты гонишь! Современные керосинки -- это совсем не те, что были 100 лет назад. Тут и титановая игла, и микроконтроллерное управление, и журналирование горения. Потом, если что, можно будет посмотреть почему она взорвалась. И вообще -- керосинки очень даже широко применяются в узких кругах фанов.

ЗЫ. Считайте, что в Форте я полный профан. Поэтому прошу относится к моим словам соответственно.

Ну не вижу я, не-ви-жу, где я могу использовать Форт в своих изделиях.

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

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

Пока я вижу только какую-то достаточно странную игрушку на базе LaunchPad -- сунули ей (игрушке) какую-то строку по последовательному порту, в ответ получили другую строку. Что к чему, в чем смысл -- я не понял. Где это можно применить в жизни (в народном хозяйстве)? Почему это же изделие нельзя реализовать на том же С/С++.

ЗЫ. Я не против Форта -- просто я не понимаю, где его место.

На ответ не надеюсь. Но если кто ответит по делу -- спасибо! Прочту с удовольствием.

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

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

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

Акции Форта еще больше понизились в цене, когда у процессов вместо единственного сумматора появилось больше регистров, которые к тому же были способны к самостоятельной арифметике/логике. В этой ситуации идея прогонки всех вычислений через посредство стека становилось уже невыгодным, т.к. стек был всего один. Более того, операции с/над регистрами оказались на редкость быстрыми, по сравнению с операциями над ячейками памяти, не говоря уже о стеке. Например, операция инкремента (увеличения значения на единичку) осуществляется в регистре всего за один такт процессора, тогда как фортовский инкремент вылился бы в засылку числа в стек (одна запись в память), вызов подпрограммы инкремента (второе обращение к памяти), чтение ею числа из стека (третье обращение к памяти), засылка в стек инкрементированного результата (4-ое обращение к памяти), выход из подпрограммы инкремента (5-ое обращение к памяти), забор результата из стека вызывающей программой (6-е обращение к памяти). Всё это в тактах процессора стоит довольно дорого. Тем более что при отсутствии специальной фортовской функции вычисления инкремента пришлось бы прибавлять единичку явным образом - заталкивая ее в стек дополнительно. Обращений к памяти получилось бы тогда еще в полтора раза больше.

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

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

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

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

+

Весь пост, пока нет желания комментировать
(слишком длино написано и бросающееся в глаза недостаточное владение материалом описываемого предмета (без оскорблений откуда "почерпнули" информацию?)
Одна только констатация, что стек (служит для хранения также адресов возвратов характеризует уровень знания темы (хотя на стеке
данных и могут появляться при необходимости адреса кода слов, но в Форте есть ещё стек возвратов (управления) где и "осядают" адреса возврата
и например управляющие переменные циклов) + есть ещё механизм локальных именованных переменных(если уж совсем невмоготу)
При реализации модели САLL вызовов слов они не прерывается операторами PUSH. если специально не вынесено действие PUSH при построении кода вне CALL (это модель
реализации Форта называется подпрограмный шитый код, есть и другие модели вплоть до генерации нативного кода см.например SP-FORTH)
Попутный вопрос - вы отлаживаете вручную Си код на уровне ассемблерных команд процессора?
Искривление сознания приводит к тому, что вклчается и "проcтранственое" мышление 10 BEGIN ... бла бла бла 1- ?DUP UNTIL (инкрементируется в цикле и служит
счётчиком число положенное в начале цикла 10 не куда не деваясь, как это не страшно может выглядеть)

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


Вряд ли это действенный метод. Как например такой пример Qt-Forth - это засчитывается?
Чаще всего интересует вопрос - а смогу ли я на данном средстве-языке-инструментарии решить 90% типовых задач не прилагая "особых" усилий? Ответ в отношении
Форта может звучать так - нет т.к. на нём не решены какие то прототипы из этих 90% задач, а смогу ли, при наличии терпения и желания - да.


Например сейчас решил "добить" частично решённую ранее задачу - компилятор из Си в Форт. Зачем? Скажу просто. например чтобы було а дальше видно будет.
можно, наверное, использовать для переоса Си кода в Форт вариант или иметь вариант интерактивного Си со средой выполнения и например оптимизации Форт...
Если С/С++ врос в Вас "всеми корнями", то может быть Форт и не рассматривать.


Почему нельзя? На С/C++ данное изделие (Форт в контроллере) тоже сделано много реализаций.

P.S. Пока ленюсь и не программирую (работа тоже не с программированием) есть время вести дискуссию.

Похвальное желание "закопать" Форт поглубже.
Есть, например, и такие экспериментальные площадки разработки http://thyrd.org


Форт всегда присутствовал и присутствует на нише встроенных приложений. (если кто то не в курсе)

P.S. Хenia. Предлагаю Вам написать корректирующий пост на весь "пафос" высказанный постом выше. (короче полный пипец и суши вёсла)
C описываемыми Вами перспективами по оперированию информацией можно стать "инвалидом" программерского труда, а ситуация с компиляторами
которые только и занимаются в RISK архитектуре "считыванием" информации для ппрограмм в "мусорные" регисты вообще плачевна. (поэтому возможно
стековый код и "уделывал" Си регистровую оптимизацию компиляторами (по обсуждению с RSDN) до появления Pentium процессоров?)
Прозвучавшее слово обязательный забудьте в применении к Форт (там больше правит анархия программиста разработчика, который может установить
свои "правила игры" исходя из ситуации) и не смешивайти языковые возможности Форта и результирующий нативный код который будет выполняться на целевом процессоре.
По Вашему Java, MSIL байт код (в основе стековая модель) вообще один сплошной тормоз?

т.е. сначала была CISC, но микропрограмма не давала "чудесным" способом уменьшить растактовку? и RISC решило эту проблему?
(вспоминая тормоза древнего 51-го ядра и быстый AVR , но при этом существовала MISC которая обходила, как минимум CISC архитектуру)
А вспомнив законы диалектики, что если где то прибыло, то в другом месте убыло всё встает на место т.к. и в цирке все фокусы объяснимы.

P.S. Всю описываему Вами цепочку выполнения кода 0-операндной машины (не вдаваясь в её корректность) можно ускорить если прочитать эти команды в группе, как
обычную CISC команду на выполнение, потеряв частично в энергоэффективности архитектуры) как и проиcходит, в общем то, при сравнении AVR и MSP430 (к тому же при проектировании MSP430 инжнеры оказались гораздо "изворотливее" в принятых решениях)


Ага передаём между функциями указатель на данные, а сами данные "чудесным" способом обрабатываются минуя регистры
Правильно я это понял И прочие нормальные языки больше не используют стек для передачи параметров? Может и к лучшему? Накой он это вообще стек нам сдался


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

Несогласие с мнением оппонента принято коротко выражать знаком минус ("-"), а не плюс ("+"). Плюсом же принято выражать согласие.

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

Рискну предположить - используется в большей степени для отладки и тестирования.
Go forth

"Нежданно-негаданно" Форт тематика пополнилась ещё одной "игрушечной" темой предположу что,близкой к контроллерам и может "приглянуться" местной embedded "тусовке".
Forth в игре, или Red Power 2 Control для MineCraft

P.S. Виртульные технологические миры всё ближе и ближе дальше не развёртываю тематику складывающихся моментов...( У кого то детки играют в эту игру?)

Да, часто для этого. Кроме того, как командный язык для общения с приложения на PC. Отчасти это унаследованное от времен, когда сами устройства программировались на Forth.
ИМХО полезно иметь в устройстве полноценный интерпретатор небольшого размера с возможностью компиляции скриптов в компактный код. Но я предпочитаю это в дополнение, а не как язык реализации основной функциональности.

Точка зрения, достойная профессионала.
А мне нравится сам процесс - "разработка через отладку". Комфортнее думается.

Ага, что только и какие подходы не используют профессионалы с использованием Форт.
Например, что бы "увеличить" прозрачность и гибкость создания кода есть один из вариантов поверх TCL, JAVA ... сделать вариант "Форт IDE"
и генерировать код этих языков из Форт ориентированного синтаксиса/семантики используя возможности целевых языков.
Forth to TCL
A Forth to Java Compiler
Простенько и со вкусом.

P.S. Что тут ещё можно сказать Форт многогранен. (из сериала 1000 и один способ применения Форт)

Форт может вполне занять уровень ассемблера (RTL, или скорее IL) и выступать в качестве бэкэнда к любому современному языку. Даже C#


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

Я тем временем накропал вводное слово - 2
Посмотрим, что выйдет в итоге.




Знаю, что Вы неравнодушны к ассемблеру msp430.
А как насчет ассемблера, встроенного непосредственно в контроллер
Хотя необязательно.
Можно и снаружи, а форт использовать как удобную макрообертку.

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


Читать статьи интересно и постепенно первоначальные знания предмета дополняется новыми гранями понимания.

Обсуждаемую конструкцию IF ... ELSE ... THEN можно генерировать и как описано в статье не привязываясь к необходимости учитывать применимость команд длинного/короткого перехода при статическом построении кода (такое есть в динамических стековых языках), только куда "выкладывать" адреса перехода, чтобы они "не мешали" остальному Форт коду (на стеке данных им не очень место, на стек возвратов тоже вроде ни к чему) а так сами
слова IF ELSE THEN - это слова немедленного выполнения и они сами знают как строить команды перехода для применяемого "железа"


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

MrYuran, а 4e4th имеется в наличии только в виде прошивки? Исходников погуглил - неувидел.
Хотелось посмотреть что изменено по сравнению с оригинальным camelforth430.

А в этот германский репозитарий не заглядывали?
Немецкая и голандские Форт группы одни из наиболее активных и "отметились" неплохими Форт системами, на их сайте есть и Wiki наполнение.

P.S. Например для генерация Форт кода amForth системы для AVR используется тулза g4.fs запускаемая из под gforth и wn32forth

О! точно. Kopa, спасибо. Полезная, на первый взгляд, ссылка.

Еще позволю себе запузырить камень в огород Форта . Обычно у микропроцессоров flash-памяти (ПЗУ) много, а SRAM (ОЗУ) на порядок меньше. А Форт, зараза , требует ОЗУ для размещения своих программ, поскольку большинство Форт-определений - это новые функции, прирастающие к основному ядру. А раз так, то не только Форт-программа строится в ОЗУ, и само ядро тоже в ОЗУ сидит.

Между тем, ОЗУ в МК дорого. Его и на массивы + стеки остро не хватает, а тут еще и Форт на эту память зарится, пытаясь разместить в ней код.

Перспективу использования Forth в микропроцессорах вижу там, где последним приходится выполнять терминальные (т.е. словесно-буквенные) команды с клавиатуры. Например, в роботехнике или станках с ЧПУ. И тут, чтобы не маяться, программируя интерпретатор, вполне можно соорудить простенькую Форт-систему. Причем, основные программы могут быть скомпилированы и залиты в ПЗУ, а ядро Форта их использует путем прямого вызова, как подпрограммы. Ну, а что сверх того, то пишется на самом Форте.

Когда-то я и сама писала нечто похожее на Форт-систему (правда на платформе x86), только не на языке Forth, а на C/C++ . Всё это компилируется в стандартный экзешник, при запуске которого сразу попадаешь в Форт-интерпретатор с уже предопределенным (!) набором команд. В том числе и те функции Форта, которые для этого языка являются стандартными и системо-образующими, тоже были вложены в него "от рождения", а не определены средствами самого Форта, как это обычно положено. Ну, а поверх всего этого уже можно было загружать чисто фортовский текстовый исходник, который достраивал ядро до полного приложения. Вот только ... я этого не делала , а всё, что мне было нужно, написала на Си и откомпилировала всё целиком. Т.е. от Форта там остались только рожки да ножки - тело каждого из определений содержало единственный вызов CALL, уходящий в ассеблерно-сишную часть программы. Однако всё это ничуть не мешало создавать новые определения на базе старых и в дальнейшем использовать такую Форт-систему обычным образом, как это в языке Форт водится.

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

Можно сказать, что в этом качестве Форт выполнял роль продавца-раздатчика уже готовой продукции. И вот эта роль, несмотря свою непрестижность, вполне может востребована при работе с МК. При этом ОЗУ расходуется минимально, а ПЗУ на всю катушку. Да и сам код программист пишет на любимом ему языке, не связываясь с Фортом , и скомпилированную прошивку во флешь тоже заливает обычным образом. Особенность же здесь только та, что подключив к такому МК терминал (клавиатура+экран) через UART или USB канал, обнаруживаем, что с таким МК можно разговаривать на человеческом языке . Односложно, правда, но это не такая уж большая беда. Более того - не изменяя прошивку, можно "доучить" МК, послав ему с консоли Форт-программу (send file). Одно только плохо - при отключении питания такой МК напрочь забудет, чему он учился на Форт-языке, но свои прошитые во флеш умения, несомненно, сохранит. И, тем не менее, такой механизм дает возможность для проведения испытаний новых идей "на лету", прежде чем внести их в следующий вариант прошивки. Например, (хотя бы для отладочных целей) целесообразно предопределить в том Форте команды чтения и записи в порты. Причем не просто записи, но и изменения отдельных битов порта. От этого уже будет большое подспорье при наладке, когда с клавиатуры можно изменять и выставлять уровень на любой ноге (из тех, что на это способны).

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

Отладка обычно так и шла, пословно, иногда помодульно (ОЗУ часто очень немного, модуль может не влезть, плюс не быстрая пересылка текста модуля и компиляция на микроконтроллере) с периодической перекомпиляцией целевой платформы. Есть свои серьезные плюсы за счет интерпретатора, но в целом я бы не сказал, что получается эффективнее и удобнее, чем с компилятором и внутрисхемным отладчиком.


Если правильно понимаю, он не умеет делать кросс-компиляцию с форта.



+1. Я к такому же пришел. Частенько прикручиваю простой форт-подобный интерпретатор, написанный на С, иногда в виде фоновой задачи RTOS.

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

"Круто!... Но за чем?" (с)

Чёт я не вижу применения этой технологии (или способу работы с МК?). У меня сразу возникает куча вопросов, на которые я не могу себе ответить.

Такое ощущение, что придумываем технологию, а потом под эту технологию ищем задачи -- подойдет/не подойдет? А, фигня, натянем!

ЗЫ, к своему стыду все еще не нашел времени прочитать Вашу публикацию на изяэлектрониксе. (Может быть сегодня прочту.) И эту ветку тоже выборочно читал. Эх, времени нет!


Прямо секта какая-то!


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

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

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

+1
Форт идеально подходит либо только под надуманные задачи, либо только тогда, когда для его применения созданы идеальные условия. А много ли их?

Немного не в тему.
Когда я освоил 51-е ядро я думал, что это еще один пунктик в моей Си-Ви (резюме) к архитектуре i8080, i8086/88, Z80. Это было хорошо! Это было нужно.
Потом пришла очередь изучать AVR. Еще один плюс в си-ви. Я стал еще чуть-чуть круче. Через несколько лет жизнь заставила освоить MSP430. Я стал еще "умнее", еще прокаченнее. Не предела совершенству! Потом настала очередь за ARM7 от ATMEL и от NXP. Сейчас мода пошла на Кортексы. Не отставать же!

И вот тут я понял, точнее -- прочувствовал на себе принцип "бритвы Оккама". А я только затронул STM32 и немножечко вкусил LPC1114. У меня в голове уже начинают путаться регистры преиферийных устройств, опции компиляторов. Я уже начал забывать, что у ATMEL-овских процов отсустсвует поддтяжка к земле, но присутствует функция подавления дребезга. Я уже не могу вспомнить опорные напряжения для компараторов и АЦП для разных процов. Это какой-то кошмар из многократно дублированных сущностей. Знать их (и соответственно так же и использовать) на поверхностном уровне уже не поучится, приходится копать глубоко. Но у каждого проца своя специфика... Зная тот или иной проц, его ядро, уже не получается пропускать мимо ушей новости, связанные с ним. Объемы перерабатываемой информации стали колоссальными, и я не побоюсь этого слова -- неподъемными для меня. В общем, у меня случилось обжорство.

Добавьте сюда еще и то, что количество компиляторов и других рабочих инструментов резко возросло из-за того, что я задвинул на Шindows и переехал на ПМЖ на Линух. (К стати, прошло уже много лет, и я не жалею ни капли!)

Я не плачусь, я не жалуюсь на свою судьбу. В конце концов, я этого сам хотел. Но я утверждаю, что возможности мозга не безграничны, как нам это втирали в школе. Кроме того, в сутках не 48 часов. Иначе говоря, поддерживать актуальность такой масса знаний становится невмоготу. (Не поверхностных знаний, а реально глубоких!) Знания морально стареют и их надо периодически подновлять. При этом, эти знания (собаки!) -- их невозможно вытереть из мозга. Они тма сидят, они мешаются, они дают ложные ассоциации. Они путаются под ногами...

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

Да, прибудет с вами мудрость!

Парадокс старости в том, что ты получил богатый опыт, а применить его времени уже не осталось. (с) Станислав Лэм (цитату написал не точно, по памяти)

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

P.S. Ваш пост на "изиэлектронике" очень большой, пространный, но "абсолютно" пустой. (с моей точки зрения). Кто осознанно использует
Форт и решает на нём мелкие и не очень задачи, предположу что, наверное имеют какие то критерии выбора для используемых иструментов?
Остальной "оффтопик" поcта мне понятен и близок. Все мы "заложники" искусственно выстроенных и принятых на веру "принципов", но хорошо бы эти принципы понять и объяснить и подумать что действительно важно, а что наносное.
Форт уже (или ещё) не Ваш путь, то это не повод притягивания своего опыта, для обоснования "единственно" правильного и беспорочнего.
Прочитал недавно, что на советских Агатах, в отладчик кода, Форт "внедряли" в виде sys драйвера и узнал о том, что такие компьютеры были


Истинные Форт джедаи следуют своему пути и занимают призовые места на конкурсе производителя. (не считайте рекламным ходом)
PbjTech.com (ссылку вроде уже приводил)


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


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


Возможно я "мамонт", но мне никогда не нравился цикл ("ввод текста -> "длительная" компиляция -> возможнсть пошаговой отладки " кода функции-> в начало) сверясь с отладчиком в правильности использования возможностей конкретного языкового средства.


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


Всё это уже придумано за нас. Мы только можем развивать или нет это направление и использовать или нет "придуманные" подходы.


+1
Мне это подходит лишь бы была возможность "простой" заливки кода без необходимости покупать отладчик.

А есть ли какие "следы" в i-nete этих проектов? (хоть намёком)


Не без этого (это не первый Вы подметили)

"

В 1971 г. Чарльз Мур разработал язык для управления оптическим телескопом и, считая его языком четвертого поколения, назвал FOURTH (четвертый). Однако на ЭВМ, на которой он работал, символьные имена могли иметь только пять букв. Так FOURTH стал FORTH (Форт). Несмотря на конкуренцию других языков программирования, в частности языка Си, Форт мало-помалу стал завоевывать популярность, особенно при решении задач управления сложными объектами в реальном масштабе времени.

Язык Форт использовался для математического обеспечения корабля многоразового использования типа Шаттл, разведывательного 1802 (Avco Inc.) и других искусственных спутников Земли, для разработки телеигр (CameFORTH), при создании фильмов Star Wars, Batlle Beyond the Stars и Star Trek, для системы управления полетами в аэропорту Эр-Рияда (400 ЭВМ и 36 000 датчиков) [24]. В 1976 г. Комитет международного астрономического союза принял Форт в качестве стандартного языка программирования. Позднее Форт применялся для создания экспертных систем, систем искусственного зрения, автоматизации анализа крови и кардиологического контроля, систем машинного перевода с 20 языков (Craig M100 – карманный переводчик) и т. д.

В СССР этот язык используется для систем управления базами данных экономических задач, для программ управления экспериментом, мониторинга состояния пациентов.
"(с) Ю. А. Семенов
Баян, конечно...

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

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

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

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


Вы ниже по тексту что-то там про программатор говорили... Прокомментируйте, пожалуйста, а то не совсем понятно, что вы имеете в виду.


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

Возможно, в обществе, где 99% граждан говорят на китайском языке (аналог -- 99% программистов используют Форт), и только 1% говорят на русском (используют другие языки программирования), такое положение дел будет считаться нормой. А разговор на русском и написание программ для МК на С/С++ -- однозначно будет толковаться как извращенное понимание. Но мы то живем не в Китае... И насаждать китайский язык на некитайской территории -- это по меньшей мере волбтнаристично и не обдумано. Кому надо, тот сам найдет курсы китайского и курсы по Форту. Но таких граждан, извините, -- очень и очень немного.

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



Да, согласен. Пустые разговоры ни о чем. Мы говорим на разных языках, у нас разные ценности, у нас разные понятия. Надо прекращать это словоблудие.


Замечательно! Я тоже довелось иметь дело с Агатами. Однако вопрос. Агат -- это, конечно, хорошо, но где сейчас эти Агаты? Почему они там и не имеют продолжения развития? Почему так мало драйверов, написанных Форте? Такое ощущение, что писали их случайные люди, которые кроме Форта не знают ничего другого.

Из моей практики, я работал с одним товарищем, который написал драйвер руссификации принтера на Фортране. По тем временам Винды еще не было, драйвер был написан для среды ДОС в виде TSR-программы. Вспоминайте, кому много лет, -- TST == Terminate and Stay Resident. Прога оставалась в памяти: 350 кбайт (или около того) было не хилой потерей из 640 кило. Но работало! Суть истории же в том, что хотя драйвер и был написан писан и даже вроде как выполнял свою функции, но задача была выполнена крайне непрофессионально. Где сейчас этот драйвер? Почему он не получил своего развития и ушел в небытие как толко появились аналогичные драйверы, написанные на ассеблере и на С? Какой опыт получил программист-математик создавая этого монстра? Я подскажу -- извращенный опыт создания программ. А зачем оно это надо? Зачем учиться изврату? Зачем мне изучать китайский, когда я отлично владею русским и никаких китайских "соприкосновений" в ближайшем будущем не предвижу?


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


Однако. Пора и делами заняться. Я не вижу смысла продолжать нашу беседу, хотя для меня она приятна (без сарказма -- приятна!) Реально, вы помогаете мне сориентироваться в море соблазнов и достойных целей. Спасибо Вам за уделенное время. Вы и MrYuran -- хорошие собеседники. Я уверен, что мы еще не раз пообщаемся и, возможно, даже на территории Форта.

Ага, уже выиграли и Windows и Linuх (не в упрёк этим системам), но мой текущий выбор ось Haiku (почему даже самому не понятно)
но в тырнет и на форумы я захожу из неё, как это ни извращённо может выглядеть и запускаю её с флеш носителя или Live CD.
Потихоньку пытаюсь "обжится" в ней и использовать необходимые мне вещи.

Баян-не баян, суть дела не меняет.

Давайте посмотрим на даты и зададим себе вопрос -- были-ли в те времена какие-то другие более эффективные средства для создания и отладки целевого программного обеспечения? В те времена не то, что Линукса или прасти-оспади -- Шindows -- не было даже ДОС-а. Не было замечательной серии Турбо-компиляторов фирмы Борланд. Не было персональных компьютеров в том виде, в каком мы имеем их сейчас. Персональные компы начали свое наступление где-то со средины 80-х, когда стали широко доступны i8080 (и его клоны), Z80, 6502 и другие. Когда на базе 8088 начали клепать налево и направо IBM PC. Только с прорывом харда начал развиваться софт. А до того -- был какой-то зоопарк Jurassic Park.

Да. Вы правильно подметили. На фоне динозавров того древнего Парка Форт имел неоспоримое преимущество среди других языков и технологий. Но Вы не заметили одного -- мир изменился. Мир изменился качественно.



Во-во! И я о том же! Мыслите правильными концепциями, а не ставьте из с ног на голову. Конкретно -- обратная польская запись повлияет на восприятие мира и приведет к извращенным понятиям.

Общество удивительно устроено. Что бы мы ни делали, всегда в обществе будут и лодыри-тунеядцы-пьяницы. Это закон природы. Даже если мы их будем периодически как-то удалять из общества, они все равно будут в нем появляться. Я это явление объясняю как наглядную демонстрацию закона "смотрите, как не надо жить". Общество само вырабатывает малое количество "яда", для своего же блага. Дабы остальные граждане практически могли видеть что есть "зло". То есть случайно скатившийся в "зло" человек, автоматически становится ярким примером того как не надо жить. 99% граждан это видят и отходят от "помойной ямы". Не будь этих пьяниц, было бы не совсем понятно, почему пить одеколон "некомильфо". А выпив одеколон -- индивидуум превращается в предупреждающий знак для других.

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

Мне надо бы было привести какой-то другой пример, а то ассоциация с пьяницами очень не приличная. Но я ничего другого придумать не могу. Единственное, что ямогу сказать, что Форт -- это не абсолютное зло, как, например, водка. Форт -- это такая технология, которая должна подсказать людям -- "Туда ходить не надо!"

Ладно. Поживем -- увидим!
Если в Форте есть что-то стоящее, то не смотря ни на что, он расширит свое присутствие. Если вообще ничего нет -- схлопнется в ноль. Размер сектора, который занимают те или иные технологии, это естественный (объективный) фактор. Если Форта 10 раз меньше, чем С/С++, то столько же в нем и пользы. Мощность множества (математическое понятие) различных технологий и языков дает куда более объективную картину, чем ты тут друг другу рисуем.

Может уже закончим, а?

Да, действительно пустые разговоры, если не принимать во внимание реалии бытия. Где Агаты? (в выпускаемых и применяемых микросхемах архитктуры 6502). Где PDP-11? (MSP430 приемник идей заложенных в эту архитектуру), но так ли уж всё это важно? чтобы понимать, что
мир не настолько "плоск" для объяснения используя бытовые понятия.


Ничего не проясняет? Canon Cat Джефа Раскина в этом зоопарке?
Хотя ход времени неумолим.


Пипец. А выбор есть? или все поголовно в ряды С/С++ программирования? и долгих лет постижения "глубин" программирования с помощью
данных инструментов.
Даже те кто пишет на С/С++ бывает не в восторге от данных инструментов и создают Perl, Phyton, Ruby, TCL, JAVA и ещё nnnn-ое количество
языковых средств от хорошей жизни. При это, хоть и существует огромное многообразие Форт систем, но они всегда узнаваемы и не требуют,
зачастую, переосмысления известных фактов. (как например появление языка Factor и ухода его создателя от использования Java? Какие
проекты на нём пишутся или будут разработаны, боюсь мы даже не узнаем)

P.S. Что дальше после ООП какая парадигма программирования правит умами? Считайте меня извращённым уродом, если так Вам спокойнее жить.
И удалите меня из общества! (как порочащего гордое звание программиста)


Где вы видете обратную польскую запись (это только ярлык для общего прояснения).
Банально и утрировано что удобнее?
Мотор включить или Включить мотор
решайте сами и покажите мне в каком случае применена обратная полькая запись? чтобы понять весь изврат?

PDP11 -- это все же компютер, а не МК. К нему подключали полноценный терминал. У этого компа отсутствовал старший "брат", на котором можно было бы осуществить кросс-компиляцию. Таким образом, глупо тащить все технологии с компов на МК. Даже если у них походят архитектуры, то назначение-то у них -- разное!


Извините, я ничего не понял. Ну да -- комп, ну да -- с Фортом на борту. Ну да -- давно это было. Что дальше-то? О чем это должно было сказать?


Вы передергиваете. Мы, во первых, говорим о применения языков программирования к МК, а там в основном только эта пара (С и С++) и используется. Но сейчас, давайте за троллим друг друга и уйдем в детали, давайте заставим друг друга перечислять все языки и указывать процент их присутствия. Если мы пойдем по этому пути, мы вообще утонем в мелочах. Дьявол кроется в деталях.

А во вторых, если Вы считаете, что мы говорим о Форте вообще, то почему наша беседе проходит на форму микроэлектроники и МК, а не на форуме общем программирования? (Хотя по большому счету, я и особых применений Форта на компах тоже не вижу. Тут зоопарк используемых языков, будет значительно больше, чем
языков, используемых для работы с МК.


Ого! Куда пришли!

Сейчас контроллеры обходят компьютеры того времени по всем показателям. А не глупее ли тащить "мощные" МK туда, где может
справится "хиленький" контроллер? Или уже произошло смещение понятий?
(Lnuх уже затащили в контроллеры)


О том, что и тогда умели программировать и что "серебрянной" пули не существует (по книге Брукса 16, 17гл.)
Уложились с софтом офисного плана в 256Кб.(сейчас, конечно, не до экстремальных рекордов, только на энтузиастов типа колибри-строителей-ОС)


Потому что Вы используете С/С++ для программирования контроллеров, а мну, по возможности Форт.

P.S. А по большому и не надо, достаточно для примера, что есть массовые nncron и eserv из известных "продвинутых" разработок,
а будет у кого то потребность в реализации на Форт своих "глобальных" проектов. то возможно мы о них узнаем.
@ Если мы чего то не понимаем, это не значит что понятия наши слабы, просто это не входит в круг наших понятий (Козьма Прутков)

А я-то здесь причем? Зачем Вы меня в Христа-то записываете? Я могу отвечать только за себя и своих детей.


Да хрен его знает что там произошло. Меня это тоже бесит. Особенно труды типа библиотеки CMSIS и библиотеки периферийных устройств. Как ни крути, но если действительно хочешь заниматься на высоком уровне, то по любому придется изучать работу регистров устройств, их состав, названия битов и пр. Получается так, что к тем знаниям, которые и так нужно знать, добавляется слой знаний, который по объему соизмерим с базовыми знаниями (регистров), и делает тоже самое, но лишает разработчика твердой почвы. Это обман и надувательство!


Ревнуете? И Шindows бы туда затащили, но ...

Да, нет. Если задача решается с помощью Linux это лучше, чем она неопределённо когда была сделана
пусть и максимально эффективно. Time маркет ещё никто не отменял.

Это Вы погорячились.


"В начале 1980-x на основе языка Форт Джон Уорнок и Чак Гешке из Adobe Systems создали язык PostScript[7], широко используемый для управления устройствами печати и послуживший основой для создания формата PDF. " (с) Форт(язык программирования) - Википедия
"Формат PDF стал международным стандартом" http://www.lenta.ru/news/2007/12/05/pdf/


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





Я полностью согласен с Вами, если речь идет о любительских "самопальных" фортах.
Но если рассматривать профессиональные (коммерческие) системы типа SwiftX, то извините-подвиньтесь...

А мне ещё интересно было глянуть, на Форт систему для контроллеров от MPE и желательно с полными исходниками,
а то на их сайте только для PC версии доступны, а для контроллеров даже триал версий на сайте нет.
Хорошая и производительная система из западных и I-Forth, но она только для PC

Вот вы тут спорте, спорите...
Десять и пятнадцать лет назад (и десятилетнее даже нагуглилось по словам «читаю и перевожу СО СЛОВАРЁМ») я даже принимал участие в подобных разговорах. Причём с позиции «доброжелательной заинтересованности» (Баранов-Ноздрунов у меня бумажный свой, купленный в 1988 по предварительной подписке в книжном магазине, просмотрен, отложен в силу «да я и на С не пишу сейчас», прочитан в середине 90-ых с карандашиком и бумажками). И параллельно прикидывал 4-витковый форт-процессор для Altera Acex (в смысле вот у нас конвейер всё равно, делаем его 4-стадийным и запускаем 4 потока исполнения, на каждой стадии конвейера команды из разных потоков, получаем четыре ядра, расшаривающих существенную часть аппаратуры).
Но вот так и не смог я тогда найти время для освоения форта на таком уровне, чтобы самому себе сделать кросс-компилятор. Хоть какой-то, не говоря уже о приличном. Так как для этого надо было бы оторвать время от не_работы, поиграться на не рабочем проекте.

Фришного ничего такого не нашлось. Вроде был какой-то для 51-го для зашивки в ПЗУ и работы оттуда.
Но меня не интересовали системы со встроенным полновесным фортом. Ну не нужен был он там, в целевой системе. Ни в AT89C51, ни в AT90S4433 с их 4 килобайтами флеша, ни в альтерине.

Я хотел на какой-то игрушке просто пописать на форте небольшие программки и посмотреть, как оно ляжет в руку. Или, точнее, совпадёт ли «кривизна инструмента с кривизной извилин». В оба раза (15 и 10 лет назад) всё заканчивалось приблизительно как в сообщении из RU.EMBEDDED по линку выше — даже у человека, использующего в форт в своей жизни, руки не доходят до целевого компилятора. Кто работает -- работает или только на PC, или на большой плате.
Кто-то один на мои просьбы прислал в приват фрагменты своего кода для микроконтроллера (там был по сути ассемблер с фортом как структурной макрооболочкой над ним). Но -- «системой поделиться не могу, это наше внутрифирменное».
Т.е. с фортом у меня вышло как у многих с линуксом -- нужно преодолеть некоторый порог, а ради чего -- непонятно (к ривизне извилин еще не примерил). Да, вот мне такому ленивому нужно было что-то, чем я «из коробки» помигаю светодиодиком (но, повторюсь, в целевой системе без форта -- играться с зашитым фортом в имевшейся плате с 80с32 +32К ROM + 8K RAM не хотелось без уверенности, что при «вдруг понравится» результат можно будет малой кровью перенести в реальные изделия).
Соответственно лет восемь я в ту сторону и не смотрел.

Ну так вот. Форт для зашивки в копеечный кит с 16К-флешным MSP430 это хорошо. Хотя MSP430 мимо меня как-то прошёл. Или я мимо него.
Есть ли сейчас что-то для AVR, что можно поставить «в два клика» и не вытягивая отдельно win32-шный форт, не разбираясь, как к нему прикрутить отдельно выкачанные надстройки, про которые все говорят, что их можно прикрутить, но никто сам не прикручивал, ... и получить кросс-компиляцию для AVR? Может, для CM3.

Впрочем, сейчас в режиме «поиграться» я уже и на встроенный форт согласен, платки с ATmega64 валяются как расходный материал.
Но токо чтобы оно, чёрт побери, работало «ис каропки». Хотя бы как avr-gcc 2.95 (прописью - два-девяносто-пять, а не четыре-семь и даже не три-четыре-два), на котором я в затёрто каком году работал.
Так как и тогда, и сейчас мне интересно не только это. А когда мне перестанет что-либо быть интересно -- я не знаю, но уже понимаю, что время стоит экономить. По этой же причине я хоть и проявляю (довольно пассивный уже) интерес к форту, но на MSP430 пробовать его не собираюсь, читать доку на MSP430 без уверенности в применимости в ближайшее время не буду. AVR ещё применяю, Cortex-M3 уже.

Ага.

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

Прямо сейчас есть прошивка amforth 4.8 ( хотя уже появился amforth 4.9 ) для Atmega32A . Могу поделиться. Могу собрать прошивку для Atmega64, но не сразу (по техническим причинам).
amforth http://amforth.sourceforge.net/ прекрасно подходит для "поиграться" http://roboforum.ru/forum58/topic4406-60.html

Вот и ответ на причины малой распространённсоти форта :-) Эт вам не аврстудия+вінавр или там кодевижн.
У меня-то atmega32 в неликвидах несколько штук лежит, а вот платки с ней нет. В платах есть mega64, mega128, mega2560.

Линки в закладки положил, спасибо. Позаглядываю по свободе («по обіді»).

Цитата оттуда:
Ну вот разговоры о том, что это всё (включая оптимизацию линейных участков в чисто регистровые манипуляции без операций со стеком, без заталкивания/выталкивания) вполне возможно и реально и тогда форт-программы будут быстрые — шли «ещё тогда», 15 лет назад. Но критической массы фортеров не хватило для создания продукта не то что уровня gcc, хоть бы SDCC.
«Или нет?»™

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

P.S. В разделе по АVR тоже есть инициированная Форт тематика, также и как впрочем PIC, остальные контроллеры. Отметился ли в ARM точно не скажу, но и для ARM есть с чем поработать.


Есть неплохая система, поддерживающая "много" контроллеров, в том числе AVR-ки разные (сам её использовал и переделывал для PDP-11, но АVR Атмегу 8535 планирую к ней подключить и "оживить" тематику дальнейшего использования, в реалиях текущих производственных замыслов)
ff303 и немного уже кем то поправленая, ff303s (ссылки найти не составит труда) или ещё спрашивайте

Спасибо за ссылку (читаю) в то время у меня совпали возможности и желание использовать Форт. (и сделал я тогда себе "самодельный" компилятор)
сейчас IT> уже доктор наук


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

Для контроллеров нет сплочённого сообщества одной системы, если такое в принципе возможно. А также критической массы, в отличии
от той же Германии. На чешском сайте FIG, кстати, были примеры использования amForth

Да вот именно что «хотелка». Когда-то не смог поиграться, сейчас что-то шевельнулось.
Хотя С в руке сидит хорошо и С++ потихоньку затягивает. Шаблоны штука хорошая при аккуратном применении.
Так что сейчас хотелка состоит в реализации (при наличии времени и вдохновения) на какой-то платке из имеющихся сделать что-то небольшое реальное и в меру нужное (т.е. если что -- то или объявится ненужным, или будет на С написано).

Что можно пожелать? От трудностей никто не застрахован, а будет ценным или бесценным опыт кто может знать?
Про Форт, в своё время, я тоже узнал из книги Баранова-Ноздрунова и это предопределило мои возможные приоритеты. Понимание шитого кода далось не сразу, как и понимание механизма бэктрекинга в Прологе, про лисп даже можно не вспоминать ("пережёвывал" c большим трудом, но так и не зацепило)
А сейчас, даже и не знаю, стоит ли тащить реализацию схемы шитого подпрограмного кода в контроллер если нет задачи сильного ужимания и
впихивания в контроллер программы, а ограничится возможной оптимизацией подпограммного или нативного кода контроллера при с использованием "некоторых" скромных навыков владения программированием. и/или может подумать о добавлении, например, второго, третьего, ... контроллера в схему.

P.S. При наличии уже сформировавшегося "отличного" опыта возможно формирование особой ценной точки зрения на предмет

http://oko-planet.su/finances/financesday/...nih-lyudey.html
Sorry, не удержался.
Сразу вспомнился фильма BraZil

ReAl, спасиба за ссылку, почитываю

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