[Kopa 0]

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

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

Изменено 3 ноября, 2012 пользователем Kopa

[chu 0]

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

 

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

Go forth

[Kopa 0]

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

Go forth

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

Forth в игре, или Red Power 2 Control для MineCraft

 

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

Изменено 5 ноября, 2012 пользователем Kopa

[SBE 1]

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

Go forth

 

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

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

 

 

 

[chu 0]

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

Точка зрения, достойная профессионала.

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

[Kopa 0]

Точка зрения, достойная профессионала.

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

Ага, что только и какие подходы не используют профессионалы с использованием Форт.

Например, что бы "увеличить" прозрачность и гибкость создания кода есть один из вариантов поверх TCL, JAVA ... сделать вариант "Форт IDE"

и генерировать код этих языков из Форт ориентированного синтаксиса/семантики используя возможности целевых языков.

Forth to TCL

A Forth to Java Compiler

Простенько и со вкусом.

 

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

Изменено 9 ноября, 2012 пользователем Kopa

[MrYuran 29]

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

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

 

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

Сравнивать надо сопоставимые вещи.

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

Ещё неизвестно, где больше.

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

По результатам отладки (пословно, помодульно, комплексно) можно скомпилировать целевую оптимизированную прошивку.

 

Я тем временем накропал вводное слово - 2

Посмотрим, что выйдет в итоге.

 

 

 

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

 

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

Знаю, что Вы неравнодушны к ассемблеру msp430.

А как насчет ассемблера, встроенного непосредственно в контроллер :)

Хотя необязательно.

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

[Kopa 0]

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

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

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

 

Я тем временем накропал вводное слово - 2

Посмотрим, что выйдет в итоге.

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

 

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

слова IF ELSE THEN - это слова немедленного выполнения и они сами знают как строить команды перехода для применяемого "железа"

 

Знаю, что Вы неравнодушны к ассемблеру msp430.

А как насчет ассемблера, встроенного непосредственно в контроллер :)

Хотя необязательно. Можно и снаружи, а форт использовать как удобную макрообертку.

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

такие процедуры легко тестировать локально, а запрограммированы они могут быть как на ассемблере, си или форте.

Изменено 10 ноября, 2012 пользователем Kopa

[chu 0]

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

Хотелось посмотреть что изменено по сравнению с оригинальным camelforth430.

[Kopa 0]

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

Хотелось посмотреть что изменено по сравнению с оригинальным camelforth430.

А в этот германский репозитарий не заглядывали?

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

 

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

Изменено 9 ноября, 2012 пользователем Kopa

[chu 0]

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

 

[Xenia 46]

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

 

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

 

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

 

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

 

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

 

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

[SBE 1]

Сравнивать надо сопоставимые вещи.

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

Ещё неизвестно, где больше.

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

По результатам отладки (пословно, помодульно, комплексно) можно скомпилировать целевую оптимизированную прошивку.

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

Если нужен полноценный интерпретатор, и к тому же компилирующий компактный байт-код, то мне очевидно, что Форт практически вне конкуренции по размеру.

 

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

 

Я тем временем накропал вводное слово - 2

Посмотрим, что выйдет в итоге.

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

 

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

 

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

 

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

Изменено 9 ноября, 2012 пользователем SBE

[chu 0]

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

 

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

[zhevak 0]

Знаю, что Вы неравнодушны к ассемблеру msp430.

А как насчет ассемблера, встроенного непосредственно в контроллер :)

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

 

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

 

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

 

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

 

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

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

 

Особенность же здесь только та, что подключив к такому МК терминал (клавиатура+экран) через UART или USB канал, обнаруживаем, что к МК можно...

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

 

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