[xvr 12]

2 hours ago, KPG said:

Если он хорошь для микроконтроллеров, то почему нет микрконтроллеров на масс рынке и почему?

Потому что :

2 hours ago, KPG said:

Стек это аппаратура, построенная поверх регистров, и без неё можно обойтись.

Т.е. ниша для стековых МК непонятна 😞

Если только выжимать по максимму плотность кода, но это так себе цель 😞

 

[KPG 2]

On 6/18/2023 at 12:19 AM, xvr said:

Forth хорошь в микроконтролерах, но и там у него есть проблемы - он оказывается слишком сложным, как это не странно. Стек это аппаратура, построенная поверх регистров, и без неё можно обойтись.

Если приводить после этого аргумент преимущества Стековой модели организации контроллера как компактность кода, то у меня нет аргументов 🙂

1 hour ago, mantech said:

Дак он вроде и написал, потому, что сложно осваивать. Честно говоря, глянув на программирование этого 144-ядерный процессор-а, я подумал, что мне предложили изучить некий инопланетный язык программирования)))

 

т.е. без помощи АИ есть сомнения в личных способностях по возможности создания качественного софта на Forth (Форт)?

[RobFPGA 27]

On 6/17/2023 at 6:19 PM, xvr said:

Forth хорошь в микроконтролерах, но и там у него есть проблемы - он оказывается слишком сложным, как это не странно. Стек это аппаратура, построенная поверх регистров, и без неё можно обойтись.

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

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

 

[artemkad 53]

В 20.06.2023 в 17:08, mantech сказал:

Честно говоря, глянув на программирование этого 144-ядерный процессор-а, я подумал, что мне предложили изучить некий инопланетный язык программирования)))

Да ладно - вполне простые и понятные инструкции почти на уровне "Hello, world!". Вот если бы были конструкции типа 4\421341 ,  это да,  без 100 грамм никак.

В 20.06.2023 в 21:35, RobFPGA сказал:

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

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

В 20.06.2023 в 21:35, RobFPGA сказал:

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

Крайне спорно. Ели конечно пытаться все прогнать через стек данных размером с ячейку, то да, но никто так не заставляет писать. К примеру, еще с 90-х для целочисленной арифметики использовали отдельный стек(по-факту стек сопроцессора), так  почему не сделать еще стек для "широких данных"?

[xvr 12]

12 hours ago, artemkad said:

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

Зачем? Какое это даёт преимущество перед обычными языками, где 'человек пришет программу целиком'? Недостаток уже виден невооружённым глазом - Forth программы имеют тенденцию скатываться в write only формат, когда даже автор после некоторого времени не сможет понять, что он там написал. Построение языка этому способствует - ввёл команду и забыл про неё, ведь важен только результат - 'выращивается Форт-система'.

12 hours ago, artemkad said:

так  почему не сделать еще стек для "широких данных"?

Потому что их много, и работают они в параллель. Например в x86 несколько десятков исполняющих устройств и все они могут работать одновременно (пул OOO декодированных команд у него - несколько сотен). Предлагаете сделать пару десятков стеков? И поток команд распаллеливать вручную?

[artemkad 53]

36 минут назад, xvr сказал:

Какое это даёт преимущество перед обычными языками,

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

 

53 минуты назад, xvr сказал:

ввёл команду и забыл про неё,

Зачем помнить - команда попадает в словарь и все доступные команды доступны для поиска и просмотра. 

1 час назад, xvr сказал:

Например в x86 несколько десятков исполняющих устройств и все они могут работать одновременно (пул OOO декодированных команд у него - несколько сотен).

Какое отношение декодирование и конвейерная обработка процессором имеет к написанию алгоритма работы с данными? Вам не кажется что это "слегка" разные уровни? 

1 час назад, xvr сказал:

Предлагаете сделать пару десятков стеков?

А что мешает? В программе

точка1 точка2 нарисовать_линию

нет указаний через какой стек передаются координаты. Это может быть как стек данных, так и широкий стек координат. 

[xvr 12]

3 hours ago, artemkad said:

Я не говорю о преимуществах или недостатках - я говорю о том откуда это пошло и исходя из этого почему оно так странно выглядит.

Это как раз понятно. Непонятно зачем Forth нужен СЕЙЧАС? Какая у него осталась ниша применения? Похоже, что никакой не осталось 😞

Есть ли у него какие либо ценные преимущества перед обычными архитектурами? Одно приемущество есть - компактный код, за счёт отсутствия в команде полей для номеров регистров. Но это преимущество само по себе бесполезное - на мелких МК (куда можно было бы встроить Forth) RAM заканчивается раньше, чем FLASH.

Quote

Зачем помнить - команда попадает в словарь и все доступные команды доступны для поиска и просмотра. 

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

Quote

Какое отношение декодирование и конвейерная обработка процессором имеет к написанию алгоритма работы с данными?

То, что вся эта параллельность в процессоре достигается автоматически, программист никаких специальных алгоритмов для этого не пишет. И всё это работает одновременно, в отличие от классического Forth.

Quote

нет указаний через какой стек передаются координаты.

Вообще то есть. Для каждого стека свой набор слов для работы с ним. В классическом Forth стека 2 (арифметики и вызовов). К стеку вызовов есть програмный доступ с помощью слов R> и R@

Других стеков нет.

Quote

