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

Сообщение отредактировал Kopa - Nov 3 2012, 15:43

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

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

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

Сообщение отредактировал Kopa - Nov 5 2012, 00:49

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

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

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

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

Сообщение отредактировал Kopa - Nov 9 2012, 12:13

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


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

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




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

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


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

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


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

Сообщение отредактировал Kopa - Nov 10 2012, 06:44

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

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

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

Сообщение отредактировал Kopa - Nov 9 2012, 14:50

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

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

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

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

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

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

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

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

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


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



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

Сообщение отредактировал SBE - Nov 9 2012, 16:28

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

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

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

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

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


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


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

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