Форт (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

[zhevak]

Ага. Спасибо. Уже читаю.

Н-н... да. Забавно. Очередное Дурдуино для домохозяек.

Читаю, и иногда подвисаю на приятных воспоминаниях по временам РК-86...
Ну мы тогда Форт тоже изредка юзали. Так, не серьезно. Скорее от безысходности -- ведь Си-компайлера для РК-ашек тогда не было. Зато были широко распространены только ассемблер и Бейсик, которые закрывали почти весь спектр тогдашних задач. Ходил по рукам, правда, еще какой-то не работающий Лэйди-Паскаль. Ну и этот там был -- Форт. Был больше для "коллекции программ", чем для работы.

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

Может быть я чего-то не догоняю. Но мне кажется, что что-то все-таки ускользает от моего понимания. Что-то я не представляю, что же _такое_толковое_ можно написать на Форте, причем _это_толковое_ ну никак невозможно было бы так же красиво реализовать на С/С++? В чем фишка?

-- Чувствую, что меня кидают. А где -- понять не могу. (с) из анекдота

[Microwatt]

Есть в ФОРТе нечто особенное. То, что сейчас кроме С++ программисты ничего не используют - не показатель. "Профи" тут следует понимать как "ремесленник".
Можно прожить с английским, где практически нет падежей и родов, можно с русским, где шесть падежей и три рода. И никому вроде не нужен язык банту. А там, если случайно заглянуть, только родов около 20. И язык живой, миллионы людей используют.

При всем несовершенстве вычислительных возможностей ФОРТ это язык с порождающей грамматикой. Т.е. после некоторой начальной возни с программой она на более высоких уровнях начинает читаться как почти естественный человеческий язык. И допускает допрограммирование пользователем. Прямое объектноориентированное кодирование.
Кроме того, это чрезвычайно компактный в смысле расхода объема памяти язык.
Вряд ли его сейчас станут применять массово, но сама идея его построения заслуживает чтобы с нею познакомиться. Для гимнастики ума.

[Bloom]

я тоже изучал в свое время форт, было очень интересно... Но эта возня со стеком со временем просто достала. Как игрушка и для разминки ума форт приколен, но для производства...

[MrYuran]

Я, вот, только не понимаю -- где его (Форт внутри msp430) можно сейчас реально применить с пользой?

1. мета-язык (в т.ч. красивая обертка для ассемблера)
2. встраиваемый интерактивный скриптовой движок, который без труда ложится в любой контроллер, от младших пиков и авр до арм.
3. возможна очень плотная упаковка программы засчет использования байт-кода
4. распределенная система хост-таргет с возможностью перераспределения в ходе отладки
5. много ещё чего

Теперь о грустном: к сожалению, систем типа "сел и поехал" практически нет, а если есть (SwiftForth), то стоит вполне конкретно.

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

Вряд ли его сейчас станут применять массово

Посмотрите спецификацию CIL (основа дотнета)
Ничего не напоминает ?

[Kopa]

Вряд ли его сейчас станут применять массово

В этом есть правда.
При всём многообразии "своих" и не своих Форт систем, форт зачастую используется их создателями на задачах
малой и средней степени сложности или в личных разработка. Открытых "крупных" проектов с использованием Форта на компьютерах не много и они
тоже, зачастую, закрывают специализированные ниши (как то например Bios для OLPC, nnCron- планировщик) Ниша встраиваемых систем хорошо "пропиарина" для использования Cи инструментария (и архитектура контроллеров к нему близка) для использования менее гибкой, но зато
проще воспринимаемой системы программирования. (но например Factor язык не появился бы, если бы его разработчика в полной мере устраивал Java)
Форт не может восприниматься менеджерами проекта, как удачное решение, ввиду отсутствия профессионально подготовленных специалистов.
И поэтому, чаще всего, можно встретить Форт в изделиях компаний, как адекватный инструмент управления например роботами (Strobotics), внутреннего ядра для создания прибора (firmware Mosaic-Indutries) и др.

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

P.S. Массово можно понимать и как создание массово используемых программ (но большее их число уже существует и мало смысла повторять решения
на существующих аппаратных плаформах их с использованием Форт). Хотя, в работе на Форт оценочная производительность труда программиста в 2-3 раза выше массовых продуктов (высказана =АК= в одном из постов на данном форуме, точно сам не оценивал, но цифры близкие). МК рынок хоть и массовый, но работает на нём не так уж много специалистов и задачи у них, в своих областях, уже обычно имеют свою "отработанность". А если задача новая, то бюджет разработки может быть не ограничен.

Как то так и лично субъективно.


(P.S.)

я тоже изучал в свое время форт, было очень интересно... Но эта возня со стеком со временем просто достала.

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

Вопрос: Можно ли например эффектвно создавть компиляторы языков программирования без использования понятия стека?

Как игрушка и для разминки ума форт приколен, но для производства...

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

Сообщение отредактировал Kopa - Sep 21 2012, 12:58

[zhevak]

1. мета-язык (в т.ч. красивая обертка для ассемблера)
2. встраиваемый интерактивный скриптовой движок, который без труда ложится в любой контроллер, от младших пиков и авр до арм.
3. возможна очень плотная упаковка программы засчет использования байт-кода
4. распределенная система хост-таргет с возможностью перераспределения в ходе отладки
5. много ещё чего

1. Ичё? Продолжайте свою мысль, а то она как-то внезапно оборвалась. Клиенту, для кого создается гаджет не то что бы "красивая обертка" не нужна -- ему вообще пофигу на каком языке пишется встроенное в его гаджет ПО. Красота для программиста? ... Сомнительно. Прогеры пишут свои программы не для красоты, а чтобы устройство работало. Программисту-разработчику от этой красоты ни холодно-ни жарко. Удобство использования нужно -- это да. А красота ... это уже к гуманитариям -- художникам, поэтам, музыкантам... К "любителям программирования", которые пишут красивый код не для работы, а для личного самоудовлетворения. (Еще один из множества разновидностей онанизма?)

2. Скрипт -- это хорошо. Скрипт -- это компактно и мощно. Скрипт -- это сверхвысокоуровнево. (Вчера прочитал: "Python -- это язык сверхвысокого уровня". Вот это я понимаю!) Ляжет-то он, конечно, ляжет... но опять же -- какие задачи он нацелен? Что им решать? Приведите какие-нибудь конкретные примеры, что ли. А я (или кто-нибудь) попробуем обсудить -- возможно ли эту задачу решить с помощью каких-то иных средств так же быстро и правильно, как на Форте. Но пока, я в упор не вижу -- где можно использовать "скриптовый" язык в МК-устройствах.

Вот, смотрите -- с одной стороны мы согласны отдать 8 кило флэша под сам Форт. Хорошо. Но, что мы при этом получаем взамен?

А если мы отдаем столько же памяти под какую-нибудь RTOS -- что мы в этом случае теряем, и что получаем?

Вы ведь не хотите отдать область создания ПО для МК домохозяйкам?

И да! Скрипты! Это область, когда нужно оперативно накидать прожку, чтобы быстро разрулить большой объем работы. Скрипты хороши тогда, когда нужно время от времени подправлять их (скриптов) работу. Но мы знаем, что в 99.9% МК-устройствах программа заливается один раз. И пашет там пожизненно. Заметьте, поменять уставки (установки, параметры, конфиги) -- это не то, что поменять скриптовую прогу.

3. Очень плотная упаковка кода? Хм... Это как? Разве есть какие-то проблемы с МК, у которых не хватает памяти? Люди уже давно не пишут на асме большие проги (большие, скажем, 2-4 килоайт) ради того, чтобы сэкономить еще "один байт". Смысл ужиматься? Не хватает памяти -- возьмите другой МК.

Давно уже канули времена, когда разница в МК с разным объемом памяти была ощутима. По инерции приводят гипотетические примеры, дескать -- для производства, которое выдает на гора стони-тысячи изделий в месяц, это проблема стоит очень остро. -- Фигня! Бред! У меня такое же производство, и я по первости тоже искал себе "проблему одного байта". Сейчас понял -- надуманно это все! Стоимость МК в изделии составляет от силы несколько процентов. Какая разница, во сколько будет выливаться себестоимость изделия -- в 2345 рублей или 2389? Важно не это, а динамика развития производства. Если каждый месяц количество заказов увеличивается на 10-30%, то экономить на 1-2% за счет "узкого" проца -- только себе засерать развитие. Производите разработку -- Отлично! Закладывайте сразу проц в двукратным количеством памяти. По деньгам не чувствительно, зато будет пространства для маневра.

4. "Переведи!" (с) из советского к/ф. Это как? Ничего не понял.

5. Ни о чем! Всё будет надуманно и высосано из пальца. (Паручики, молчать!!!)


Теперь о грустном. К сожалению, я так и не понял -- зачем Форт? Или что он должен собой вытеснить (заменить)?

Да! И еще пара вопросов.

1. О манагерах. Я их тоже недолюбливаю. Но в данном вопросе с ними солидарен.

Вот, допустим, был у меня один такой уникум -- разработчик МК-системы, писал на Форте. Уволился (не важно по какой причине!) Дальше что? Разработки встали колом? Все начинать с начала и на международном языке программирования (С/С++) или учить самому/учить людей Форту. Ну и зачем мне залазить в такой "производственный капкан"?

2. Как у Форта обстоят дела с многозадачностью? Можно-ли на нем написать event-driven ПО? (Уточняю -- событийно-управляемое ПО.) Грубо -- это такое ПО, которое всё время спит, то есть не кушает батарею, не греется. Но как только в системе возникает какое-либо событие (прерывание), система пробуждается и начинает его обрабатывать. В такой системе возможны порождения вторичных событий. События в систему могут поступать по нескольким каналам.

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

А то получится как во времена DOS:

Код

do (!конец_работы())
{
  if (ответ_от_HDD_получен() == 1)
    обработать_файл();
  else if (клавиатура_нажата() == 1)
    определить_нажатую_клавишу();
  else if (событие_от_мышки() == 1)
    определить_какое_событие_случилось_у_мышки();
  else if (тайм-аут_истек() == 1)
    погасить_экран();
}

Ни в спячку систему не отправить, ни быстро отреагировать на событие.

[polyname]

Но пока, я в упор не вижу -- где можно использовать "скриптовый" язык в МК-устройствах.

значит вы с таким пока не сталкивались. Вот возьмем например устройство для автоматизации чего-то.
Пользователь пишет на MicroSD или по RS232/USB командный файлик типа:

Код

if (in(1) == 1) {out(1,0); out(2,1); sleep(100);}
else if (in(2) == 1) {out(1,1); out(2,0); sleep(200);}

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

Или "умный" звуковой модуль. Опять же на MicroSD звуковые файлы и командный текстовый файлик:

Код

if (keypress(1)) {play("sound1.wav"); sleep(100);}
else if (keypress(2)) {play("sound2.wav"); sleep(100);play("sound3.wav"); sleep(100);}

На Forth парсер/компилятор реализуется проще и короче других языков.
В принципе приблизить синтаксис к привычному несложно, например сделать вызов функций как имя( парам1 парам2 ), а при компиляции удалить скобки и переставить имя в конец списка. Можно сделать присваивание переменных как имя = знач, или set("имя" знач)

Ни в спячку систему не отправить, ни быстро отреагировать на событие.

все что требует быстродействия реализуется на С/Асм, и предоставляется Форту как библиотека стандартных функций.

Сообщение отредактировал polyname - Sep 23 2012, 12:32

[zhevak]

Спасибо за примеры, polyname.

Да, действительно, не моя темя. Я не сталкивался с проблемами, когда для полноценной работы устройства пользователю нужно предоставить какой-нибудь скриптовый язык. Видимо, речь идет о ПЛК?

все что требует быстродействия реализуется на С/Асм, и предоставляется Форту как библиотека стандартных функций.

Разумеется, не писать же на Форте стек TCP/IP для того же ENC28J60! Но рулить Фортом на верхним уровнем ... хм? <Задумался> какие-нибудь неторопливые торговые и платежные терминалы, управление вент-каналами, управление климатом в УД?

[Kopa]

Теперь о грустном. К сожалению, я так и не понял -- зачем Форт? Или что он должен собой вытеснить (заменить)?

@ "- Я не люблю кошек."
"- Вы их просто не умеете готовить"

В полемику вступать у меня нет желания. Моё предложение было озвучено в первом посте. Полемику по Форт можно прочитать
на форуме рускоязычных пользователей Форт языка и поучаствовать в ней при желании.

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

Event-driven (или автоматный подход) и другие возможности - это только модель построения системы и к языку имеет не такое
опосредованное значение (будет ли это встроено, или поддержано независимым модулем, или расширением к языку)
Форт, как расширямый язык, может адаптироваться к любым "хотелкам" программиста. Опыт создания управляемого событиемм приложение
у меня был, как со стороны контроллера на языке ассеблера иначе задача в данном железе не работала (!580 процессор на 2Мгц)
при обработке датчика метража, клавиатуры, индикатора, логики приложения и выдачи на общий канал сбора информации к PC от таких же приборов.
иначе просто программа тормозила и не работала. На уровне PC был опыт разработки управляемого событиями (с клавиатуры, мышки)
мультиоконного текстового редактора (почти микро оконная система) на Форт (на основе SPF2.5 системы в DOS и его FED редактора), где на основе первичных событий порождались синтетические и проходили по некоторой выстроеннной иеархии объектов изменяя контекст обработки для следующих событий.
(отлаживать такое приложение оказалось, довольно не простым занятием и в результате прототип так и не был доведён до полностью рабочего состояния)
был и другой опыт создания эмбеддед ПО, как с привлечением Форт, так и без него на таргете. (С, ASM)

. Скрипт -- это хорошо. Скрипт -- это компактно и мощно. Скрипт -- это сверхвысокоуровнево. (Вчера прочитал: "Python -- это язык сверхвысокого уровня". Вот это я понимаю!)

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

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

Решить задачу можно сто и одним способом а ссылки на использование Форт можно найти на Форум по форт
Нужно это или нет Вам определитесь сами.

Код

if (in(1) == 1) {out(1,0); out(2,1); sleep(100);}
else if (in(2) == 1) {out(1,1); out(2,0); sleep(200);}

Один из вариантов, можно и оптимальнее

Код

: abc
1 in 1 = if  1 0 out  2 1 out  100 sleep exit then
2 in 1 = if  1 1 out  2 0 out  200 sleep then
;

При этом ассемблер тоже выглядеть может похожим образом и мало характеризует другие другие аспекты Форт системы.
В шутку и всъерьз Форт на луркморье

Сообщение отредактировал Kopa - Sep 23 2012, 14:12

[polyname]

Один из вариантов, можно и оптимальнее

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

[Kopa]

Вы ведь не хотите отдать область создания ПО для МК домохозяйкам?

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

Вот, допустим, был у меня один такой уникум -- разработчик МК-системы, писал на Форте. Уволился (не важно по какой причине!) Дальше что? Разработки встали колом? Все начинать с начала и на международном языке программирования (С/С++) или учить самому/учить людей Форту. Ну и зачем мне залазить в такой "производственный капкан"?

Проблемы будут и С/С++ разработками т.к. уровень разработчиков, их пристастия (стиль написания кода), да и запрограммированный алгоритм без дополнительного обяснения
логики его работы могут оказаться трудно преодолимыми факторами

4. "Переведи!" (с) из советского к/ф. Это как? Ничего не понял.

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

Вот, смотрите -- с одной стороны мы согласны отдать 8 кило флэша под сам Форт. Хорошо. Но, что мы при этом получаем взамен?
А если мы отдаем столько же памяти под какую-нибудь RTOS -- что мы в этом случае теряем, и что получаем?

8кило, это, как говорится "средний показатель температуры по больнице" в классической реализации автономной Форт машины для 8-и битных контроллеров,
в близком варианте к действующим стандартам, для возможности создавать ПО в рамках Форт языка, при этом некоторая мультизадачность уже может быть встроена в этот объём. (при кросс компиляции ресурсы контроллера по памяти уже расходуются по другому). Форт сам по себе представляет "некоторую" операционную среду, с вытекающими
из этого "последствиями" (сейчас глянул ехе файл SPF4 для windows разбух уже за 100КБ, хотя если отключить оптимизатор должно получиться ~30-40КБ)

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

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

P.S. Поддержку ассемблера, также можно загрузить расширением, при необходимости.

Сообщение отредактировал Kopa - Sep 23 2012, 16:45

[zhevak]

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

Криминального-то ничего нет. Мне кажется -- это заблуждение из серии "Психбольница в руках пациентов".

Программируемый телевизор? 99% людей используют только кнопку вкл-выкл, переключатель каналов и громкость.
Умный холодильник, кофеварка? -- Дак, отлично! Напечатайте инструкцию по их программированию и добейтесь чтобы домохозяйки не посылали Вас лесом.

Базар пасанов:
-- Вчера стока бабла отвалил... Матри, какой у меня есть умный девайс!
-- Ичё!
-- Да ты вааще лох! Он программируемый!
-- ..уясе! Ну-ка -- закажи!
-- А я .уй его знает как!

Обывателям не нужна программируемость. Обывателям нужна одна кнопка -- Вкл/Выкл. И всё!

Проблемы будут и С/С++ разработками т.к. уровень разработчиков, их пристастия (стиль написания кода), да и запрограммированный алгоритм без дополнительного обяснения логики его работы могут оказаться трудно преодолимыми факторами

Проблем везде хватает. А с Фотром добавляется еще и языковая проблема -- Форт-программеров на рынке труда намного меньше, чем Си-шников.

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

А причем здесь Форт? Или я уже потерял нить рассуждения?

[Kopa]

Обывателям не нужна программируемость. Обывателям нужна одна кнопка -- Вкл/Выкл. И всё!

Про домохозяйку это была шутка.

Проблем везде хватает. А с Фотром добавляется еще и языковая проблема -- Форт-программеров на рынке труда намного меньше, чем Си-шников.

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

А причем здесь Форт? Или я уже потерял нить рассуждения?

Это было пояснение по пункту 4. MrYuran

Сообщение отредактировал Kopa - Sep 23 2012, 16:37

[zhevak]

@ "- Я не люблю кошек."
"- Вы их просто не умеете готовить"

Да, я не умею готовить кошек...
Однако: я не использую Линукс потому что его не знаю. Я не знаю Линукс потому что его не использую.
И как же выйти из этого цикла?

Извините, немного офф-топа:

... на языке ассеблера ...

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

Вы считаете. что при решении задачи первичен язык?

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

а вот этого я вообще не понял:

(мышление способно воспринять в себя и оперировать "чудовищными" построениями не замечая этого

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

Хороший язык, программирования, в моём понимании когда об нём самом и как на нём сделать то то и то то меньше всего думаешь (аналогия -
не думаем же мы как првильно дышать)

Ага. Согласен.
Мы вот тут базарим на русском и даже не испытываем дискомфорта или непонимания (пример выше -- это просто недоразумение! Не рассматриваем!)
So let's speak english and we shall got difficulties immediately.

[Kopa]

Извините, немного офф-топа:
я думал что только у меня проблема с буквой "м". Почему-то всякий раз набирая это слово я пропускаю эту букву. Вы уже второй человек, у которого та же проблема.

За своей кавиатурой замечаю некие странности (подключена через переходник PS2 - USB). так вот бывает вместо набора текста происходят нехорошие действия как то переключение на другое окно, включение режима выделения и др. Подозреваю, что в системе "существует" какая то гадость (левый процесс). Снимается предупредительным Ctr+Alt+Del без необходимости открытия диспетчера задач. Но особого дисклмфорта пока не причиняет.
В критических случаях лечится перестановкой образа системы

а вот этого я вообще не понял:

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

So let's speak english and we shall got difficulties immediately

Так что давайте говорить на английском языке, и мы получили сразу же трудности. (Переводчик от гугла)
Поэтому давайте говорить на английском языке, и мы будем, немедленно получил трудности (Переводчик от промта)
Так что давайте говорить по-английски, и мы получили трудности сразу же (Переводчик от яндекса)
Так что давайте говорить Английский, и мы будем получили трудности немедленно (Bing транслятор)

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

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

[zhevak]

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

Да! Да! Да!

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

У меня было (или где-то есть?) аж две книжки издания какого-то тысяча девятьсот мохнатого года по Форту. Одна даже в твердом переплете для БК-0010. С тех пор, на сколько я могу судить -- вообще ничего не издавалось.

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

Вот ссылка на рейтинг языков: http://www.tiobe.com/index.php/content/pap...tpci/index.html . Так, для общего развития.

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

[polyname]

Если бы в языке было что-то стоящее, то наверняка он развивался бы более динамично, имел бы множество диалектов

а чему там развиваться ? Это всяким С и Жабам нужно постоянно добавлять новые фичи, которые уже 40..50 лет есть в Лиспе и Форте...

[zhevak]

я безвылазно сижу в Лине. Так что "левые процессы" отпадают. Отсутствие "м" в "ассемблере" -- это что-то чисто человеческое.

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

А-а! Спасибо за разъяснения.
Об этом хорошо расписано в книжке Эрика Реймонда "Искусство программирования для UNIX". Дзен называется коротко K.I.S.S.

Ладно. Пойду заниматься делами. Спасибо за разговор!

[Kopa]

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

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

Вот ссылка на рейтинг языков: http://www.tiobe.com/index.php/content/pap...tpci/index.html . Так, для общего развития.

Подозреваю, что это результат вследствии решения задачи по созданию индустрии огромного оборота капитала IT области. (лично и субъективно)

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

а те кто его в промышленности его применяют, как бы и не в счёт

я безвылазно сижу в Лине. Так что "левые процессы" отпадают. Отсутствие "м" в "ассемблере" -- это что-то чисто человеческое.

Парадокс. Обычно не думаю где находятся клавиши при наборе текста.

а чему там развиваться ? Это всяким С и Жабам нужно постоянно добавлять новые фичи, которые уже 40..50 лет есть в Лиспе и Форте...

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

Ремарка: интересный факт. Разработчик языка Factor создавал свои программы сначала на Java (jEdit редактор). И ещё n-ое количество
существующих языков (цепочечного типа- Joy PostScript 5th Enchilada Cat Raven Onyx Staapl Lviv Deque и др.) построены на использовании стека, как
вычислительной структуры в своём базисе.
Не говоря уж о JVM и CLI и других исполнительны виртуальных машинах классических языков.

Сообщение отредактировал Kopa - Sep 23 2012, 18:39

[ReAl]

За своей кавиатурой замечаю некие странности (подключена через переходник PS2 - USB). так вот бывает вместо набора текста происходят нехорошие действия как то переключение на другое окно, включение режима выделения и др.

Аналогично.
Дома старая клавиатура ещё с AT-штекером через переходник из 30-летней давности магнитофонного гнезда и обрубка хвоста PS/2 мыши ткнуто в PS/2-USB.
На работе клава поновее, сама с PS/2.
И там, и там линукс.
«Всякие нехорошие действия» тоже и там, и там (на работе еще и с PS/2 трекболом).
Дома старая клава обладает такой особенностью, что после включения питания весело перемигивает всеми светодиодами.
Все «нехорошие действия» как раз тогда и бывают, когда среди быстрого набора вдруг промгнут эти светодиоды…
Похоже, придётся таки ходить и на ощупь выбирать себе новую USB-шную.

[MrYuran]

Какая разница, во сколько будет выливаться себестоимость изделия -- в 2345 рублей или 2389?

Это вы товарищу сектеру попробуйте задвинуть
Он сразу расклад накидает: миллион изделий в год, бакс с каждого в карман. Итого?

Спорить бесполезно, особенно даже не вникая в суть вопроса.
Но вот лично я при виде любой темы типа "как бы мне JVM или python или LUA встроить в контроллер" сразу вспоминаю forth.
Равно как и разговоры про лексические парсеры.

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

[rezident]

Обращаюсь к модераторам раздела публично, поскольку приватные сообщения они видимо игнорируют.
Тема данного топика изначально слабо коррелировала с тематикой раздела, а сейчас вообще попер голимый оффтопик. Перенесите, пожалуйста, топик в соответствующий раздел форума!

[Kopa]

Обращаюсь к модераторам раздела публично, поскольку приватные сообщения они видимо игнорируют.
Тема данного топика изначально слабо коррелировала с тематикой раздела, а сейчас вообще попер голимый оффтопик. Перенесите, пожалуйста, топик в соответствующий раздел форума!

Парадокс заключается в том, что не ясно где именно Найти подходящее место на форуме по Форт тематике из данного обсуждения

P.S. А чем Вас не устраивает, располжение в ветке MSP430 т.к. пока идёт "разъяснительное" обсуждение.
Примеры и описание инструментария по ссылке и не только тоже можно привести при сформированном интересе к данной тематике.

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

[rezident]

Парадокс заключается в том, что не ясно где именно Найти подходящее место на форуме по Форт тематике из данного обсуждения

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

P.S. А чем Вас не устраивает, располжение в ветке MSP430 т.к. пока идёт "разъяснительное" обсуждение.
Примеры и описание инструментария по ссылке и не только тоже можно привести при сформированном интересе к данной тематике.

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

[Виктория]

Наверно лучше перенести в "Операционные системы", впрочем мне все равно - лишь бы подписка на тему не съехала.

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

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

В Вас сидит скрытый провокатор, ещё и Kolibri OS вытянули из стека форума. Хотя идея для учебного процесса интересная.

[Kopa]

Наверно лучше перенести в "Операционные системы", впрочем мне все равно - лишь бы подписка на тему не съехала.
В Вас сидит скрытый провокатор, ещё и Kolibri OS вытянули из стека форума. Хотя идея для учебного процесса интересная.

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

P.S. Kolibri OS интересна, отчасти сформировавшейся "инфраструктурой" разработки и обсуждения направления возможного развития "операционных" сред. MSP430 - это почти "калька" c PDP-11 c которым мне посчастливилось "плодотворно" поработать и Форт, в поддержке его, многим мне помог. В колибри также были эксперименты встраивания Форт,
но идея не нашла поддержки у активных разработчиков колибри, что могло существенно облегчить написание (или прототипирование) ос.
Фoрт так или иначе используется и или может использоваться "широко" в учебном процессе. (примеры находятся при "незамыленности" восприятия или могу подсказать)

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

[MrYuran]

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

Очень простой пример.
Имея контроллер (неважно какой) с прошитым ядром forth и любой терминал через СОМ-порт, получаем абсолютный доступ ко всем потрохам контроллера прямо из терминала.
Не нужно житагов, иаров, кейлов, тулчейнов, дорогостоящих программаторов/отладчиков.
Студент ввел строку программы и тут же запустил и увидел результат.

[Виктория]

Очень простой пример.
Имея контроллер (неважно какой) с прошитым ядром forth и любой терминал через СОМ-порт, получаем абсолютный доступ ко всем потрохам контроллера прямо из терминала.
Не нужно житагов, иаров, кейлов, тулчейнов, дорогостоящих программаторов/отладчиков.
Студент ввел строку программы и тут же запустил и увидел результат.

Да ведь развлекаться будут...

Имея контроллер (неважно какой) с прошитым ядром forth и любой терминал через СОМ-порт

- Почему? Это вроде можно на любом языке. Стековая архитектура может позволит сделать просто более оптимальную трассировку?
Форт, к моему сожалению, не знаю. Нужно время, пойду разбираться

Кора, прошлась по той ссылке на форум колибристроителей, там не очень уважают встроенные системы

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

Буду признательна. Соблазнилась и купила Launchpad в прошлом году именно из-за архитектуры PDP-11. Похожая, кстати, архитектура у первых мотороловских микропроцессоров 68000 и т.д.
Дешевизна Launchpad-а, разумеется, важный фактор.

[MrYuran]

- Почему? Это вроде можно на любом языке. Стековая архитектура может позволит сделать просто более оптимальную трассировку?
Форт, к моему сожалению, не знаю. Нужно время, пойду разбираться

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

Новые введенные слова сначала компилируются в ОЗУ, можно их использовать (развлекаться , как Вы выразились), комбинировать в более мощные конструкции, а потом при желании сохранить в флеш-память с помощью слова SAVE, чтобы при следующем включении они уже были.

[Kopa]

Да ведь развлекаться будут...

И пусть, лишь бы к контроллеру были подключены реальные механизмы, датчики для эспериментов.

- Почему? Это вроде можно на любом языке. Стековая архитектура может позволит сделать просто более оптимальную трассировку?

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

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

Начните с имеющихся, хотя и отчасти и устаревших учебников.

Буду признательна. Соблазнилась и купила Launchpad в прошлом году именно из-за архитектуры PDP-11. Похожая, кстати, архитектура у первых мотороловских микропроцессоров 68000 и т.д.
Дешевизна Launchpad-а, разумеется, важный фактор.

Попробую подобрать или скомпоновать возможный вариант введения в Форт и в применениии его к контроллерам.

P.S. стартовая ссылка для "погружения" в Форт методологию, вроде была уже озвучена fforum.winglion.ru
Некторые ссылки на материалы могут уже не существовать, но из web или в личных архивах фортёров можно, наверное, найти этот материал.

Сообщение отредактировал Kopa - Sep 26 2012, 12:34

[Tanya]

- Почему? Это вроде можно на любом языке. Стековая архитектура может позволит сделать просто более оптимальную трассировку?

Компиляция идет внутри. Можно быстро пробовать.

[Kopa]

Немного ссылок на презентации Форта.

Включены слайд курс лекций по тематике Forth
The Structure of Programming Languages
Fall 2012

The Forth Language (простая)

Forth Pesentation

Сообщение отредактировал Kopa - Sep 26 2012, 19:21

[polyname]

Студент ввел строку программы и тут же запустил и увидел результат.

и к этому элементарно добавляются удаленный доступ, например запускается простейший локальный сервер (фактически ретранслятор в COM порт) и прямо из броузера можно производить любые настройки параметров, дописывать свои алгоритмы и т.д. Программы на IEC 61131 элементарно транслируются в Форт.

Сообщение отредактировал polyname - Sep 26 2012, 18:28

[Kopa]

и к этому элементарно добавляются удаленный доступ, например запускается простейший локальный сервер (фактически ретранслятор в COM порт) и прямо из броузера можно производить любые настройки параметров, дописывать свои алгоритмы и т.д. Программы из IEC 61131 элементарно транслируются на Форт.

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

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

Программы на IEC 61131 элементарно транслируются в Форт

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

Сообщение отредактировал Kopa - Sep 26 2012, 19:27

[MrYuran]

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

А ссылку не можете привести?
Тоже была такая мысль, но самому колхозить некогда

[Kopa]

А ссылку не можете привести?
Тоже была такая мысль, но самому колхозить некогда

Попробую найти или подумать в этом направлении, (возможно встречал, в сообщениях форума comp.lang.forth на слово Ladder),
а пока приведу обсуждавшуюся тему: СЛОВАРИ ФОРТА В РЕАЛИЗАЦИИ КОНЕЧНОГО АВТОМАТА
от прочтения которой, возможно, стоит "оттолкнуться" и посмотреть следующий блог
Конечные автоматы и таблицы решений на SPF

P.S. Возможно, что то было близко к этому, Plc ladder logic compiler idea
со страницы обсуждения

Код

{ DEMO LADDER LOGIC

ORIGINAL LADDER LOGIC DIAGRAM

|   X000     X001
|----| |------| |---|
|                   |
|   X004     X005   | X002
|----| |------| |---|--|/|---|
|                            |
|   X006     X007            |
|----| |------| |------------|
|                            |
|   Y000                     |  X003                      Y000
|----| |---------------------|---|/|-----------------------(
|
}
\ FORTH CODE BELOW

variable inputs
variable outputs
: -; IMMEDIATE                  \ dummy spacing, compiles nothing
: |<     ( bitnum -- bitmask )   1 SWAP SHL;
: -||-   ( flag adr -- flag )    |< inputs AND 0<> AND;
: -|/|-  ( flag adr -- flag )    |< inputs AND 0= AND;
: -(     ( flag adr -- )         SWAP IF outputs SET ELSE outputs RES THEN;
: -()-   ( flag adr -- flag )    32 + -||-;
: READ                           INA@ inputs !;
: WRITE                          outputs @ OUTA!;
ALIAS FALSE |
ALIAS TRUE |-
ALIAS : LADDER
ALIAS; END
ALIAS OR -|



\ DEMO LADDER PROGRAM
LADDER DEMO
READ
|
|- 00 -||- 01 -||- -|
|- 04 -||- 05 -||- -| 02 -[/]- -|
|- 06 -||- 07 -||- - - - - - - -|
|- 00 -()- - - - - - - - - - - -| 03 -|/|- 00 -(
WRITE
END

Отдельная реализация на С
Ladder Logic для PIC и AVR

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

[Виктория]

Немного ссылок на презентации Форта.

Спасибо. Ещё найти бы хорошую старую книжку

С релейной логикой красивый пример :-)

[MrYuran]

Спасибо. Ещё найти бы хорошую старую книжку

Ищите Лео Броуди (Leo Browdie)

Его "Thinking Forth" - отличная книга не только по теме, но и по вопросам алгоритмизации вообще.

[Kopa]

Спасибо. Ещё найти бы хорошую старую книжку

С релейной логикой красивый пример :-)

А зачем сложно искать?
Книги
из раздела Литература

Прочтение можно начать
с Начального курса программирования (Броуди) рус, Starting Forth (еngl)
Язык Форт и его реализации (Баранов,Ноздрунов)
Способ мышления - Форт (Броуди) рус, Thinking Forth (engl)
дальше по интересу.
...
и стандартов на язык
ANSI 94
Forth 83 (в изданных книгах 90-х годов)

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

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

[Виктория]

А зачем сложно искать?
Книги
...
Завести себе блокнотик (словарик) для запоминания стандартных слов по группам.

Ups, на bookFI.org нашлась брошюра общества "Знания" - в помощь лектору древняя книжка и дома в книжном шкафу "Программирование на языке Форт" Семенова Ю.А.
Спасибо всем!

[MrYuran]

Специально заказал TI Launchpad, чтобы попробовать этот 4e4th

Код

> 4E4th-se v0.34 Apr  5 2012|110001110 Warm

> 1 2 3

ok

> + + .

6  ok

> : Hello ." Hello World! ";

ok

> Hello

Hello World!  ok

>

Один косяк только омрачил этот светлый миг.
Почему-то через ихнюю TUSB3410 ни в какую не хочет работать.
Пришлось снаружи на проводках подвешивать нормальный шнурок СОМ-UART

Все-таки, красивше было бы через USB напрямую работать.

PS:
Эх я тум-тум!
Джамперы неправильно воткнул (в смысле, они уже были воткнуты)
Но они (техасцы) тоже хороши: три джампера вдоль, а два крайних поперек. Хорошо полез дорожки посмотреть и наткнулся на соответствующую шелкографию.
То есть у меня был режим SW UART, а нужен HW.
Ну все, теперь полный хэппи энд, в смысле хэппи старт.
Будем с сыном робота делать, попутно изучая азы.

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

[SyncLair]

1.Но пока, я в упор не вижу -- где можно использовать "скриптовый" язык в МК-устройствах.
Скрипты хороши тогда, когда нужно время от времени подправлять их (скриптов) работу.

2. Очень плотная упаковка кода? Хм... Это как? Разве есть какие-то проблемы с МК, у которых не хватает памяти? Люди уже давно не пишут на асме большие проги (большие, скажем, 2-4 килоайт) ради того, чтобы сэкономить еще "один байт". Смысл ужиматься? Не хватает памяти -- возьмите другой МК.


3. Как у Форта обстоят дела с многозадачностью? Можно-ли на нем написать event-driven ПО? (Уточняю -- событийно-управляемое ПО.)

1. Менее грамотные специалисты-программисты просто пишут скриптовый файл -- система их выполняет. Актуально на мой взгляд, сложно ли будет написать форт интерпретатор который кушает что-то типа DOSовских *.BAT файлов?

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

3.Вот этот вопрос меня действительно интересует! Есть в Форте механизмы параллельного исполнения?
Или единственный вариант -- упаковывать все события в системе в одну большую очередь и обрабатывать их единственным интерпретатором.


И напоследок ещё один вопрос! Есть ли где примеры того что на форте написан рельно работающий интерпретатор для embedded устройств. Интересует хотя бы такие вещи:
1.Чтение конфигурационных файлов для загрузчика -- на подобие синтаксиса GRUB или UBOOT
2.Интерпретация FTP команд embedded FTP сервером ?

[MrYuran]

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

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

1.Чтение конфигурационных файлов для загрузчика -- на подобие синтаксиса GRUB или UBOOT

сановские загрузчики целиком на форте написаны.
Open Boot, Open Firmware, OLPC boot script

[shreck]

2MrYuran

А чем закончились ваши отношения с Forpost? (если я не ошибаюсь, и это были вы)

[MrYuran]

А чем закончились ваши отношения с Forpost? (если я не ошибаюсь, и это были вы)

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

[Kopa]

1. Менее грамотные специалисты-программисты просто пишут скриптовый файл -- система их выполняет. Актуально на мой взгляд, сложно ли будет написать форт интерпретатор который кушает что-то типа DOSовских *.BAT файлов?

Сложностей нет. Можно использовать имеющиеся знания и библиотеки (например лексический анализатор). Есть популярный курс по построению
компилятора от Креншоу с кодом на Форт (начальный на Pascal). А если остановится на Форт ориентированном синаксисе, то это даже не вопрос.
"куча" материалов и ссылок на "любой вкус и цвет" представлена на русскоязычном форуме по Форт тематике http://fforum.winglion.ru.Начав изучать разные реализации можно определиться со своими "пристрастиями":) Есть и на ВАТ файле форт подобные реализации
"Менее грамотные" специалисты, что очень хорошо, имеют возможность реализовывать свои знания в программном коде! без необходимости начального углублённого
изучения "сложного" каркаса языка и возможностей создания программ с помощью него. Форт осваивается достаточно быстро. Из кирпичиков-форт слов можно
построить достаточно грандиозные "здания". Форт первый расширемый конкатенавный язык, но есть и другие его "потомки"

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

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

3.Вот этот вопрос меня действительно интересует! Есть в Форте механизмы параллельного исполнения?
Или единственный вариант -- упаковывать все события в системе в одну большую очередь и обрабатывать их единственным интерпретатором.

Сам Форт не предаставляет в стандарте парралелизм, но и никак не ограничивает расширение "себя" необходимыми возможностями. Учитывая
хорошую реентерабельность стекового кода можно создавать требуемые решения вплоть до использования в ассемблере Форта. (ассемблер тоже
часто одно из расширений Форта с зарезервированными словами CODE ... ENDCODE).Часто, в Форте используют реализацию кооперативной мультизадачности,
а если Форт выполняется в рамках заданной ОСИ то используются её сервисы (например с использованием потоков в PC версиях) Есть и проекты Форт-осей,
но "продвинутость" их неочевидна. Есть и многоядерный ассинхронный Форт контроллер (пиковая частота переключений в ядре где-то 700МГц при работе ядра,
асинхронизм 144 ядер очень сильно "рагружает" потребление )

И напоследок ещё один вопрос! Есть ли где примеры того что на форте написан рельно работающий интерпретатор для embedded устройств. Интересует хотя бы такие вещи:
1.Чтение конфигурационных файлов для загрузчика -- на подобие синтаксиса GRUB или UBOOT
2.Интерпретация FTP команд embedded FTP сервером ?

На SP-Forth реализованы eserv и nncron программы. По вашему вопросу посмотрите nncron и почитайте форум на её сайте.
На sourceforge.net есть н-ое количество Форт проектов прикладного характера.

P.S. Пожалуй пока так. Остальные пояснения по мере прояснения Форт тематики при изучении.
На MSP430 пока не работал с Фортом (нет железки), но Форт для PDP-11 процессора "юзал" интенсивно, вплоть до симуляции программно данного процессора.
поэтому и интересна данная тема. (При этом можно использовать самые недорогие контроллерные "камни")

Сообщение отредактировал Kopa - Oct 31 2012, 12:47

[Timmy]

Моё мнение по исходному вопросу: основной рыночной нишей MSP430 являются устройства с минимизированным энергопотреблением. Если оно не требуется, сейчас выгоднее и удобнее использовать ядро ARM/Кортекс. Таким образом, использование MSP430 в качестве интерпретатора Форта, что влечёт, грубо говоря, удесятерение энергопотребления, выглядит странным. А изучать периферию лучше начинать с чтения документации.

[Kopa]

Моё мнение по исходному вопросу: основной рыночной нишей MSP430 являются устройства с минимизированным энергопотреблением. Если оно не требуется, сейчас выгоднее и удобнее использовать ядро ARM/Кортекс. Таким образом, использование MSP430 в качестве интерпретатора Форта, что влечёт, грубо говоря, удесятерение энергопотребления, выглядит странным. А изучать периферию лучше начинать с чтения документации.

Десятикратно вряд ли и вряд ли фатальные, но наверное будут при использовании компактного шитогого кода.
При этом использование ассемблера в Форте по реультатам профилирования никто не запрещает использовать.

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

P.S. В НГУ на базе MSP430 проектировали проект сенсорного узла с использованием форт подхода "Метеор-Форт". Статья по результатам для ознакомления доступна.

Сообщение отредактировал Kopa - Nov 1 2012, 16:33

[MrYuran]

На MSP430 пока не работал с Фортом (нет железки)

Цена вопроса - $4.30
Доставят через несколько дней прямо в руки (мне на проходную предприятия привезли)

Уже немного поигрался

[Kopa]

Цена вопроса - $4.30
Доставят через несколько дней прямо в руки (мне на проходную предприятия привезли)

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

Уже немного поигрался

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

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

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

Сообщение отредактировал Kopa - Nov 1 2012, 18:51

[SBE]

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

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

[Kopa]

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

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

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

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

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

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

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

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

И не только.

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

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

[zhevak]

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

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

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

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

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

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

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

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

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

[Xenia]

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

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

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

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

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

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

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

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

[Kopa]

+

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

[Kopa]

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

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

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

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

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

[Xenia]

+

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

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

[Kopa]

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

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

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

[chu]

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

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

[Kopa]

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

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

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

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

[SBE]

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

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

[chu]

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

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

[Kopa]

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

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

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

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

[MrYuran]

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

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

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

[chu]

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

[Kopa]

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

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

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

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

[chu]

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

[Xenia]

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

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

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

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

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

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

[SBE]

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

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

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

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

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

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

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

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

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

[chu]

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

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

[zhevak]

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

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

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

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

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

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

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

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

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

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

[SBE]

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

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

[zhevak]

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

И вот тут я понял, точнее -- прочувствовал на себе принцип "бритвы Оккама". А я только затронул STM32 и немножечко вкусил LPC1114. У меня в голове уже начинают путаться регистры преиферийных устройств, опции компиляторов. Я уже начал забывать, что ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

[chu]

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

"

В 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

[zhevak]

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

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

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

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

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

В терминале для повышения эффективности работы, желательно иметь функционал текстового редактора.

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

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

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

P.S. Ваш пост на "изиэлектронике" очень большой, пространный, но "абсолютно" пустой. (с моей точки зрения).

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

Прочитал недавно, что на советских Агатах, в отладчик кода, Форт "внедряли" в виде sys драйвера и узнал о том, что такие компьютеры были

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

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

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

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


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

[Kopa]

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

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

[zhevak]

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

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

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

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

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

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

"Будь осторожен со своими мыслями, они - начала поступков" (с) толи лао-цзы толи конфуций - непомню, короче -
Thinking Forth

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

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

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

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

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

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

[Kopa]

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

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

Баян-не баян, суть дела не меняет.
Персональные компы начали свое наступление где-то со средины 80-х, когда стали широко доступны i8080 (и его клоны), Z80, 6502 и другие. Когда на базе 8088 начали клепать налево и направо IBM PC. Только с прорывом харда начал развиваться софт. А до того -- был какой-то зоопарк Jurassic Park.

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

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

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

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

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

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

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

[zhevak]

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

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

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

[zhevak]

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

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

Или уже произошло смещение понятий?

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

(Lnuх уже затащили в контроллеры)

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

[Kopa]

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

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

[chu]

Конкретно -- обратная польская запись повлияет на восприятие мира и приведет к извращенным понятиям.

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

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

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

Если Форта 10 раз меньше, чем С/С++, то столько же в нем и пользы.

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

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

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

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

[Kopa]

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

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

[ReAl]

Вот вы тут спорте, спорите...
Десять и пятнадцать лет назад (и десятилетнее даже нагуглилось по словам «читаю и перевожу СО СЛОВАРЁМ») я даже принимал участие в подобных разговорах. Причём с позиции «доброжелательной заинтересованности» (Баранов-Ноздрунов у меня бумажный свой, купленный в 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 уже.

[chu]

... и желательно с полными исходниками,

Ага.

[ReAl]

"В начале 1980-x на основе языка Форт Джон Уорнок и Чак Гешке из Adobe Systems создали язык PostScript[7], широко используемый для управления устройствами печати и послуживший основой для создания формата PDF.

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

[chu]

Впрочем, сейчас в режиме «поиграться» я уже и на встроенный форт согласен, платки с ATmega64 валяются как расходный материал.
Но токо чтобы оно, чёрт побери, работало «ис каропки».

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

[ReAl]

Могу поделиться. Могу собрать прошивку для Atmega64, но не сразу (по техническим причинам).

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

amforth

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

Цитата оттуда:

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

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

[Kopa]

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

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

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

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

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

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

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

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

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

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

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

[ReAl]

Вариантов полно, но всё частично зависит от ваших "хотелок" (@знания порождают многие печали)

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

[Kopa]

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

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

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

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

[chu]

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

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

Сообщение отредактировал chu - Nov 12 2012, 05:55

[Kopa]

Sorry, не удержался.

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