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

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Guardian Hardware Monitor: опыт разработки
Автор Сообщение
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
Ой, зафлудили-то всю тему как :)
true-grue писал(а):
Не беспокойтесь, Kickstarter был, так сказать, для отвода глаз!

Пф. А зачем она вообще тогда была? Почему она не использовалась и никто ей не занимался? Уже в первые дни было очевидно, что на компанию на кикстартере просто забыли и она явно провалится.
Сообщение Добавлено: Вт дек 30, 2014 19:04
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
Небольшой привет из светлого мира *nix. Штатный hello world для Microblaze. Проект занимается только выводом Hello world в консоль.

arm-xilinx-eabi-size helloc.elf |tee "helloc.elf.size"
text data bss dec hex filename
22940 1096 29780 53816 d238 helloc.elf

arm-xilinx-eabi-size hellocpp.elf |tee "hellocpp.elf.size"
text data bss dec hex filename
19524 1096 29788 50408 c4e8 hellocpp.elf
Сообщение Добавлено: Вт дек 30, 2014 18:19
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
gudleifr писал(а):
Вы мало видели успешных и эффективных применений lex и yacc?

Видел - крайне мало. Зато слышал на всех углах. Что характерно - если таким крикунам предлагать предметный разговор о сроках и достижимых характеристиках, они сразу куда-то испаряются. Потому что играть с БНФ и написать работающий продукт - совершенно разные вещи.
gudleifr писал(а):
Поймайте за пуговицу любого не-FORTH-программиста контроллеров и спросите, что для него проще: изучать чей-то FORTH-кросс-компилятор или рассматривать FORTH-процессор просто как еще один "кривой стековый".

Изучать компилятор, конечно. От рассмотрения код не появляется. Программист контроллеров - это с очень большой вероятностью инженер-электронщик, и у него в контроллере и так масса работы помимо настройки yacc. Я не встречал еще ни одного программиста встраиваемых систем, который мог бы показать свой реальный код для yacc или хотя бы знал, что такое machine description и как оно выглядит. Штамп "gcc - настраиваемый компилятор для разных процессоров" знают почти все. Практически у всех первая и единственная реакция - "где скачать toolchain для этой архитектуры?". При этом как работать на Форте, эмбеддеру обычно объясняют на пальцах и прямо на ходу. Поскольку у него голова разной околопрограммистской ерундой не забита, результат обычно положительный. А по достижению работоспособного состояния можно уже и заниматься адаптацией системы под широкие массы программистов.
Сообщение Добавлено: Вт дек 30, 2014 11:00
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
Hishnik писал(а):
:))

Ну, тогда, точно - FORTH спасен!

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

Hishnik писал(а):
Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата.

Вы мало видели успешных и эффективных применений lex и yacc?
Поймайте за пуговицу любого не-FORTH-программиста контроллеров и спросите, что для него проще: изучать чей-то FORTH-кросс-компилятор или рассматривать FORTH-процессор просто как еще один "кривой стековый".
Сообщение Добавлено: Пн дек 29, 2014 22:37
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
gudleifr писал(а):
Вы титульный документ читали?

:))
gudleifr писал(а):
Hishnik писал(а):
А посмотреть можно на "под нее" и "мощнейший инструментарий"?
Про nix'ы слышали?

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

Раз так - срочно создавайте компанию по разработке компиляторов! :)
Сообщение Добавлено: Пн дек 29, 2014 22:17
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
Hishnik писал(а):
Когда пишет разработчик, он пишет на Форте...
Вы титульный документ читали?
Hishnik писал(а):
А посмотреть можно на "под нее" и "мощнейший инструментарий"?
Про nix'ы слышали?
Hishnik писал(а):
А я вот не умею сам себя обманывать.
А мы вот на днях взяли и посчитали, прямо на Форуме.
Сообщение Добавлено: Пн дек 29, 2014 22:10
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
gudleifr писал(а):
Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C.

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

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

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

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

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

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

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

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

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

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

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

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

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

Hishnik писал(а):
Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.
Ну, как бы, тогда и программист не нужен.
Сообщение Добавлено: Пн дек 29, 2014 14:13
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
gudleifr писал(а):
Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм.

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

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

То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору? Нет, так не пойдет, процесс оптимизации охватывает и аппаратную, и программную части. Форт сам по себе и так делает очень много для минимизации размера программы - у него нет команд вида add r1, r5, r7, и код на Форте получается компактнее, чем после Си, при прочих равных. Охват простейшим способом? Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.
Сообщение Добавлено: Пн дек 29, 2014 03:22
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
Hishnik писал(а):
А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? ... В такой ситуации в чем будет заключаться оптимальность языка?
В том, чтобы не нагенерировать больше памяти, чем надо...

Есть задача. Она решена. Начиная от всего потребного железа и заканчивая алгоритмом. Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм. Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения.
Сообщение Добавлено: Пн дек 29, 2014 02:55
  Заголовок сообщения:  Re: Guardian Hardware Monitor: опыт разработки  Ответить с цитатой
gudleifr писал(а):
Т.е. перепрограммирование осуществляется на инструментальной машине.

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

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


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