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

...
Google Search
Forth-FAQ Spy Grafic

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




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

А не проще ли откладывать команды в стековую структуру для оперативного анализа?


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

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
`Kopa писал(а):
А не проще ли откладывать команды в стековую структуру для оперативного анализа?
Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте! :)

_________________
With best wishes, in4.


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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Вт мар 20, 2012 22:16 
in4 писал(а):
Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте! :)

Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода


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

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

_________________
With best wishes, in4.


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


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

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
`Kopa писал(а):
Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода
Неправильно... :( Сейчас объясню, что имел ввиду.
Код генерируется как обычно, компилирующими словами. По адресу в here. Это обычная куча. И растет к бОльшим адресам. Скомпилированный код накапливается тут. И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек.
При необходимости оптимизации происходит выделение параметров предыдущих команд и "возврат" dp (и соотв. here) на запомненные места. Как удаление из стека. "Последнее скомпилированное первым удаляется." ;) Потом компилируется новый код с использованием выделенных параметров. "Стек" снова растет. (Если остаются сложности - спрашивайте, объясню еще более подробно и с конкретным кодом).

_________________
With best wishes, in4.


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


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

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

_________________
With best wishes, in4.


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

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
in4 писал(а):
...
Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...
Можно поподробнее, "для тупых"... ;) Хочется все-таки понять смысл фразы. М. есть какое-то различие в понимании. Вот хочу разобраться, чтоб "синхронизировать" понимание или хотя бы понять Вашу точку зрения. :shuffle;

_________________
With best wishes, in4.


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


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

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
in4 писал(а):
Код компилируется как обычно. ... И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек.

Макрооптимизатор почти так постороен, за исключением что нет привязки к высокоуровневым цепочкам Форт команд.
in4 писал(а):
Это можно рассматривать как растущий стек.

Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)


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

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Kopa писал(а):
in4 писал(а):
Это можно рассматривать как растущий стек.
Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)
А если рассматривать кучу, а в конце ее маленький плавающий стек на пару фрагментов кода?
А если указатели на границы фрагментов в переменных?
Почему это нельзя рассматривать как растущий стек фрагментов переменной длины с доступом только к последним двум?
Википедия-Стек писал(а):
Стек (англ. stack — стопка) — структура данных, в которой доступ к элементам организован по принципу LIFO (англ. last in — first out, «последним пришёл — первым вышел»).
Вроде вполне подходящая аналогия... :shuffle;
Определению соответствует. Почему это недопустимо рассматривать как стек?
Или для стека требуются дополнительные условия? Какие?

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Сравнение возможностей саморасширения Forth-LISP
СообщениеДобавлено: Ср мар 21, 2012 02:55 
gudleifr писал(а):
П.Хендерсон, ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ, МОСКВА «МИР» 1983
Рассматривается некоторый ограниченный (инструментальный) LISP, зато подробно рассматривается, как вся эта фигня "самозамыкается".
Оттуда:
Компилятор
http://vaxbusters.org/lispkit/LKIT-2/LISPKIT.LKS и откомпилированный компилятор - так лучше, чем картинкой.


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

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
gudleifr писал(а):
Здесь мы имеем порочный круг. При реализации Forth на чистом Forth нужна, действительно, какая-то виртуальная Forth-машина. Но ее не реализовать на чистом Forth. Собрать из готовых частей? Но и их не написать на чистом Forth.


Мне достаточно было сэмулировать целевое адресное пространство.
Для этого, требуется чтобы инструментальное и адресное пространство не
накладывались друг на друга. Если накладываются, инструментальные средства
можно (на пример) перенести в другое место.
Переопределяю слова работающие с памятью - следующим образом:

Код:
: C! DUP THERE? IF  T_C! EXIT THEN C! ;
: C@ DUP THERE? IF T_C@ EXIT THEN C@ ;
: ! DUP THERE? IF  T_! EXIT THEN ! ;
: @ DUP THERE? IF T_@ EXIT THEN @ ;
: EXECUTE DUP THERE? IF  TEXECUTE EXIT THEN EXECUTE ;


Где THERE? определяет принадлежность адреса целевой области.
TEXECUTE - перед передачей управления, целевое CFA заменяет на эквивалентное ему инструментальное
по средствам таблицы соответствия.
Целевой компилятор, при этом, будет представлять набор тех-же средств компиляции что и в целевой системе.
Этот-же механизм я использую для взаимодействия с удаленным устройством в распределенной форт-системе.

gudleifr писал(а):
Чем раньше мы разорвем этот круг и перейдем на язык ассемблера (пусть и встроенного в Forth), тем раньше это заработает.

Если встроенного ассемблера нет, то проще минимизировать количество примитивов и представить их в виде:
Код:
: DUP
[
0x8D C, 0x6D C, 0xFC  C,  \       LEA     EBP , -4 [EBP]
0x89 C, 0x45 C, 0x00   C, \        MOV     0 [EBP] , EAX
0xC3 C,     \         RET
] ;
чем писать ассемблер.


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

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


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

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


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

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