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

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

Обзор темы - Сравнение возможностей саморасширения Forth-LISP
Автор Сообщение
  Заголовок сообщения:  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
] ;
чем писать ассемблер.
Сообщение Добавлено: Ср мар 21, 2012 11:28
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
gudleifr писал(а):
П.Хендерсон, ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ, МОСКВА «МИР» 1983
Рассматривается некоторый ограниченный (инструментальный) LISP, зато подробно рассматривается, как вся эта фигня "самозамыкается".
Оттуда:
Компилятор
http://vaxbusters.org/lispkit/LKIT-2/LISPKIT.LKS и откомпилированный компилятор - так лучше, чем картинкой.
Сообщение Добавлено: Ср мар 21, 2012 02:55
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
Kopa писал(а):
in4 писал(а):
Это можно рассматривать как растущий стек.
Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)
А если рассматривать кучу, а в конце ее маленький плавающий стек на пару фрагментов кода?
А если указатели на границы фрагментов в переменных?
Почему это нельзя рассматривать как растущий стек фрагментов переменной длины с доступом только к последним двум?
Википедия-Стек писал(а):
Стек (англ. stack — стопка) — структура данных, в которой доступ к элементам организован по принципу LIFO (англ. last in — first out, «последним пришёл — первым вышел»).
Вроде вполне подходящая аналогия... :shuffle;
Определению соответствует. Почему это недопустимо рассматривать как стек?
Или для стека требуются дополнительные условия? Какие?
Сообщение Добавлено: Вт мар 20, 2012 23:28
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
Код компилируется как обычно. ... И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек.

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

Нельзя. Если бы в стеке откладывались указатели на генерируемый код то это ещё допустимо:)
Сообщение Добавлено: Вт мар 20, 2012 22:57
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
Хочется все-таки понять смысл фразы.
Плюньте, это старческое брюзжание...
Сообщение Добавлено: Вт мар 20, 2012 22:50
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
gudleifr писал(а):
in4 писал(а):
...
Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...
Можно поподробнее, "для тупых"... ;) Хочется все-таки понять смысл фразы. М. есть какое-то различие в понимании. Вот хочу разобраться, чтоб "синхронизировать" понимание или хотя бы понять Вашу точку зрения. :shuffle;
Сообщение Добавлено: Вт мар 20, 2012 22:47
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
gudleifr писал(а):
in4 писал(а):
В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы...
Это противоречит идее Forth. Тупой программист и умный оператор!
Тут хотелось бы разделить задачи, которые решают программист и оператор. Программист делает систему. Оператор решает свою задачу с использованием этой системы. Полное знание системы от него не требуется, чтобы ее использовать. Достаточно уметь работать " интерфейсом" (не обязательно даже знать все его возможности!). Для включения телевизора с пульта не обязательно полностью понимать их принципы работы. Хотя знание внутренностей системы дает дополнительные возможности. А так достаточно знать, что "при работе системы некоторые оптимизации выполяются".
Сообщение Добавлено: Вт мар 20, 2012 22:43
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
...
Пардон, когда я говорил "тупой програпммист", я не подозревал, что все так запущено... Извините, ради бога...
Сообщение Добавлено: Вт мар 20, 2012 22:38
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
`Kopa писал(а):
Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода
Неправильно... :( Сейчас объясню, что имел ввиду.
Код генерируется как обычно, компилирующими словами. По адресу в here. Это обычная куча. И растет к бОльшим адресам. Скомпилированный код накапливается тут. И поддерживается пара указателей на предыдущие скомпилированные команды. Это можно рассматривать как растущий стек.
При необходимости оптимизации происходит выделение параметров предыдущих команд и "возврат" dp (и соотв. here) на запомненные места. Как удаление из стека. "Последнее скомпилированное первым удаляется." ;) Потом компилируется новый код с использованием выделенных параметров. "Стек" снова растет. (Если остаются сложности - спрашивайте, объясню еще более подробно и с конкретным кодом).
Сообщение Добавлено: Вт мар 20, 2012 22:35
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы...
Это противоречит идее Forth. Тупой программист и умный оператор!
Сообщение Добавлено: Вт мар 20, 2012 22:25
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
gudleifr писал(а):
Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали.
Ну, я не надеюсь, а уверен, ЧТО будет, раз уж так сделал. Например, если в коде будет определенное сочетание операций, то при генерации следующей будет сделана указанная оптимизация. Ни больше, но и ни меньше! :)
gudleifr писал(а):
А то, что будет пользоваться кто-то другой - забудьте.
В данном случае я говорил не об исходниках, а о конечном пользователе, который может и не знать о внутренностях системы...
А как образец простой оптимизации - годится! И эту идею можно тиражировать.
gudleifr писал(а):
Проще свой Forth написать, чем чужой выучить.
Не всегда. Но исправлять ошибки, похоже, проще таки в своем! :) Пробовал, был опыт - много времени потерял... :(
gudleifr писал(а):
Тем более, что, по определению, каждая новая задача порождает новый Forth.
Не всегда, но для разных классов задач - верно.
gudleifr писал(а):
Forth, это не язык - это способ написания языков.
100% за! :) И хочется этот способ применить для других систем, более современных по тенденциям развития компьютеров и интерфейсов. Что и хочется обсуждать в теме.
Сообщение Добавлено: Вт мар 20, 2012 22:20
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте! :)

Правильно ли я понял, что при этом приходится переключать указатель стека DP между стеком данных и стеком (кучей) в области построения кода (HERE) или можно использовать как обычный стек, памятуя что при формировании кода операции он должен быть "актуализирован" При этом,лучше всего, подходит программная память на ОЗУ.для формирования кода
Сообщение Добавлено: Вт мар 20, 2012 22:16
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
...
Все смешалось в доме Облонских... Вы как-то надеетесь, что то, что Вы делаете вдруг сможет оказаться умнее, чем Вы предполагали. Причем, путем какой-то сложной подмены того, что есть, на то, что хотелось бы, но не бывает. Все проще: если Вы умеете что-то делать, Вы можете делать или пустить на самотек, то чего Вы не можете, Вы обязаны пустить на самотек... А то, что будет пользоваться кто-то другой - забудьте. Проще свой Forth написать, чем чужой выучить. Тем более, что, по определению, каждая новая задача порождает новый Forth. Forth, это не язык - это способ написания языков.
Сообщение Добавлено: Вт мар 20, 2012 22:03
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
`Kopa писал(а):
А не проще ли откладывать команды в стековую структуру для оперативного анализа?
Ну так они и "откладываются"... Как раз в стеке кучи - dp @ == here ;) При этом не потребляется дополнительной памяти и если оптимизация не нужна - код уже на месте! :)
Сообщение Добавлено: Вт мар 20, 2012 22:00
  Заголовок сообщения:  Re: Сравнение возможностей саморасширения Forth-LISP  Ответить с цитатой
in4 писал(а):
Если это делать потом, восстановить семантику труднее. Например, опрерация + после литерала изменяет "push + mov ax,const" на "add ax, const". При этом она использует указатели на границы кодов команд.

А не проще ли откладывать команды в стековую структуру для оперативного анализа?
Сообщение Добавлено: Вт мар 20, 2012 21:52

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


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