Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
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 ] ;
чем писать ассемблер.
[quote="gudleifr"]Здесь мы имеем порочный круг. При реализации Forth на чистом Forth нужна, действительно, какая-то виртуальная Forth-машина. Но ее не реализовать на чистом Forth. Собрать из готовых частей? Но и их не написать на чистом Forth.[/quote]
Мне достаточно было сэмулировать целевое адресное пространство. Для этого, требуется чтобы инструментальное и адресное пространство не накладывались друг на друга. Если накладываются, инструментальные средства можно (на пример) перенести в другое место. Переопределяю слова работающие с памятью - следующим образом:
[code] : 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 ; [/code]
Где THERE? определяет принадлежность адреса целевой области. TEXECUTE - перед передачей управления, целевое CFA заменяет на эквивалентное ему инструментальное по средствам таблицы соответствия. Целевой компилятор, при этом, будет представлять набор тех-же средств компиляции что и в целевой системе. Этот-же механизм я использую для взаимодействия с удаленным устройством в распределенной форт-системе.
[quote="gudleifr"] Чем раньше мы разорвем этот круг и перейдем на язык ассемблера (пусть и встроенного в Forth), тем раньше это заработает. [/quote] Если встроенного ассемблера нет, то проще [url=http://planet.plt-scheme.org/package-source/zwizwa/staapl.plt/1/9/mcf/eforth/eforth.f]минимизировать количество примитивов[/url] и представить их в виде: [code] : DUP [ 0x8D C, 0x6D C, 0xFC C, \ LEA EBP , -4 [EBP] 0x89 C, 0x45 C, 0x00 C, \ MOV 0 [EBP] , EAX 0xC3 C, \ RET ] ; [/code]чем писать ассемблер.
|
|
|
|
Добавлено: Ср мар 21, 2012 11:28 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
gudleifr писал(а): П.Хендерсон, ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ, МОСКВА «МИР» 1983 Рассматривается некоторый ограниченный (инструментальный) LISP, зато подробно рассматривается, как вся эта фигня "самозамыкается". Оттуда: Компилятор http://vaxbusters.org/lispkit/LKIT-2/LISPKIT.LKS и откомпилированный компилятор - так лучше, чем картинкой.
[quote="gudleifr"]П.Хендерсон, ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ, МОСКВА «МИР» 1983 Рассматривается некоторый ограниченный (инструментальный) LISP, зато подробно рассматривается, как вся эта фигня "самозамыкается". Оттуда: Компилятор[/quote][url]http://vaxbusters.org/lispkit/LKIT-2/LISPKIT.LKS[/url] и [url=http://vaxbusters.org/lispkit/LKIT-2/test.lkc]откомпилированный компилятор[/url] - так лучше, чем картинкой.
|
|
|
|
Добавлено: Ср мар 21, 2012 02:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
Kopa писал(а): in4 писал(а): Это можно рассматривать как растущий стек. Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:) А если рассматривать кучу, а в конце ее маленький плавающий стек на пару фрагментов кода? А если указатели на границы фрагментов в переменных? Почему это нельзя рассматривать как растущий стек фрагментов переменной длины с доступом только к последним двум? Википедия-Стек писал(а): Стек (англ. stack — стопка) — структура данных, в которой доступ к элементам организован по принципу LIFO (англ. last in — first out, «последним пришёл — первым вышел»). Вроде вполне подходящая аналогия... Определению соответствует. Почему это недопустимо рассматривать как стек? Или для стека требуются дополнительные условия? Какие?
[quote="Kopa"][quote="in4"]Это можно рассматривать как растущий стек.[/quote] Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)[/quote]А если рассматривать кучу, а в конце ее маленький плавающий стек на пару фрагментов кода? А если указатели на границы фрагментов в переменных? Почему это нельзя рассматривать как растущий стек фрагментов переменной длины с доступом только к последним двум? [quote="Википедия-Стек"][b]Стек[/b] (англ. [i]stack[/i] — стопка) — структура данных, в которой доступ к элементам организован по принципу LIFO (англ. [i]last in — first out[/i], «последним пришёл — первым вышел»).[/quote]Вроде вполне подходящая аналогия... :shuffle; Определению соответствует. Почему это недопустимо рассматривать как стек? Или для стека требуются дополнительные условия? Какие?
|
|
|
|
Добавлено: Вт мар 20, 2012 23:28 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): Код компилируется как обычно. ... И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек.
Макрооптимизатор почти так постороен, за исключением что нет привязки к высокоуровневым цепочкам Форт команд. in4 писал(а): Это можно рассматривать как растущий стек.
Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)
[quote="in4"]Код компилируется как обычно. ... И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек. [/quote] Макрооптимизатор почти так постороен, за исключением что нет привязки к высокоуровневым цепочкам Форт команд. [quote="in4"] Это можно рассматривать как растущий стек. [/quote] Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)
|
|
|
|
Добавлено: Вт мар 20, 2012 22:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): Хочется все-таки понять смысл фразы. Плюньте, это старческое брюзжание...
[quote="in4"]Хочется все-таки понять смысл фразы.[/quote]Плюньте, это старческое брюзжание...
|
|
|
|
Добавлено: Вт мар 20, 2012 22:50 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
gudleifr писал(а): in4 писал(а): ... Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога... Можно поподробнее, "для тупых"... Хочется все-таки понять смысл фразы. М. есть какое-то различие в понимании. Вот хочу разобраться, чтоб "синхронизировать" понимание или хотя бы понять Вашу точку зрения.
[quote="gudleifr"][quote="in4"]...[/quote]Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...[/quote]Можно поподробнее, "для тупых"... ;) Хочется все-таки понять смысл фразы. М. есть какое-то различие в понимании. Вот хочу разобраться, чтоб "синхронизировать" понимание или хотя бы понять Вашу точку зрения. :shuffle;
|
|
|
|
Добавлено: Вт мар 20, 2012 22:47 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
gudleifr писал(а): in4 писал(а): В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы... Это противоречит идее Forth. Тупой программист и умный оператор! Тут хотелось бы разделить задачи, которые решают программист и оператор. Программист делает систему. Оператор решает свою задачу с использованием этой системы. Полное знание системы от него не требуется, чтобы ее использовать. Достаточно уметь работать " интерфейсом" (не обязательно даже знать все его возможности!). Для включения телевизора с пульта не обязательно полностью понимать их принципы работы. Хотя знание внутренностей системы дает дополнительные возможности. А так достаточно знать, что "при работе системы некоторые оптимизации выполяются".
[quote="gudleifr"][quote="in4"]В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы...[/quote]Это противоречит идее Forth. Тупой программист и умный оператор![/quote]Тут хотелось бы разделить задачи, которые решают программист и оператор. Программист делает систему. Оператор решает свою задачу с использованием этой системы. Полное знание системы от него не требуется, чтобы ее использовать. Достаточно уметь работать " интерфейсом" (не обязательно даже знать [b]все[/b] его возможности!). Для включения телевизора с пульта не обязательно полностью понимать их принципы работы. Хотя знание внутренностей системы дает дополнительные возможности. А так достаточно знать, что "при работе системы некоторые оптимизации выполяются".
|
|
|
|
Добавлено: Вт мар 20, 2012 22:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): ... Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...
[quote="in4"]...[/quote]Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...
|
|
|
|
Добавлено: Вт мар 20, 2012 22:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
`Kopa писал(а): Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода Неправильно... Сейчас объясню, что имел ввиду. Код генерируется как обычно, компилирующими словами. По адресу в here. Это обычная куча. И растет к бОльшим адресам. Скомпилированный код накапливается тут. И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек. При необходимости оптимизации происходит выделение параметров предыдущих команд и "возврат" dp (и соотв. here) на запомненные места. Как удаление из стека. "Последнее скомпилированное первым удаляется." Потом компилируется новый код с использованием выделенных параметров. "Стек" снова растет. (Если остаются сложности - спрашивайте, объясню еще более подробно и с конкретным кодом).
[quote="`Kopa"]Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода[/quote]Неправильно... :( Сейчас объясню, что имел ввиду. Код генерируется как обычно, компилирующими словами. По адресу в [b]here[/b]. Это обычная куча. И растет к бОльшим адресам. Скомпилированный код накапливается тут. И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек. При необходимости оптимизации происходит выделение параметров предыдущих команд и "возврат" [b]dp[/b] (и соотв. [b]here[/b]) на запомненные места. Как удаление из стека. "Последнее скомпилированное первым удаляется." ;) Потом компилируется новый код с использованием выделенных параметров. "Стек" снова растет. (Если остаются сложности - спрашивайте, объясню еще более подробно и с конкретным кодом).
|
|
|
|
Добавлено: Вт мар 20, 2012 22:35 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы... Это противоречит идее Forth. Тупой программист и умный оператор!
[quote="in4"]В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы...[/quote]Это противоречит идее Forth. Тупой программист и умный оператор!
|
|
|
|
Добавлено: Вт мар 20, 2012 22:25 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
gudleifr писал(а): Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали. Ну, я не надеюсь, а уверен, ЧТО будет, раз уж так сделал. Например, если в коде будет определенное сочетание операций, то при генерации следующей будет сделана указанная оптимизация. Ни больше, но и ни меньше! gudleifr писал(а): А то, что будет пользоваться кто-то другой - забудьте. В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы... А как образец простой оптимизации - годится! И эту идею можно тиражировать. gudleifr писал(а): Проще свой Forth написать, чем чужой выучить. Не всегда. Но исправлять ошибки, похоже, проще таки в своем! Пробовал, был опыт - много времени потерял... gudleifr писал(а): Тем более, что, по определению, каждая новая задача порождает новый Forth. Не всегда, но для разных классов задач - верно. gudleifr писал(а): Forth, это не язык - это способ написания языков. 100% за! И хочется этот способ применить для других систем, более современных по тенденциям развития компьютеров и интерфейсов. Что и хочется обсуждать в теме.
[quote="gudleifr"]Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали.[/quote]Ну, я не надеюсь, а уверен, ЧТО будет, раз уж так сделал. Например, если в коде будет определенное сочетание операций, то при генерации следующей будет сделана указанная оптимизация. Ни больше, но и ни меньше! :) [quote="gudleifr"]А то, что будет пользоваться кто-то другой - забудьте.[/quote]В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы... А как образец простой оптимизации - годится! И эту [b]идею[/b] можно тиражировать. [quote="gudleifr"]Проще свой Forth написать, чем чужой выучить.[/quote]Не всегда. Но исправлять ошибки, похоже, проще таки в своем! :) Пробовал, был опыт - много времени потерял... :( [quote="gudleifr"]Тем более, что, по определению, каждая новая задача порождает новый Forth.[/quote]Не всегда, но для разных классов задач - верно. [quote="gudleifr"]Forth, это не язык - это способ написания языков.[/quote]100% за! :) И хочется этот [b]способ[/b] применить для других систем, более современных по тенденциям развития компьютеров и интерфейсов. Что и хочется обсуждать в [url=http://fforum.winglion.ru/viewtopic.php?p=34835#p34835]теме[/url].
|
|
|
|
Добавлено: Вт мар 20, 2012 22:20 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте! :) Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода
[quote="in4"]Ну так они и "откладываются"... Как раз в стеке кучи - [b]dp @[/b] == [b]here[/b] ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код [b]уже[/b] на месте! :)[/quote] Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода
|
|
|
|
Добавлено: Вт мар 20, 2012 22:16 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): ... Все смешалось в доме Облонских... Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали. Причем, путем какой-то сложной подмены того, что есть, на то, что хотелось бы, но не бывает. Все проще: если Вы умеете что-то делать, Вы можете делать или пустить на самотек, то чего Вы не можете, Вы обязаны пустить на самотек... А то, что будет пользоваться кто-то другой - забудьте. Проще свой Forth написать, чем чужой выучить. Тем более, что, по определению, каждая новая задача порождает новый Forth. Forth, это не язык - это способ написания языков.
[quote="in4"]...[/quote]Все смешалось в доме Облонских... Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали. Причем, путем какой-то сложной подмены того, что есть, на то, что хотелось бы, но не бывает. Все проще: если Вы умеете что-то делать, Вы можете делать или пустить на самотек, то чего Вы не можете, Вы обязаны пустить на самотек... А то, что будет пользоваться кто-то другой - забудьте. Проще свой Forth написать, чем чужой выучить. Тем более, что, по определению, каждая новая задача порождает новый Forth. Forth, это не язык - это способ написания языков.
|
|
|
|
Добавлено: Вт мар 20, 2012 22:03 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
`Kopa писал(а): А не проще ли откладывать команды в стековую структуру для оперативного анализа? Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте!
[quote="`Kopa"]А не проще ли откладывать команды в стековую структуру для оперативного анализа?[/quote]Ну так они и "откладываются"... Как раз в стеке кучи - [b]dp @[/b] == [b]here[/b] ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код [b]уже[/b] на месте! :)
|
|
|
|
Добавлено: Вт мар 20, 2012 22:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: Сравнение возможностей саморасширения Forth-LISP |
|
|
in4 писал(а): Если это делать потом, восстановить семантику труднее. Например, опрерация + после литерала изменяет "push + mov ax,const" на "add ax, const". При этом она использует указатели на границы кодов команд. А не проще ли откладывать команды в стековую структуру для оперативного анализа?
[quote="in4"] Если это делать потом, восстановить семантику труднее. Например, опрерация [b]+[/b] после литерала изменяет "[b]push[/b] + [b]mov ax,const[/b]" на "[b]add ax, const[/b]". При этом она использует указатели на границы кодов команд. [/quote] А не проще ли откладывать команды в стековую структуру для оперативного анализа?
|
|
|
|
Добавлено: Вт мар 20, 2012 21:52 |
|
|
|
|