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

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

Обзор темы - О естественности FORTH-решений
Автор Сообщение
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
_KROL писал(а):
всякие разные цитаты


Да вот Gudliefr'а нет и волю почувствовали :D
Сообщение Добавлено: Ср мар 14, 2018 11:26
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
KPG писал(а):
_KROL писал(а):
Я что-то вас не понимаю. А что, в Лисп это нельзя сделать? Предположим, что чуть доработанный Лисп тоже может экспортировать программу в шитый код, и что тогда?

P.s. Не думал, что такие завихрения начнуться после удаления Gudliefr с форума 8)

Можно и на Лисп, кто же против?
Вопрос лишь в том, сколько от Лисп системы будет необходимо в контроллере по ресурсам для принятого решения , если внимательно прочитали на что был дан пример. :)


P.S. К завихрениям, это точно не относится. Как выяснили, вопрос лишь в личных предпочтениях
т.к. другой аргументации не последовало.
Например Zillion games программируются на Лисп, но также имеется возможность их программировать на Axiom (Форт интерфейсе)
Я бы добавил (относительно недавно обнаружил для себя), что и в Audacity встроен lisp, на котором написаны все (почти?) эффекты.
Но я уж точно не могу понять, почему это в этой теме?
Цитата:
О естественности FORTH-решений
Сообщение Добавлено: Ср мар 14, 2018 11:04
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
_KROL писал(а):
Я что-то вас не понимаю. А что, в Лисп это нельзя сделать? Предположим, что чуть доработанный Лисп тоже может экспортировать программу в шитый код, и что тогда?

А какой смысл перебирать все языки и проверять, нельзя ли на них сделать?
Сообщение Добавлено: Ср мар 14, 2018 01:38
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
true-grue писал(а):
Среди примеров применения описанного подхода можно отметить Java-апплеты в смарт-картах и виртуальные машины для распределенных сетей сенсорных устройств.

Это уже было, но можно ещё раз в этой теме привести ссылку :)
Д.В.Рогозин Экономичный интерпритатор для узлов сенсорной сети
Сообщение Добавлено: Ср мар 14, 2018 01:06
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
KPG писал(а):
Но это не повод занимать ОЗУ недосборщиками всякого мусора.
Поэтому я и пишу, что реализация всяких недосистем, в большинстве случаев просто не имеет смысла.
Сообщение Добавлено: Вт мар 13, 2018 23:57
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
loztcatz писал(а):
И все таки я не вижу оправданий насиловать микроконтроллер с ограниченными ресурсами (2к озу) (недо)форт-системой, ведь там и так места мало (небось 8к флеш).

Сейчас у меня в наличии две отладочные платы на STM32L100 и STM32L476 на них да существенно больше ОЗУ
но на плате с STM8L уже не уверен. Флэша достаточно на них для использования режима самопрограммирования.

P.S. Но это не повод занимать ОЗУ недосборщиками всякого мусора. :)
Сообщение Добавлено: Вт мар 13, 2018 23:50
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
И все таки я не вижу оправданий насиловать микроконтроллер с ограниченными ресурсами (2к озу) (недо)форт-системой, ведь там и так места мало (небось 8к флеш).
Сообщение Добавлено: Вт мар 13, 2018 23:35
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
_KROL писал(а):
Я что-то вас не понимаю. А что, в Лисп это нельзя сделать? Предположим, что чуть доработанный Лисп тоже может экспортировать программу в шитый код, и что тогда?

P.s. Не думал, что такие завихрения начнуться после удаления Gudliefr с форума 8)

Можно и на Лисп, кто же против?
Вопрос лишь в том, сколько от Лисп системы будет необходимо в контроллере по ресурсам для принятого решения , если внимательно прочитали на что был дан пример. :)


P.S. К завихрениям, это точно не относится. Как выяснили, вопрос лишь в личных предпочтениях
т.к. другой аргументации не последовало.
Например Zillion games программируются на Лисп, но также имеется возможность их программировать на Axiom (Форт интерфейсе)
Сообщение Добавлено: Вт мар 13, 2018 21:08
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
KPG писал(а):
loztcatz писал(а):
А зачем вообще нужна реализация всей экосистемы языка (лиспа, форта, и др.) в МК? Разве что только для поднятия ЧСВ :) Главное ведь чтобы диодик мигал, верно :)

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

P.S Помнится, кто то в рамках Форт системы на компьтере моделировал решение технологической задачи, а потом это решение уже запускалось и доводилось на месте в контроллере на производстве.
Я что-то вас не понимаю. А что, в Лисп это нельзя сделать? Предположим, что чуть доработанный Лисп тоже может экспортировать программу в шитый код, и что тогда?

P.s. Не думал, что такие завихрения начнуться после удаления Gudliefr с форума 8)
Сообщение Добавлено: Вт мар 13, 2018 20:12
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
Сложность аппаратуры и ПО современной встраиваемой системы зависит, разумеется, от задач, которые на нее возложены. Где-то уместно использование решения на базе быстродействующей системы на кристалле с ОЗУ, размер которого исчисляется в гигабайтах, а также с ОС уровня Linux.

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

Возвратимся, однако, ко дню сегодняшнему. Заметна тенденция усложнения ПО в области даже ограниченных по ресурсам систем. От такого рода ПО теперь требуется большая гибкость, реализация более сложных алгоритмов (в том числе из области ИИ: синтез и распознавание речи, компьютерное зрение, использование нечеткой логики и так далее). При этом с точки зрения аппаратуры речь часто идет о микроконтроллерах или софт-процессорах с небольшим (2-8 Кбайт) объемом памяти данных и команд.

Перспективным ответом разработчика на современные вызовы является организация ПО встраиваемой системы в виде машинно-ориентированной базовой части и байткода некоторой виртуальной машины. Такой подход давно зарекомендовал себя в области серверных и персональных компьютеров. Какие же плюсы можно ожидать от его использования во встраиваемом ПО?

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

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

Таким образом, в рамках разрабатываемого встраиваемого ПО может быть полезно иметь как интерпретатор байткода, так и интерпретатор текстовых команд. Легко заметить, что эти механизмы в интегрированном виде уже содержатся в языках-интерпретаторах, таких, например, как Lisp, Forth или Tcl. Поэтому естественным образом возникает необходимость выбора существующей или создания собственной подобной языковой системы с учетом решаемых задач.
Сообщение Добавлено: Вт мар 13, 2018 18:29
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
loztcatz писал(а):
А зачем вообще нужна реализация всей экосистемы языка (лиспа, форта, и др.) в МК? Разве что только для поднятия ЧСВ :) Главное ведь чтобы диодик мигал, верно :)

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

P.S Помнится, кто то в рамках Форт системы на компьтере моделировал решение технологической задачи, а потом это решение уже запускалось и доводилось на месте в контроллере на производстве.
Сообщение Добавлено: Вт мар 13, 2018 14:27
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
KPG писал(а):
Хочется услышать аргументы за использование Лисп в задачах для микро-контроллеров.
Что это за задачи где преимущество владения Лисп инструментарием перекроет владение Форт инструментарием.
А где я писал о преимуществах? Никто не любит заморачиваться, поэтому каждый выберет тот инструмент, которым он хорошо владеет.
KPG писал(а):
Зачем сборщик мусора в рамках 2Кб адресной памяти.
В данном случае без него можно обойтись.
KPG писал(а):
Здесь, в основном. интересующиеся Форт инструментарием и для "продвижения" Лисп требуется соответствующая аргументация.
Лисп пусть продвигают лисперы, а я лишь его временный (бесплатный) адвокат.
KPG писал(а):
Был задан обычный вопрос, расцененый Вами как холивар и ещё и наезды кому и что будет понятно (даже без акцента какое решение будет "глючным" vs "удобным" ).
Естественно, каждый кулик свое болото хвалит :)
KPG писал(а):
Написав ДСЛ на Лиспе, понятный только автору, что тогда останется от самого Лиспа в этом ДСЛ?
т.е. будет кросс компиляция и Лиспа в контроллере не предвидется?
А зачем вообще нужна реализация всей экосистемы языка (лиспа, форта, и др.) в МК? Разве что только для поднятия ЧСВ :) Главное ведь чтобы диодик мигал, верно :)
Сообщение Добавлено: Вт мар 13, 2018 13:51
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
loztcatz писал(а):
Так никто мне не ответил, что таково сложного в реализации лисповского диалогового режима, ведь по своей сути он примитивен (к примеру, у питона он реализован гораздо сложнее). В общем, его можно без особых проблем реализовать на чем угодно, хоть на форте, хоть на асме. Но вместо конкретного ответа, вами был устроен очередной холивар.

Причём тут холивар?
Хочется услышать аргументы за использование Лисп в задачах для микро-контроллеров.
Что это за задачи где преимущество владения Лисп инструментарием перекроет владение Форт инструментарием.

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

Зачем сборщик мусора в рамках 2Кб адресной памяти.

loztcatz писал(а):
S-выражения лишь удобная форма записи АСТ, достаточно простого для разбора и преобразований. А конечная цель - получение машкодов.

Никто же не против, если Вам так удобно, но пользователям Форт, предположу, что он удобен в большинстве случаев. :)
Здесь, в основном. интересующиеся Форт инструментарием и для "продвижения" Лисп требуется соответствующая аргументация.

P.S. Реализаций кросс Фортов на Лиспе достаточно примеров (даже для испольования МК например Staapl для PIC18), а обратного почти нет.
Был задан обычный вопрос, расцененый Вами как холивар и ещё и наезды кому и что будет понятно (даже без акцента какое решение будет "глючным" vs "удобным" ). :)
Написав ДСЛ на Лиспе, понятный только автору, что тогда останется от самого Лиспа в этом ДСЛ?
т.е. будет кросс компиляция и Лиспа в контроллере не предвидется?
Можете описать этот ДСЛ язык?
Сообщение Добавлено: Вт мар 13, 2018 12:54
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
Цель лиспера: написать дсл удобный для генерации машкодов, но понятный только его автору.
Цель фортера: реализовать невообразимо глючную недофорт-систему, понятную лишь её автору.

PS В каждой шутке есть доля шутки :)
Сообщение Добавлено: Вт мар 13, 2018 12:43
  Заголовок сообщения:  Re: О естественности FORTH-решений  Ответить с цитатой
Victor__v писал(а):
Ничего сложного, кроме динамической типизации
И она тоже абсолютно необязательна, хотя и удобна. Кстати, реализуется она достаточно просто :)
Сообщение Добавлено: Вт мар 13, 2018 12:32

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


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