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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Вс дек 28, 2014 21:33 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Т.е. язык должен быть.

Разумеется, должен, куда же без языка-то?

gudleifr писал(а):
С здесь обошел FORTH по простой причине. Обвешанный всякими lex и yacc (эдесь META II), С является лучшим FORTH, чем сам FORTH.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Вс дек 28, 2014 21:47 
Hishnik писал(а):
Если заниматься разработкой "под ключ", а не созданием платформы для допрограммирования, то Форт на форт-процессоре часто эффективнее, чем С на форт-процессоре.
Боюсь, наоборот. Если инструментарий C не лимитируется ограничениями платформы, а задача решена до конца, то написать на нем компилятор оптимального языка проще, чем на FORTH.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Вс дек 28, 2014 22:08 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Боюсь, наоборот. Если инструментарий C не лимитируется ограничениями платформы

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Вс дек 28, 2014 22:45 
Hishnik писал(а):
Предположение о наличии С на любой платформе как раз и является определенным лимитирующим фактором.
А его и не нужно тащить на рабочую станцию. Достаточно иметь на инструментальной машине. Поэтому я указал два условия: отсутствие необходимости программирования "на месте" и требование решенности задачи. Второе, еще и потому, что "грамматические" инструменты требуют готовности грамматики до начала программирования.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 01:11 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Поэтому я указал два условия: отсутствие необходимости программирования "на месте" и требование решенности задачи.

В этом проекте как раз надо.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 01:29 
Hishnik писал(а):
В этом проекте как раз надо.

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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 02:28 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Т.е. перепрограммирование осуществляется на инструментальной машине.

А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? В конструировании синтаксических оборотов можно зайти так далеко, что это будет годиться только для PC с огромным размером памяти (по сравнению с embedded). Архитектура x86 настолько въелась в практику, что воспринимается как данность, хотя это не так. Оптимизация программно-аппаратных систем начинается с аппаратуры - больше шансов получить заметный эффект. В такой ситуации в чем будет заключаться оптимальность языка?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 02:55 
Hishnik писал(а):
А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? ... В такой ситуации в чем будет заключаться оптимальность языка?
В том, чтобы не нагенерировать больше памяти, чем надо...

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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 03:22 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм.

Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta).

gudleifr писал(а):
Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения.

То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору? Нет, так не пойдет, процесс оптимизации охватывает и аппаратную, и программную части. Форт сам по себе и так делает очень много для минимизации размера программы - у него нет команд вида add r1, r5, r7, и код на Форте получается компактнее, чем после Си, при прочих равных. Охват простейшим способом? Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 14:13 
Hishnik писал(а):
Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta).
Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно.

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

Hishnik писал(а):
Форт сам по себе и так делает очень много для минимизации размера программы
Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты.

Hishnik писал(а):
Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.
Ну, как бы, тогда и программист не нужен.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 21:05 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно.

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

А память инструментальной машины потом каким-то волшебным образом попадет в целевую? Можно ведь и на Java все написать, а потом потребовать, чтобы целевая машина имела сотню-другую мегабайт и установленную JVM.
gudleifr писал(а):
Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты.

Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата. Минимизация программы 0-операндного процессора идет от меньшей разрядности команд. Это схемотехнический параметр, а не вопрос эффективности синтаксиса.
gudleifr писал(а):
Ну, как бы, тогда и программист не нужен.

