[ReAl 0]

Вот вы тут спорте, спорите...

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

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

Ага.

[ReAl 0]

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

Угумс, на postscript даже как-то написал короткую программку.

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

 

[chu 0]

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

Но токо чтобы оно, чёрт побери, работало «ис каропки».

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

amforth http://amforth.sourceforge.net/ прекрасно подходит для "поиграться" http://roboforum.ru/forum58/topic4406-60.html

[ReAl 0]

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

Вот и ответ на причины малой распространённсоти форта :-) Эт вам не аврстудия+вінавр или там кодевижн.

У меня-то atmega32 в неликвидах несколько штук лежит, а вот платки с ней нет. В платах есть mega64, mega128, mega2560.

 

amforth

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

 

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

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

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

«Или нет?»™

[Kopa 0]

Впрочем, сейчас в режиме «поиграться» я уже и на встроенный форт согласен, платки с 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

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

[ReAl 0]

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

Да вот именно что «хотелка». Когда-то не смог поиграться, сейчас что-то шевельнулось.

Хотя С в руке сидит хорошо и С++ потихоньку затягивает. Шаблоны штука хорошая при аккуратном применении.

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

 

 

[Kopa 0]

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

Что можно пожелать? От трудностей никто не застрахован, а будет ценным или бесценным опыт кто может знать?

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

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

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

 

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

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

[chu 0]

:bb-offtopic: http://oko-planet.su/finances/financesday/...nih-lyudey.html

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

Сразу вспомнился фильма BraZil

 

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

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

[Kopa 0]

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

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

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

но это уже "заморочки" будущих поколений:)

 

[chu 0]

но это уже "заморочки" будущих поколений:)

Угу - Министерство Информации и Корпорация "Централизованные услуги"

[ReAl 0]

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

Я тоже списал половину этого воскресного дня в убытки "полностью выходной день".

[MrYuran 29]

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

Если хотя бы одним глазком заглянете в описание 4e4th, то увидите, что он новые слова сразу кладет в флеш-память. Ещё интереснее переменные. Адрес кладется в флеш-словарь, а место в виде одной ячейки резервируется в ОЗУ.

 

Чтобы вновь введенные слова "запомнились" насовсем, есть специальное слово SAVE, которое прописывает ссылку на новый словарь в инфо-флеши.

 

Я между тем полез внутрь :)

[SBE 1]

Как много понаписали, может тема того не стоит. Придется и мне :rolleyes:

 

Я столкнулся с фортом в середине 90-х. Заполучили от партнеров в штатах неплохую форт-систему с исходниками для мотороловских 8 битников. Для того времени очень приличное решение, с учетом однократной или ультрафиолетовой ROM в микроконтроллерах, отсутствия аппаратных отладчиков, производительности тогдашних ПК, и уровня компиляторов и сред разработок под С и подобное. На ней успешно написали все ПО контроллеров для нескольких разных приборов. Измерения, сбор данных, математика (вот это тяжело пишется на Forth), пользовательский интерфейс, обмен с ПК и т.п. Поэтому немного представляю особенности, достоинства и недостатки форта и отладки систем на нем применительно к микроконтроллерам для реальных проектов.

 

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

 

Я немного смотрел как развивается Forth за прошедшие годы. В целом по моему это «игры разума», и особого продвижения нет (я работал с системой 89 года выпуска, и она была даже поприличней многих нынешних), да и не будет.

 

Я не вижу большого смысла в применении Forth в чистом виде для микроконтроллеров класса MSP430 при наличии для них приличных С/С++ компиляторов и внутрисхемной отладки. Не видно выигрыша в скорости разработки и объеме результирующего кода. А проигрыш для меня очевиден в быстродействии, надежности и поддержке. И может это субъективно, но также огромный проигрыш в удобстве написания и отладке.

 

Многие аргументы, которые мелькают в статьях по Forth, выглядят для меня несерьезными.

«Маленький объем кода» - для МК нужно понаписать под три десятка килобайт, чтобы получить выигрыш над С, это очень приличный проект по размеру, и по моему опыту на С/С++ это сделать приятнее и быстрее. Можно ужимать интерпретатор, выбрасывая поля имени и «лишние» слова (приходилось это делать), но во многом теряется прелесть интерпретатора и отладки.

«Не нужно компилировать и прошивать» - приходится кросс-компилировать и прошивать, хотя бы потому что, для больших проектов это зачастую просто много быстрее и удобнее, чем скармливать по последовательному каналу текст Forth компилятору на неторопливом микроконтроллере.