Это может быть как стек данных, так и широкий стек координат.

И как Forth будет решать, через какой стек передавать? И потом как он будет решать на каком стеке запускать следующее слово?

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

 

Вообще эта часть дискуссии бесполезна - OOO и прочее делается в высокопроизводительных системах, куда Forth не подходит (как мы это уже выяснили)

 

PS. Один открытый вопрос остаётся - где СЕЙЧАС целесообразно применять Forth? Похоже нигде 😞

[KPG 2]

Форт очень экономно расходует и ОЗУ и вполне неплохо себя чувствует и в рамках 8051 архитектуры, (встраивают и в ограниченные FPGA и не только - gameDuino gameduino 3X Daizzler ...)

но Forth это не только стековая вычислительная архитектура, а ещё комплекс заложенных в него архитектурных особенностей

определяющих его как Форт-систему.

P.S. И он ещё достаточно используется в разных ипостасях, а то что Вы не видите возможность для его использования в круге решения своих

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

К примеру около Factor языка организовалось некоорое сообщество по его использованию как и у Форт.

20-ть лет назад iosifK опубликовал цикл статей в тематике Форт.

Предлагаю Ваи, к примеру пообщаться на тему Форт и здесь https://t.me/ruforth

Изменено 22 июня, 2023 пользователем KPG

[artemkad 53]

2 часа назад, xvr сказал:

Какая у него осталась ниша применения?

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

2 часа назад, xvr сказал:

Одно приемущество есть - компактный код, за счёт отсутствия в команде полей для номеров регистров.

И снова у вас перемешено в кучу мухи и котлеты Форт и строительство стековых процессоров/контроллеров. 

3 часа назад, xvr сказал:

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

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

3 часа назад, xvr сказал:

То, что вся эта параллельность в процессоре достигается автоматически,

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

3 часа назад, xvr сказал:

И как Forth будет решать, через какой стек передавать?

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

[RobFPGA 27]

3 hours ago, artemkad said:

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

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

[artemkad 53]

55 минут назад, RobFPGA сказал:

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

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

[KPG 2]

4 hours ago, RobFPGA said:

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

В  конкатенативные языки добавляют дополнительные варианты по доступу к данным на стеке и способах с ним работы (Factor, Quakery ...)

где то как StrongForth добавляют и типизированный стек с нотацией для учёта движению параметров на нём.

P.S. Почему обречён язык Форт

Интересно, что и на куцем "стеке" из 4-ёх ячеек MK-61 (MK-161) в рамках штатных команд сделали eForth

EFORTH для программируемого калькулятора

EFORTH для МК-161: Структуры данных

 

[KPG 2]

9 hours ago, artemkad said:

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

Неужели выбора вариантов для использования Форт нет или они недостаточны для нелюбительских "поделок"?

[quark 48]

2 часа назад, KPG сказал:

Неужели выбора вариантов для использования Форт нет или они недостаточны для нелюбительских "поделок"?

По моему, на МК вариантов для Форта нет. То, что программы на этом языке выглядят непривычно - это, на самом деле, не является основной проблемой. Ко всему можно привыкнуть, при желании. Было бы ради чего...
Современные МК строятся, в основном, по гарвардской архитектуре: память программ - отдельно, память данных - отдельно. Программа хранится в относительно дешевой ПЗУ (а если ПЗУ однократно записываемая - то совсем дешевой), и ее может быть много. Текущие данные хранятся в ОЗУ, которая значительно дороже. И ее в МК немного. Она может даже отсутствовать совсем. Еще есть регистровая (сверхоперативная) память процессора, которая еще дороже и ее совсем мало. А аппаратный стек может быть всего с десяток уровней...
Концепция Форт предлагает нам экономию памяти программ - компактный код. Основной упор сделан на стек, как механизм передачи параметров. Стек должен располагаться в ОЗУ и иметь достаточный размер. Это дорого. И медленно, поскольку постоянное обращение к стеку каждой команды, резко снижает быстродействие, по сравнению с использованием регистровых команд. Если же, для ускорения работы, разработать специальный МК - стек разместить в регистровой памяти и сделать достаточно объемным, то такой МК станет слишком дорогим.
Форт предлагает нам экономить дешевую программную память и расходовать дорогое ОЗУ. И все это - в ущерб быстродействию. С концепцией МК это ни как не вяжется. Экономической целесообразности в этом нет.

[RobFPGA 27]

1 hour ago, quark said:

По моему, на МК вариантов для Форта нет. То, что программы на этом языке выглядят непривычно - это, на самом деле, не является основной проблемой. Ко всему можно привыкнуть, при желании. Было бы ради чего...

Вот вот - ради чего?
Увы, как раз эта  реальная непривычность полностью нивелирует призрачные профиты.
Ведь основное,  и IMHO самое важное для языка программирования - удобство для программиста в выражении задуманного на языке программирования . 
А  какое удобство может быть если программиста язык заставляет думать задом  наперёд  ...   

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

P.S.  Есть и другой, противоположный пример для языка программирования. Он тоже из прошлого века, интерпретируемый, с гибкой возможности расширения, и местами даже немного странный ...
Только вот разница в ~20 лет от момента создания FORT кардинально изменила  основную концепцию при разработке этого языка.
И как результат - сейчас это язык везде,  и даже  в микроконтроллерах ...   Угадаете  что это за язык?