Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт янв 28, 2021 16:15

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 4 ] 
Автор Сообщение
 Заголовок сообщения: Форт - телега впереди лошади?
СообщениеДобавлено: Пт дек 18, 2020 03:11 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7123
Благодарил (а): 17 раз.
Поблагодарили: 119 раз.
Почему такое название темы? Потому что неудачные попытки применения Форта часто объясняются именно этим - перемещением телеги вперед лошади, в результате чего движение благополучно прекращается.

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

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

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

Вывод - до применения Форта необходимо проработать те части проекта, которые не зависят от используемого языка. Если же разрабатывается новый Форт, для него должны быть определены сценарии использования (из той же серии - use cases, набор модельных задач и т.п.). Тогда шаги по реализации будут проверяемыми на конкретных примерах, а разработка перестанет быть хаотичной.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Форт - телега впереди лошади?
СообщениеДобавлено: Чт дек 24, 2020 19:32 
Не в сети

Зарегистрирован: Пн янв 07, 2013 22:40
Сообщения: 1341
Благодарил (а): 3 раз.
Поблагодарили: 48 раз.
Ссылка на новую статью с Хабр (специально для Хищник или чтoбы был материал для размышлений :)
Проблемы методологии проектирования микропроцессорных систем

P.S. Чем может помочь Форт в сонме описанных задач/проблем?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Форт - телега впереди лошади?
СообщениеДобавлено: Пт дек 25, 2020 01:29 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7123
Благодарил (а): 17 раз.
Поблагодарили: 119 раз.
Да известная вещь, в принципе. Понятно, что не всем, но тем, кто занимается - известна. Например, если посмотреть соседнюю тему, с поздравлением нового к.т.н., то там элемент вот такой, уже реализованной методологии, как раз и имел место, именно со стороны инструментального обеспечения высокоуровневого моделирования.

По названиям-фамилиям тоже понятно. По сути, это описание и упоминание того, как "хотели делать, но не получилось".

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Форт - телега впереди лошади?
СообщениеДобавлено: Сб дек 26, 2020 04:14 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7123
Благодарил (а): 17 раз.
Поблагодарили: 119 раз.
Цитата:
Применяемая, в настоящее время, для проектирования СБИС, методология с использованием языков описания аппаратуры, обладает общепризнанными недостатками, а именно:

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


Ну в целом да. Только последние два пункта еще и взаимосвязаны. Изменяя что-то в схеме, разработчики так или иначе изменяют и характеристики СБИС как таковой. Иногда существенно, причем основная причина - неполное понимание особенностей топологических библиотек. Добавить инвертор - ерунда. Сказать "а давайте это будет еще и DSP, поэтому ставим умножение с накоплением" - это огромный по меркам кристалла модуль с приличной задержкой и сложной трассировкой. Энергоэффективность вообще отдельная тема - в ПЛИС компоненты уже выбраны и имеют конкретные характеристики, а при проектировании СБИС один и тот же компонент можно реализовать в вариантах, отличающихся по энергетике и быстродействию на порядок.

Цитата:
Разработка СБИС становится частью инструментария разработчика программного обеспечения.

Каждая компания разработчик ПО, получает возможность разрабатывать СБИС.

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

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

Цитата:
Поднять уровень абстракции при разработке аппаратуры:

a. Использовать языки более высокого уровня, например, C ++ вместо Verilog;

Ну да, или DSL.

Цитата:
Использовать инструменты высокоуровневого синтеза;


