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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:17 
mOleg писал(а):
что такое "неявное ассемблирование"
Подсовывание заранее ассемблированных кусков.
Если "штатные методы", это "переносимый" байт-код, то это не интересно.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:19 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1261
Благодарил (а): 3 раз.
Поблагодарили: 19 раз.
gudleifr писал(а):
а FIND у Вас шедеврален! Уже не в первый раз Вы считаете оптимальной функциональностью отсутствие таковой. (Кстати, а куда делся флаг?)

Ноль - то ничего не найдено. Не ноль - на стеке адрес узла списка. Да и указано же - в простейшем случае.
Чем проще устройство - тем оно надежнее.

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:30 
VoidVolker писал(а):
Ноль - то ничего не найдено.
Стандартно: cfa,-1|cfa,1|0. По уму, надо бы nfa|0. Проблема честной Forth-реализации в чем?
1) если "просто" список, то число слов в определении примерно равно числу процессорных команд;
2) если таблица расстановки, то работает быстрее и на слова разложить можно, но такая таблица будет практически бесполезна для других целей; создавать обобщенную таблицу расстановки с подбором размера, выбором хэш-функции и полноценными списками - слишком утяжелит ядро;
3) если немного сжульничать с хранением имен (по Муру), то число слов станет больше числа процессорных команд.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:31 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Подсовывание заранее ассемблированных кусков.
А что в этом плохого? Задача ведь решается?

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:37 
gudleifr писал(а):
.
Если "штатные методы", это "переносимый" байт-код, то это не интересно.


Почему не интересно, если будет "штатным" средством JIT компилятор?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:38 
in4 писал(а):
gudleifr писал(а):
Подсовывание заранее ассемблированных кусков.
А что в этом плохого?
`Kopa писал(а):
gudleifr писал(а):
Если "штатные методы", это "переносимый" байт-код, то это не интересно.
Почему не интересно, если будет "штатным" средством JIT компилятор?
Тем, что честное ассемблирование проще и дает больше возможностей.
P.S. Вообще, не знаю как, мы, наконец, начали обсуждение того, чем является Forth. Если еще привязать к "Forth в разрезе", то не только друг друга чему научим, а, глядишь, и пару сотен неофитов...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:45 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Тем, что честное ассемблирование проще и дает больше возможностей.
Но зато "сборка из кодов" позволяет начать использовать возможности инструментальной Forth-системы на более раннем этапе - в процессе компиляции! Тут как раз можно начать применять "улучшенные" методы кодогенерации/оптимизации. Ну, как у Мура в colorForth-е... :)

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

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:51 
gudleifr писал(а):
Тем, что честное ассемблирование проще и дает больше возможностей.

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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 20:55 
in4 писал(а):
...
`Kopa писал(а):
больше возможностей? - под вопросом.
Плохо понимаю о чем речь, но, если я могу на лету скомпилировать "тот самый" блок, то как это может быть хуже того, чтобы просто хранить его?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:04 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Плохо понимаю о чем речь, но, если я могу на лету скомпилировать "тот самый" блок, то как это может быть хуже того, чтобы просто хранить его?
Скомпилировать можно по-разному. Например, с оптимизацией - удалять/изменять последовательности кодов и заменять последовательность call + ret в конце слова на jmp , полчая аналог хвостовой рекурсии. Это все реализовано в colorForth. Не знаю ассемблеров, которые такое позволяют (если на макросах не реализовать часть Forth-а - так тоже делал ;) ). :( Просто вставка таких возможностей не дает... :(

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:07 
gudleifr писал(а):
in4 писал(а):
...
`Kopa писал(а):
больше возможностей? - под вопросом.
Плохо понимаю о чем речь, но, если я могу на лету скомпилировать "тот самый" блок, то как это может быть хуже того, чтобы просто хранить его?


Больше возможностей только под одним критерием - "жизнеcпособности" решения в разных условиях (окружения).

P.S. Cкомпилировать "на лету" это и есть одна из составляющих терминологии JIT. и это конечно лучше т.к. к моменту компиляции уже может быть достаточно информации для эффективной привязке кода "по месту"


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:11 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
gudleifr писал(а):
mOleg писал(а):что такое "неявное ассемблирование"
Цитата:
Подсовывание заранее ассемблированных кусков.Если "штатные методы", это "переносимый" байт-код, то это не интересно.

У вас бедная фантазия, вариантов больше.

VoidVolker писал(а):
Ноль - то ничего не найдено. Не ноль - на стеке адрес узла списка. Да и указано же - в простейшем случае.Чем проще устройство - тем оно надежнее.

а у меня еще интереснее идея, если слово не найдено в словаре, делаем THROW с кодом "не найдено", а в INTERPRET делаем:
Код:
['] FIND CATCH IF  ?число ELSE  найдено THEN

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:13 
in4 писал(а):
Например, с оптимизацией - удалять/изменять последовательности кодов и заменять последовательность call + ret в конце слова на jmp , полчая аналог хвостовой рекурсии.
Кто пишет оптимизатор? Вы. Кто будет им пользоваться? Опять Вы. Зачем тогда Вам самого себя оптимизировать? Почему просто не запомнить рекомендации Рея Дункана и не отказаться от писания кривого кода? Или создать пару-другую макросов, учитывающих Ваши ассемблерные вкусы? Кто, в конце концов, запретит Вам скормить уже готовый блок вашему супер-пупер рандомизирущему оптимизатору?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:35 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Кто будет им пользоваться? Опять Вы. Зачем тогда Вам самого себя оптимизировать?
Ну, тут как раз не только я. Ну, я так скромно надеюсь... А если встрою в какую-нибудь систему - так наверняка! :)
gudleifr писал(а):
Почему просто не запомнить рекомендации Рея Дункана и не отказаться от писания кривого кода?
Из-за простоты реализации! При раскрутке проще генерить код по шаблону, потом применять правила оптимизации при добавлении последующего кода. Так сделано у Мура и мне нравится! :) Получается просто и понятно.
gudleifr писал(а):
Или создать пару-другую макросов, учитывающих Ваши ассемблерные вкусы?
А вот их сложно сделать. И если таки сделать, то получится ровно то же самое... ;) Ну, с точностью до...
gudleifr писал(а):
Кто, в конце концов, запретит Вам скормить уже готовый блок вашему супер-пупер рандомизирущему оптимизатору?
В момент компиляции все указатели и буфера актуальны. Если это делать позже - н. восстановить все, что было на момент генерации - это ресурсы. Кроме того, если будет сдвижка - код "поползет" и его надо будет в свою очередь пересматривать. А так оптимизация делается прямо во время генерации кода и "взгляд назад" обычно не превышает несколько предыдущих команд. Кроме того, оптимизация идет в компилирующем слове как часть его работы. Тут же учитывается и семантика. Если это делать потом, восстановить семантику труднее. Например, опрерация + после литерала изменяет "push + mov ax,const" на "add ax, const". При этом она использует указатели на границы кодов команд. Анализ кода для такой оптимизации намного сложнее - необходимо выделять кодовые последовательности, просматривая намного больше таблиц. С указателем проще! :)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 21:41 
Принципы Дункана хорошо, но мы имеем дело с Форт языком и - это уже уровень абстрагирования от реального железа.


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

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


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

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


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

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