[MrYuran 16]

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

Руки не дошли. Как и до многого другого.

На работе надо работать работу за деньги, дома вообще к компьютеру не пробьёшься, да и некогда.

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

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

[Kopa 0]

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 процессора "юзал" интенсивно, вплоть до симуляции программно данного процессора.

поэтому и интересна данная тема. (При этом можно использовать самые недорогие контроллерные "камни")

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

[Timmy 1]

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

[Kopa 0]

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

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

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

 

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

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

 

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

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

[MrYuran 16]

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

Цена вопроса - $4.30

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

 

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

[Kopa 0]

Цена вопроса - $4.30

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

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

 

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

Спасибо. Хорошая новость и статья, и обозначен интерес к "развёртыванию" тематики в данном направлении.

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

 

P.S. Примерно с этого момента

Похожие эксперименты на Форте для AVR на робофоруме (автор Chu зарегистрирован и на местном форуме)

Форт может составить серьёную конкуренцию текущему Ардуин направлению и снять некую "элитарность" в умении программирования.

 

P.S. А комментарии в коде ( // ) специально обозначены в Си варианте? (а не \ принятому в Форт)

Ещё, вначале, можно показать использование булевой алгебры изменив систему счисления на двоичную, 2 BASE !

и как изменяются биты в ячейках (CELL) при использовании операций AND OR ХОR

т.к. целевая аудитория читателей может быть разная.

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

целевого образа программы в контроллере во флеш или ОЗУ)

Самих статей может быть очень много и получится неплохой учебник по Форт применению.

Интересно как будет изменяться ("прогрессировать") понимание возможностей применения Форт в МК и не только у "массового" читателя:)

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

[SBE 1]

Добавлю свои пять копеек, как бывший пользователь форта.

Успешно использовал его для нескольких микроконтроллерных проектов лет 15 назад.

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

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

 

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

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

[Kopa 0]

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

Сейчас, если посмотреть на определение "мелкий контроллер" критерии у производителя несколько изменились и даже используя встроенный Форт (современные

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

 

Да необычен, но востребован или невостребован это критерий относительный если посмотреть на применимость в индустрии. Вы, Я применяете в своей практике

тогда почему делать вывод, что это пригодно "только" для Вас или меня? Удачный опыт это хороший критерий дальнейшего использования. Как показывает

практика, если задачу можно решить с помощью "тощего" контроллера, то зачем "переплачивать"? Но для меня и не только - это, прежде всего, эффективное удобное

средство в деле "программинга" (есть конечно и "костыли"), а на определённое мнение кем то о неактуальности мне как бы это помягче выразиться...:)

 

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

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

 

Добавлю свои пять копеек, как бывший пользователь форта.

Успешно использовал его для нескольких микроконтроллерных проектов лет 15 назад.

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

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

 

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

И не только.

 

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

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

[zhevak 0]

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

 

Один говорит: Да вы, что, пацаны! Какие нахрен керосинки! 21 век на дворе!

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[Xenia 35]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[Kopa 0]

+

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

[Kopa 0]

...

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

Весь пост, пока нет желания комментировать

(слишком длино написано и бросающееся в глаза недостаточное владение материалом описываемого предмета (без оскорблений откуда "почерпнули" информацию?)

Одна только констатация, что стек (служит для хранения также адресов возвратов характеризует уровень знания темы (хотя на стеке

данных и могут появляться при необходимости адреса кода слов, но в Форте есть ещё стек возвратов (управления) где и "осядают" адреса возврата

и например управляющие переменные циклов) + есть ещё механизм локальных именованных переменных(если уж совсем невмоготу)

При реализации модели САLL вызовов слов они не прерывается операторами PUSH. если специально не вынесено действие PUSH при построении кода вне CALL (это модель

реализации Форта называется подпрограмный шитый код, есть и другие модели вплоть до генерации нативного кода см.например SP-FORTH)

Попутный вопрос - вы отлаживаете вручную Си код на уровне ассемблерных команд процессора?

Искривление сознания приводит к тому, что вклчается и "проcтранственое" мышление 10 BEGIN ... бла бла бла 1- ?DUP UNTIL (инкрементируется в цикле и служит

счётчиком число положенное в начале цикла 10 не куда не деваясь, как это не страшно может выглядеть)

 

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

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

лучше - таже "мозгодробилка", только вид сбоку.)

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

 

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

Вряд ли это действенный метод. Как например такой пример Qt-Forth - это засчитывается? :rolleyes:

Чаще всего интересует вопрос - а смогу ли я на данном средстве-языке-инструментарии решить 90% типовых задач не прилагая "особых" усилий? Ответ в отношении

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

 

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

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

можно, наверное, использовать для переоса Си кода в Форт вариант или иметь вариант интерактивного Си со средой выполнения и например оптимизации Форт...

Если С/С++ врос в Вас "всеми корнями", то может быть Форт и не рассматривать.

 

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

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

 

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

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

[Kopa 0]

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

...

Похвальное желание "закопать" Форт поглубже.

Есть, например, и такие экспериментальные площадки разработки http://thyrd.org

 

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

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

 

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

C описываемыми Вами перспективами по оперированию информацией можно стать "инвалидом" программерского труда, а ситуация с компиляторами

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

стековый код и "уделывал" Си регистровую оптимизацию компиляторами (по обсуждению с RSDN) до появления Pentium процессоров?)

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

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

По Вашему Java, MSIL байт код (в основе стековая модель) вообще один сплошной тормоз?

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

[Kopa 0]

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

т.е. сначала была CISC, но микропрограмма не давала "чудесным" способом уменьшить растактовку? и RISC решило эту проблему?

(вспоминая тормоза древнего 51-го ядра и быстый AVR :smile3009:, но при этом существовала MISC которая обходила, как минимум CISC архитектуру)

А вспомнив законы диалектики, что если где то прибыло, то в другом месте убыло всё встает на место т.к. и в цирке все фокусы объяснимы.

 

P.S. Всю описываему Вами цепочку выполнения кода 0-операндной машины (не вдаваясь в её корректность) можно ускорить если прочитать эти команды в группе, как

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

 

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

:) Ага передаём между функциями указатель на данные, а сами данные "чудесным" способом обрабатываются минуя регистры:)

Правильно я это понял :crying: И прочие нормальные языки больше не используют стек для передачи параметров? Может и к лучшему? Накой он это вообще стек нам сдался

 

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

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

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

являтся гарантом правильности выстраивания потока данных (может со временем только это навык приобретаетcя?)

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

[Xenia 35]

+

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

 

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