HLS, с вариантами C++/SystemC. Проблема в п.2 - реализация "расползается", чрезмерно абстрагированное описание дает возможность посмотреть на результаты выполнения операций, но детали различаются очень существенно. Разработка на HLS - это масса директив (#pragma) и постоянная игра с ними.

Цитата:
Применение методологии AGILE в разработке СБИС:


Ну это уже свое любимое человек вставил. Зависит от множества факторов. Особенно я бы посмотрел на непрерывную интеграцию - оно вполне может выглядеть как-то так: https://xkcd.ru/303/
Зачем вообще абстрагирование? Да как раз затем, чтобы выполнять больше итераций проектирования, не вдаваясь в несущественные на данном этапе детали (например, где конкретно на кристалле расположен сумматор в операции A + B и в каком слое металлизации проведены шины для подачи операндов).

Цитата:
И модульный подход к физическому проектированию СБИС основанный на мелкозернистом глобально асинхронном и локально синхронном (GALS) тактировании.


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

Цитата:
При этом признаётся, что для достижения поставленных, программой IDEA, целей потребуется прорыв в алгоритмах машинного обучения и оптимизации.


Еще бы! Уж делали бы на базе оптимизированных компонентов, пусть с локальными оптимизациями. Но глобально - это даже не выиграть у человека в го. В го доска 19x19, и то не так давно компьютер выиграл у профессионала, а СБИС побольше будет.

Цитата:
обеспечивающих доверие к строительным блокам (IP блокам) аппаратного обеспечения с открытым исходным кодом.


Доверие и открытый код - разные вещи. Open - это не волшебное слово, гарантирующее чуть ли не подключение Мирового Разума к разработке. Собственно, opencores.org - в основном собрание негодных на практике, непроверенных и амбициозно "продвигаемых" проектов и проектиков. Огромные простыни кода никак не помогут осознать заложенную концепцию, архитектуру и проверить реализацию в строгом математическом смысле. Открытость тут видится как просьба "вы там нам дайте уж побольше всего, а то мы не справляемся".

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

Фантазии. Интеграция IP-блока в СБИС подтверждается физическим моделированием СБИС. Только так можно проверить системные эффекты (например, банальные наводки, локальный перегрев или проседание напряжения на сетке питания - мало ли по каким причинам). Если запуск пластины стоит очень дорого, то "размазанная" по безликому миру open source ответственность ничего хорошего не даст.

Цитата:
При этом не ожидается полное устранение ошибок: «Качество платформы моделирования по своей природе ограничено качеством используемых моделей системы и векторов испытаний, и вполне вероятно, что ряд критических ошибок будет пропущен».

Естественно!

Цитата:
Практика показала, что их текстовое описание не лучший способ представления, потому, в настоящее время, используются схемы алгоритмов, в частности визуальный язык ДРАКОН


:)) :)) :)) :)) :))

Цитата:
В рамках проекта суперкомпьютера «Ангара», под руководством Эйсымонта Л.К., автор участвовал в разработке микропроцессора с массовым параллелизмом, где применялся метод схемного проектирования. Разработка микроархитектуры выполнялась одним человеком, обладавшим большим опытом схемотехнического проектирования. Применение схемного проектирования показало существенно меньшее количество ошибок, допускаемых человеком, при разработке микроархитектуры и схемотехнической реализации функций блоков. При этом, описание уже готовых схем, на языке Verilog, приводило к появлению ошибок, отсутствовавших в схемном описании.

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

Цитата:
В дальнейшем, на основе когнитивно-эргономического подхода, был создан графический язык ДРАКОН. Применение его для создание различных ракетно-космических систем доказало эффективность идей, положенных в его основу

Вариант вредного для практической деятельности затуманивания мозгов читателям. Прежде всего - НИЧЕГО оно не "доказало". Оно просто показало, что конкретно в том проекте работали люди, персонально заинтересованные в таком подходе. Разве была какая-то конкуренция? Да нет, просто проекты такого уровня имеют массу ограничений, прежде всего организационно-бюрократических. Просто так нельзя даже ознакомиться с ходом работ, а уж предложить собственную реализацию - и подавно. Поэтому в космических технологиях (ну и в ядерных тоже, в силу специфики доступа туда) можно встретить результаты, объясняемые тем, что люди порезвились в свое удовольствие, потому что кроме них к проекту никто не был допущен. Что хотят доказать сторонники Дракона? Что для реализации проекта уровня космического корабля нужно освоить Дракон? Да нет, для такого проекта нужно иметь финансирование, коллектив и производственную базу... тогда даже вкрапления личных хобби-проектов ничего сильно не испортят :D


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 4 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB