Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Ой, зафлудили-то всю тему как true-grue писал(а): Не беспокойтесь, Kickstarter был, так сказать, для отвода глаз! Пф. А зачем она вообще тогда была? Почему она не использовалась и никто ей не занимался? Уже в первые дни было очевидно, что на компанию на кикстартере просто забыли и она явно провалится.
Ой, зафлудили-то всю тему как :) [quote="true-grue"]Не беспокойтесь, Kickstarter был, так сказать, для отвода глаз![/quote] Пф. А зачем она вообще тогда была? Почему она не использовалась и никто ей не занимался? Уже в первые дни было очевидно, что на компанию на кикстартере просто забыли и она явно провалится.
|
|
|
|
Добавлено: Вт дек 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
Небольшой привет из светлого мира *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 для этой архитектуры?". При этом как работать на Форте, эмбеддеру обычно объясняют на пальцах и прямо на ходу. Поскольку у него голова разной околопрограммистской ерундой не забита, результат обычно положительный. А по достижению работоспособного состояния можно уже и заниматься адаптацией системы под широкие массы программистов.
[quote="gudleifr"]Вы мало видели успешных и эффективных применений lex и yacc?[/quote] Видел - крайне мало. Зато слышал на всех углах. Что характерно - если таким крикунам предлагать предметный разговор о сроках и достижимых характеристиках, они сразу куда-то испаряются. Потому что играть с БНФ и написать работающий продукт - совершенно разные вещи. [quote="gudleifr"]Поймайте за пуговицу любого не-FORTH-программиста контроллеров и спросите, что для него проще: изучать чей-то FORTH-кросс-компилятор или рассматривать FORTH-процессор просто как еще один "кривой стековый".[/quote] Изучать компилятор, конечно. От рассмотрения код не появляется. Программист контроллеров - это с очень большой вероятностью инженер-электронщик, и у него в контроллере и так масса работы помимо настройки yacc. Я не встречал еще ни одного программиста встраиваемых систем, который мог бы показать свой реальный код для yacc или хотя бы знал, что такое machine description и как оно выглядит. Штамп "gcc - настраиваемый компилятор для разных процессоров" знают почти все. Практически у всех первая и единственная реакция - "где скачать toolchain для этой архитектуры?". При этом как работать на Форте, эмбеддеру обычно объясняют на пальцах и прямо на ходу. Поскольку у него голова разной околопрограммистской ерундой не забита, результат обычно положительный. А по достижению работоспособного состояния можно уже и заниматься адаптацией системы под широкие массы программистов.
|
|
|
|
Добавлено: Вт дек 30, 2014 11:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Hishnik писал(а): Ну, тогда, точно - FORTH спасен! gudleifr писал(а): Я повторяю вопрос. Где можно посмотреть на конкретный пример адаптации Си под форт-процессор, чтобы код был компактнее того, который продуцируется Фортом? Hishnik писал(а): Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата. Вы мало видели успешных и эффективных применений lex и yacc? Поймайте за пуговицу любого не-FORTH-программиста контроллеров и спросите, что для него проще: изучать чей-то FORTH-кросс-компилятор или рассматривать FORTH-процессор просто как еще один "кривой стековый".
[quote="Hishnik"] :)) [/quote] Ну, тогда, точно - FORTH спасен!
[quote="gudleifr"]Я повторяю вопрос. Где можно посмотреть на конкретный пример адаптации Си под форт-процессор, чтобы код был компактнее того, который продуцируется Фортом?[/quote] [quote="Hishnik"]Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата.[/quote] Вы мало видели успешных и эффективных применений lex и yacc? Поймайте за пуговицу любого не-FORTH-программиста контроллеров и спросите, что для него проще: изучать чей-то FORTH-кросс-компилятор или рассматривать FORTH-процессор просто как еще один "кривой стековый".
|
|
|
|
Добавлено: Пн дек 29, 2014 22:37 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
gudleifr писал(а): Вы титульный документ читали? gudleifr писал(а): Hishnik писал(а): А посмотреть можно на "под нее" и "мощнейший инструментарий"? Про nix'ы слышали? Я повторяю вопрос. Где можно посмотреть на конкретный пример адаптации Си под форт-процессор, чтобы код был компактнее того, который продуцируется Фортом? gudleifr писал(а): А мы вот на днях взяли и посчитали, прямо на Форуме. Раз так - срочно создавайте компанию по разработке компиляторов!
[quote="gudleifr"]Вы титульный документ читали?[/quote] :)) [quote="gudleifr"]Hishnik писал(а): А посмотреть можно на "под нее" и "мощнейший инструментарий"? Про nix'ы слышали?[/quote] Я повторяю вопрос. Где можно посмотреть на конкретный пример адаптации Си под форт-процессор, чтобы код был компактнее того, который продуцируется Фортом? [quote="gudleifr"]А мы вот на днях взяли и посчитали, прямо на Форуме.[/quote] Раз так - срочно создавайте компанию по разработке компиляторов! :)
|
|
|
|
Добавлено: Пн дек 29, 2014 22:17 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Hishnik писал(а): Когда пишет разработчик, он пишет на Форте... Вы титульный документ читали? Hishnik писал(а): А посмотреть можно на "под нее" и "мощнейший инструментарий"? Про nix'ы слышали? Hishnik писал(а): А я вот не умею сам себя обманывать. А мы вот на днях взяли и посчитали, прямо на Форуме.
[quote="Hishnik"]Когда пишет разработчик, он пишет на Форте...[/quote]Вы титульный документ читали? [quote="Hishnik"]А посмотреть можно на "под нее" и "мощнейший инструментарий"?[/quote]Про nix'ы слышали? [quote="Hishnik"]А я вот не умею сам себя обманывать.[/quote]А мы вот на днях взяли и посчитали, прямо на Форуме.
|
|
|
|
Добавлено: Пн дек 29, 2014 22:10 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
gudleifr писал(а): Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C. Когда пишет разработчик, он пишет на Форте, потому что отдельного ассемблера у форт-процессора нет. Для постороннего пользователя можно предоставить С, если это поможет ему освоить систему быстрее. gudleifr писал(а): Потому что он пишется именно под нее. Используя мощнейший инструментарий. А посмотреть можно на "под нее" и "мощнейший инструментарий"? А то я на слово не верю как-то... gudleifr писал(а): Проводить измерения так, чтобы получилось "что надо", мы все еще с института умеем. А я вот не умею сам себя обманывать. Это отдельный навык - упираться, оставаясь в круге известных вещей, и не обращать внимание на объективные возможности улучшения характеристик устройства. Когда я измерял, итогом стал отказ от ПЛИС объемом 1,5 млн. вентилей с переходом на 400 тыс. вентилей. Нечистоплотный сотрудник по найму, вероятно, мог бы с пеной у рта доказать, что надо оставить 1,5 млн, потому что С - это промышленный стандарт и т.п. Или Пролог туда начать ставить, потому что где Бобик - сын Шарика, там и Функция - результат Вычислений. Весело, перспективно, и есть аргументы, чтобы объяснить, почему ничего не работает
[quote="gudleifr"] Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C.[/quote] Когда пишет разработчик, он пишет на Форте, потому что отдельного ассемблера у форт-процессора нет. Для постороннего пользователя можно предоставить С, если это поможет ему освоить систему быстрее. [quote="gudleifr"]Потому что он пишется именно под нее. Используя мощнейший инструментарий.[/quote] А посмотреть можно на "под нее" и "мощнейший инструментарий"? :) А то я на слово не верю как-то...
[quote="gudleifr"]Проводить измерения так, чтобы получилось "что надо", мы все еще с института умеем.[/quote] А я вот не умею сам себя обманывать. Это отдельный навык - упираться, оставаясь в круге известных вещей, и не обращать внимание на объективные возможности улучшения характеристик устройства. Когда я измерял, итогом стал отказ от ПЛИС объемом 1,5 млн. вентилей с переходом на 400 тыс. вентилей. Нечистоплотный сотрудник по найму, вероятно, мог бы с пеной у рта доказать, что надо оставить 1,5 млн, потому что С - это промышленный стандарт и т.п. Или Пролог туда начать ставить, потому что где Бобик - сын Шарика, там и Функция - результат Вычислений. Весело, перспективно, и есть аргументы, чтобы объяснить, почему ничего не работает ;)
|
|
|
|
Добавлено: Пн дек 29, 2014 22:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Hishnik писал(а): Я не вижу смысла в использовании нестандартной терминологии. А мне лень писать каждый раз "язык машины" (А), "FORTH-подобный язык" (F) и "проблемно-ориентированный язык" (P). Эти сокращения здорово сокращают жизнь. И не дают за словесной эквилибристикой потерять смысл. Например: Hishnik писал(а): Пока что я вижу ситуацию, когда аппаратная часть по мере разработки сопровождается кросс-компилятором на базе Форта, а при фиксации архитектуры ядра появляются основания сформулировать ТЗ на Си. Т.е. А создается, имея в уме F, а о P - никаких мыслей. Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C. Hishnik писал(а): С какого перепугу он будет оптимальным для процессора с другой вычислительной моделью? Потому что он пишется именно под нее. Используя мощнейший инструментарий. Hishnik писал(а): А когда я измерял размер алгоритмов, Проводить измерения так, чтобы получилось "что надо", мы все еще с института умеем. Я, например, знаю язык, на котором компактно записывается "Бобик - сын Шарика".
[quote="Hishnik"]Я не вижу смысла в использовании нестандартной терминологии.[/quote]А мне лень писать каждый раз "язык машины" (А), "FORTH-подобный язык" (F) и "проблемно-ориентированный язык" (P). Эти сокращения здорово сокращают жизнь. И не дают за словесной эквилибристикой потерять смысл. Например: [quote="Hishnik"]Пока что я вижу ситуацию, когда аппаратная часть по мере разработки сопровождается кросс-компилятором на базе Форта, а при фиксации архитектуры ядра появляются основания сформулировать ТЗ на Си.[/quote]Т.е. А создается, имея в уме F, а о P - никаких мыслей. Т.е. F будет супер быстр и компактен, но, когда потребуется что-то написать, возьмут C. [quote="Hishnik"]С какого перепугу он будет оптимальным для процессора с другой вычислительной моделью? [/quote]Потому что он пишется именно под нее. Используя мощнейший инструментарий. [quote="Hishnik"]А когда я измерял размер алгоритмов,[/quote]Проводить измерения так, чтобы получилось "что надо", мы все еще с института умеем. Я, например, знаю язык, на котором компактно записывается "Бобик - сын Шарика".
|
|
|
|
Добавлено: Пн дек 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 раза компактнее.
[quote="gudleifr"]По уму: P - F - A. В случае "фиксации на авось" (наиболее выигрышном для FORTH): A - F - P. Совсем плохо, как Вы предлагаете: F - A - P.[/quote] Я не вижу смысла в использовании нестандартной терминологии. Пока что я вижу ситуацию, когда аппаратная часть по мере разработки сопровождается кросс-компилятором на базе Форта, а при фиксации архитектуры ядра появляются основания сформулировать ТЗ на Си. [quote="gudleifr"]На целевой - только код, оптимально скомпилированный с оптимального языка, оптимальным компилятором.[/quote] С какого перепугу он будет оптимальным для процессора с другой вычислительной моделью? Можно и сборщик мусора сгенерировать, только на какой памяти он будет этот мусор собирать? [quote="gudleifr"]И это "широкий случай"?! И даже при нем мы проигрываем: на стековых перетасовках, на избыточной фрагментации, на применении FORTH-метода...[/quote] [i]Вы[/i], может быть, и проигрываете. А когда я измерял размер алгоритмов, просто переписанные один в один, получалось в 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-метода...
[quote="Hishnik"]И если мы сначала имеем реконфигурируемую архитектуру, а в определенный момент ее фиксируем для выпуска конкретного продукта, то каким должен быть порядок создания компиляторов?[/quote]По уму: P - F - A. В случае "фиксации на авось" (наиболее выигрышном для FORTH): A - F - P. Совсем плохо, как Вы предлагаете: F - A - P. [quote="Hishnik"]А память инструментальной машины потом каким-то волшебным образом попадет в целевую? [/quote]А зачем? C работает только на инструментальной, при написании компилятора. На целевой - только код, оптимально скомпилированный с оптимального языка, оптимальным компилятором. [quote="Hishnik"]Минимизация программы 0-операндного процессора идет от меньшей разрядности команд.[/quote]И это "широкий случай"?! И даже при нем мы проигрываем: на стековых перетасовках, на избыточной фрагментации, на применении FORTH-метода...
|
|
|
|
Добавлено: Пн дек 29, 2014 21:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
gudleifr писал(а): Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно. Вот, уже ближе. И если мы сначала имеем реконфигурируемую архитектуру, а в определенный момент ее фиксируем для выпуска конкретного продукта, то каким должен быть порядок создания компиляторов? gudleifr писал(а): Оптимальный компилятор живет на инструментальной машине. Там места - завались. А память инструментальной машины потом каким-то волшебным образом попадет в целевую? Можно ведь и на Java все написать, а потом потребовать, чтобы целевая машина имела сотню-другую мегабайт и установленную JVM. gudleifr писал(а): Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты. Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата. Минимизация программы 0-операндного процессора идет от меньшей разрядности команд. Это схемотехнический параметр, а не вопрос эффективности синтаксиса. gudleifr писал(а): Ну, как бы, тогда и программист не нужен. Так он в Guardian и не особо нужен Аппаратная поддержка ряда критических протоколов обмена плюс компилятор С - и работа прикладного программиста в основном сводится к раскладыванию чисел по портам. Другой вопрос, насколько красивые эффекты он сможет реализовать, но это слабо связано с синтаксисом языка.
[quote="gudleifr"]Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно.[/quote] Вот, уже ближе. И если мы сначала имеем реконфигурируемую архитектуру, а в определенный момент ее фиксируем для выпуска конкретного продукта, то каким должен быть порядок создания компиляторов? [quote="gudleifr"]Оптимальный компилятор живет на инструментальной машине. Там места - завались.[/quote] А память инструментальной машины потом каким-то волшебным образом попадет в целевую? Можно ведь и на Java все написать, а потом потребовать, чтобы целевая машина имела сотню-другую мегабайт и установленную JVM. [quote="gudleifr"]Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты.[/quote] Чтобы видеть то, что есть, надо смотреть чуть шире первого понравившегося результата. Минимизация программы 0-операндного процессора идет от меньшей разрядности команд. Это схемотехнический параметр, а не вопрос эффективности синтаксиса. [quote="gudleifr"]Ну, как бы, тогда и программист не нужен.[/quote] Так он в Guardian и не особо нужен :) Аппаратная поддержка ряда критических протоколов обмена плюс компилятор С - и работа прикладного программиста в основном сводится к раскладыванию чисел по портам. Другой вопрос, насколько красивые эффекты он сможет реализовать, но это слабо связано с синтаксисом языка.
|
|
|
|
Добавлено: Пн дек 29, 2014 21:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Hishnik писал(а): Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta). Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно. Hishnik писал(а): То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору? Оптимальный компилятор живет на инструментальной машине. Там места - завались. Hishnik писал(а): Форт сам по себе и так делает очень много для минимизации размера программы Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты. Hishnik писал(а): Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы. Ну, как бы, тогда и программист не нужен.
[quote="Hishnik"]Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta).[/quote]Все, как раз, просто. C - возможность создавать языки с оптимальной грамматикой, но, сначала подумав. Сразу в окончательной форме. FORTH - создание языка по ходу дела, методом тыка. Постепенно.
[quote="Hishnik"]То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору?[/quote]Оптимальный компилятор живет на инструментальной машине. Там места - завались.
[quote="Hishnik"]Форт сам по себе и так делает очень много для минимизации размера программы[/quote]Это, как мы видели ранее, брехня. Вся минимизация FORTH - только от его простоты.
[quote="Hishnik"] Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.[/quote]Ну, как бы, тогда и программист не нужен.
|
|
|
|
Добавлено: Пн дек 29, 2014 14:13 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
gudleifr писал(а): Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм. Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta). gudleifr писал(а): Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения. То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору? Нет, так не пойдет, процесс оптимизации охватывает и аппаратную, и программную части. Форт сам по себе и так делает очень много для минимизации размера программы - у него нет команд вида add r1, r5, r7, и код на Форте получается компактнее, чем после Си, при прочих равных. Охват простейшим способом? Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.
[quote="gudleifr"] Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм. [/quote] Ну а зачем так сложно? Форт или Си - или, если боле абстрактно, регулярная грамматика на основе обычных форт-слов, или же БНФ (yacc/OMeta).
[quote="gudleifr"]Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения.[/quote] То есть добавить планочку-другую DDR3, чтобы было где развернуться оптимальному компилятору? Нет, так не пойдет, процесс оптимизации охватывает и аппаратную, и программную части. Форт сам по себе и так делает очень много для минимизации размера программы - у него нет команд вида add r1, r5, r7, и код на Форте получается компактнее, чем после Си, при прочих равных. Охват простейшим способом? Так ведь проще оставаться в рамках заранее проработанных подходов, а не пересоздавать языки, постоянно требуя то победить нехватку памяти, то заранее определить всю функциональность системы.
|
|
|
|
Добавлено: Пн дек 29, 2014 03:22 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
Hishnik писал(а): А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? ... В такой ситуации в чем будет заключаться оптимальность языка? В том, чтобы не нагенерировать больше памяти, чем надо... Есть задача. Она решена. Начиная от всего потребного железа и заканчивая алгоритмом. Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм. Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения.
[quote="Hishnik"]А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? ... В такой ситуации в чем будет заключаться оптимальность языка?[/quote]В том, чтобы не нагенерировать больше памяти, чем надо...
Есть задача. Она решена. Начиная от всего потребного железа и заканчивая алгоритмом. Оптимальность проблемно-ориентированного языка очевидно состоит в том, чтобы простейшим способом охватить всю вариативность, заложенную в алгоритм. Нехватка памяти должна быть побеждена раньше - на этапах жезезо- и алгоритмо-творения.
|
|
|
|
Добавлено: Пн дек 29, 2014 02:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Guardian Hardware Monitor: опыт разработки |
|
|
gudleifr писал(а): Т.е. перепрограммирование осуществляется на инструментальной машине. А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? В конструировании синтаксических оборотов можно зайти так далеко, что это будет годиться только для PC с огромным размером памяти (по сравнению с embedded). Архитектура x86 настолько въелась в практику, что воспринимается как данность, хотя это не так. Оптимизация программно-аппаратных систем начинается с аппаратуры - больше шансов получить заметный эффект. В такой ситуации в чем будет заключаться оптимальность языка?
[quote="gudleifr"]Т.е. перепрограммирование осуществляется на инструментальной машине.[/quote] А если при этом инструментальная машина нагенерирует памяти в три раза больше, чем ее есть в целевом кристалле? В конструировании синтаксических оборотов можно зайти так далеко, что это будет годиться только для PC с огромным размером памяти (по сравнению с embedded). Архитектура x86 настолько въелась в практику, что воспринимается как данность, хотя это не так. Оптимизация программно-аппаратных систем начинается с аппаратуры - больше шансов получить заметный эффект. В такой ситуации в чем будет заключаться оптимальность языка?
|
|
|
|
Добавлено: Пн дек 29, 2014 02:28 |
|
|
|
|