Форт (Forth) и MSP430 для изучения, Программирование и исследование на Форт Опции

[Kopa]

Есть интересное направление -
например, в частности, использование Форт языка для быстрого и эффективного изучения возможностей контроллера MSP430 и внешней периферии.
4e4th

Код

4E4th on the LaunchPad - 8/16K
Recently we had a meeting in the Lower Rhine region dreaming about a small nice affordable board with a modern MCU and a compact Forth inside.

There it is!

The TI LaunchPad with 4E4th on it. 16K FLASH - 8K Forth and 8K for our own apps. The 4E4th is covered in a 20Pin DIL MSP430G2553.
Now our goal is to supply a TI LaunchPad ready with the MSP430G2553 and Forth inside - all for 4€ - plug in the USB, open the terminal, and there we go! CamelForth430 is the kernel of 4E4th.

I think these are exciting developments.

Michael

P.S. Возможно окажется полезным инструментарием проект немецкого Форт сообщества.
В репозитарии есть ещё некоторые Форт системы для MSP430.
Хотчется услышать мнение участников местного форума.

C MSP430 близко не работал, но "ностальгия" по системе команд PDP-11 осталась
И если приобрести launch pad ($4,6) то можно многое сделать используя Форт идеалогию.
Есть и другие Форт системы для MSP430, но наверное без "продвижителя" данного направления тема "заглохнет":)

Сообщение отредактировал Kopa - Sep 20 2012, 17:15

[Xenia]

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

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

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

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

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

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

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

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

[Kopa]

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

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

На микропроцессорной ниве (а за нее сейчас как раз и сватают Форт) ситуация для Форта тоже не слишком оптимистичная.

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

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

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

[Xenia]

+

Хenia. Предлагаю Вам написать корректирующий пост на весь "пафос" высказанный постом выше. (короче полный пипец и суши вёсла)

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