Кстати, 4E4th кросс-компилировать с Форта не умеет, что вполне ожидаемо от простенькой системы на ассемблере, тут препроцессор нужен. Для учебных целей, для которых он позиционируется, и так, конечно, сойдет.

 

Сам язык, конечно, гибкий и позволяет многое. Но на моей практике при реальных ограничениях быстродействия и объема для моих микроконтроллерных задач как-то эта гибкость использовалась слабо. Зато ужас было писать на форте математику или обработку массивов и структур. И разбирать написанное тоже непросто.

 

Тема наличия встроенного интерпретатора-компилятора для меня отдельная, и здесь идеи Forth полезны и интересны.

Для ARM слышал об решениях с Lua, это мне кажется правильным и перспективным, объем памяти под это пока выглядит великоватым, но это пройдет.

 

Идеология форта красива сама по себе, осваивать его интересно, и возможно этим объясняется его некую популярность, в том числе и в учебных целях. Время, потраченное на Forth, не будет потерянным, но я бы не рассчитывал на него как практический инструмент серьезной работы в embedded.

 

[Kopa 0]

Cам язык, конечно, гибкий и позволяет многое. Но на моей практике при реальных ограничениях быстродействия и объема для моих микроконтроллерных задач как-то эта гибкость использовалась слабо. Зато ужас было писать на форте математику или обработку массивов и структур. И разбирать написанное тоже непросто.

А сам язык не расширяли надстройкой, например, для записи формул в обычном виде и необходимым "дизайном привычного вида"

Многие алгоритмы, Форт реализаций функций, уже собраны в проектах Форт библиотек Forth Foundation Library (FFL) The Forth Scientific Library Project Если посмотреть в i-Forth там очень много математики реализовано на Форт без "классического" синтаксиса, (может

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

 

P.S. Разбирать математику может оказаться действительно сложно без применения дополнительного инструментария. Но и в переложении

на С уровень реализации, без знания предмета, тоже не такое простое (если же возможно) действие. У математики свой язык оперирования

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

 

Для ARM слышал об решениях с Lua, это мне кажется правильным и перспективным, объем памяти под это пока выглядит великоватым, но это пройдет.

На Фoрте есть реализованные парсеры BNF с Форт поддержкой среды выполнения и другие "незатейливые" варианты разного парсинга. Может они могут уменьшить требуемый объём при применении для большой группы "классических" скриптовых языков?

 

«Маленький объем кода» - для МК нужно понаписать под три десятка килобайт, чтобы получить выигрыш над С, это очень приличный проект по размеру, и по моему опыту на С/С++ это сделать приятнее и быстрее.

Три десятка килобайт - это "очень" много для Форт применением. (лнейкой конечно не мерил). В реализации Си с использованием Форт схемы,

думаю раница окажется не такая существенная.

 

 

Можно ужимать интерпретатор, выбрасывая поля имени и «лишние» слова (приходилось это делать), но во многом теряется прелесть интерпретатора и отладки.

Неплохой результатдля ужимания текста в именах слов даёт Radiх кодировка. (вроде 5-ть бит на символ)

 

«Не нужно компилировать и прошивать» - приходится кросс-компилировать и прошивать, хотя бы потому что, для больших проектов это зачастую просто много быстрее и удобнее, чем скармливать по последовательному каналу текст Forth компилятору на неторопливом микроконтроллере.

Есть и такие варианты, поэтому это не контраргумент.

 

 

Я не вижу большого смысла в применении Forth в чистом виде для микроконтроллеров класса MSP430 при наличии для них приличных С/С++ компиляторов и внутрисхемной отладки. Не видно выигрыша в скорости разработки и объеме результирующего кода. А проигрыш для меня очевиден в быстродействии, надежности и поддержке. И может это субъективно, но также огромный проигрыш в удобстве написания и отладке.

Может действительно приведённые вами параметры субъективны и не настолько очевидны для пользователей Форт, например, при выработке определённых методологий при создании кода? Иначе, как объяснить широкое использование Форт в NASA разработках?

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

бы выиграли в дизайне с аппаратной поддержкой двух стеков и 0-операндных команд (как бы они с ними поступали это уже на их усмотрение)

В FPGA реализации стекового процессора microcore введён режим и интерпритации шитого кода к тому же.

 

Я немного смотрел как развивается Forth за прошедшие годы. В целом по моему это «игры разума», и особого продвижения нет (я работал с системой 89 года выпуска, и она была даже поприличней многих нынешних), да и не будет.

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

 

Так в чём пародокс "существования" Форта? На протяжении стольких десятилетий? Тупиковые идеи обычно не находят свою электоральную группу.

(или может @"Кесарю кесарево, а слесарю слесарево")

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