Так он в Guardian и не особо нужен :) Аппаратная поддержка ряда критических протоколов обмена плюс компилятор С - и работа прикладного программиста в основном сводится к раскладыванию чисел по портам. Другой вопрос, насколько красивые эффекты он сможет реализовать, но это слабо связано с синтаксисом языка.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 21:14 
Hishnik писал(а):
И если мы сначала имеем реконфигурируемую архитектуру, а в определенный момент ее фиксируем для выпуска конкретного продукта, то каким должен быть порядок создания компиляторов?
По уму: P - F - A. В случае "фиксации на авось" (наиболее выигрышном для FORTH): A - F - P. Совсем плохо, как Вы предлагаете: F - A - P.
Hishnik писал(а):
А память инструментальной машины потом каким-то волшебным образом попадет в целевую?
А зачем? C работает только на инструментальной, при написании компилятора. На целевой - только код, оптимально скомпилированный с оптимального языка, оптимальным компилятором.
Hishnik писал(а):
Минимизация программы 0-операндного процессора идет от меньшей разрядности команд.
И это "широкий случай"?! И даже при нем мы проигрываем: на стековых перетасовках, на избыточной фрагментации, на применении FORTH-метода...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 21:36 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
По уму: P - F - A. В случае "фиксации на авось" (наиболее выигрышном для FORTH): A - F - P. Совсем плохо, как Вы предлагаете: F - A - P.

Я не вижу смысла в использовании нестандартной терминологии. Пока что я вижу ситуацию, когда аппаратная часть по мере разработки сопровождается кросс-компилятором на базе Форта, а при фиксации архитектуры ядра появляются основания сформулировать ТЗ на Си.
gudleifr писал(а):
На целевой - только код, оптимально скомпилированный с оптимального языка, оптимальным компилятором.

С какого перепугу он будет оптимальным для процессора с другой вычислительной моделью? Можно и сборщик мусора сгенерировать, только на какой памяти он будет этот мусор собирать?
gudleifr писал(а):
И это "широкий случай"?! И даже при нем мы проигрываем: на стековых перетасовках, на избыточной фрагментации, на применении FORTH-метода...

Вы, может быть, и проигрываете. А когда я измерял размер алгоритмов, просто переписанные один в один, получалось в 2,5 - 3 раза компактнее.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 21:52 
Hishnik писал(а):
Я не вижу смысла в использовании нестандартной терминологии.
А мне лень писать каждый раз "язык машины" (А), "FORTH-подобный язык" (F) и "проблемно-ориентированный язык" (P). Эти сокращения здорово сокращают жизнь. И не дают за словесной эквилибристикой потерять смысл. Например:
Hishnik писал(а):
Пока что я вижу ситуацию, когда аппаратная часть по мере разработки сопровождается кросс-компилятором на базе Форта, а при фиксации архитектуры ядра появляются основания сформулировать ТЗ на Си.
Т.е. А создается, имея в уме F, а о P - никаких мыслей. Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C.
Hishnik писал(а):
С какого перепугу он будет оптимальным для процессора с другой вычислительной моделью?
Потому что он пишется именно под нее. Используя мощнейший инструментарий.
Hishnik писал(а):
А когда я измерял размер алгоритмов,
Проводить измерения так, чтобы получилось "что надо", мы все еще с института умеем. Я, например, знаю язык, на котором компактно записывается "Бобик - сын Шарика".


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Guardian Hardware Monitor: опыт разработки
СообщениеДобавлено: Пн дек 29, 2014 22:05 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C.

Когда пишет разработчик, он пишет на Форте, потому что отдельного ассемблера у форт-процессора нет. Для постороннего пользователя можно предоставить С, если это поможет ему освоить систему быстрее.
gudleifr писал(а):
Потому что он пишется именно под нее. Используя мощнейший инструментарий.

А посмотреть можно на "под нее" и "мощнейший инструментарий"? :) А то я на слово не верю как-то...

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

А я вот не умею сам себя обманывать. Это отдельный навык - упираться, оставаясь в круге известных вещей, и не обращать внимание на объективные возможности улучшения характеристик устройства. Когда я измерял, итогом стал отказ от ПЛИС объемом 1,5 млн. вентилей с переходом на 400 тыс. вентилей. Нечистоплотный сотрудник по найму, вероятно, мог бы с пеной у рта доказать, что надо оставить 1,5 млн, потому что С - это промышленный стандарт и т.п. Или Пролог туда начать ставить, потому что где Бобик - сын Шарика, там и Функция - результат Вычислений. Весело, перспективно, и есть аргументы, чтобы объяснить, почему ничего не работает ;)


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

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


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

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


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

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