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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Идеология компилятора и защищённый режим
СообщениеДобавлено: Пт окт 26, 2007 20:43 
Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями). В то же время идеология форт-компилятора - это весьма вульгарно понятый принцип фон Неймана - "вали код и данные в общую кучу - там разберёмся". Противоречие, однако.
И ещё один моментик. В защищённом режиме в секцию кода запрещено не только писать, но и читать оттуда иначе как через EIP/IP. Короче, каменюка сыграет исключение, и префикс CS: не прокатит, как в реальном.
Вопрос: как при таких драконовских условиях форт-система может работать, причём и с сохранением традиционной "идеологии кучи"? Ведь она должна и компилировать новый код, и выполнять его.
Была такая задумка: спроектировать форт-систему специально под архитектуру Пентиума-4/Атлона с разделением ресурсов по сегментам. Но даст ли это какой-нибудь выигрыш?
Прямой шитый код уже не катит - в нём "идеология кучи" выражена сильнее всего. Косвенный шитый... О его независимости от платформы можно слагать легенды. Да и для разделения ресурсов он приспособлен как нельзя кстати:
1. машкод присутствует только в низкоуровневых словах;
2. в самой форт-системе он представлен всего одной ячейкой, правда используемой нерационально: она ссылается на следующую ячейку, с которой код и начинается.
Но что мешает перенести этот самый код в другое место, не трогая ничего в высокоуровневых словах? Правда, есть одно "но", этакая ложечка дёгтя: структура < CREATE ... DOES> ... >. Её невозможно сделать традиционными форт-средствами без фокусов с машинным кодом. Есть древнее решение этой проблемы - фиговское < <BUILDS ... DOES> ... >, но оно было "при царе Горохе, когда людей было трохи" и сейчас не используется.
Подпрограммный код тоже легко переносится в сегменты при условии его представительства в секции данных (словаре) адресной ячейкой. И с < CREATE ... DOES> ... > тоже проблем не будет - машкод он и в Африке машкод! А как тогда быть с запретом на компиляцию в секцию кода?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт окт 26, 2007 21:37 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Кстати - а как работают реально существующие форты под защищённый режим
:? :?:

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт окт 26, 2007 23:13 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
В защищенном режиме вполне можно делать разделение кода и данных. Для чтения/записи в сегмент кода существует такое понятие, как алиас сегмента, создаваемый стандартной функцией ДОС-экстендера. На практике это сегмент с теми же базовым адресом и лимитом, что и сегмент кода, но в котором установлены флаги, разрешающие чтение и запись. Так что никакого запрета на модифицировние сегмента кода на деле нет.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб окт 27, 2007 01:29 
Не в сети
Moderator
Moderator
Аватара пользователя

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

yug писал(а):
Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями). В то же время идеология форт-компилятора - это весьма вульгарно понятый принцип фон Неймана - "вали код и данные в общую кучу - там разберёмся". Противоречие, однако.
И ещё один моментик. В защищённом режиме в секцию кода запрещено не только писать, но и читать оттуда иначе как через EIP/IP. Короче, каменюка сыграет исключение, и префикс CS: не прокатит, как в реальном.

вы не правы по той причине, что все (практически без исключений) форты работают с той моделью памяти, которую предлагает ОС (либо наиболее простую из моделей). Многосегментных форт-систем было много под досом, а вот под виндой это не удобно 8( с другой стороны, приведенная вами проблема достаточно просто обойдена в DSFORTH(который по мативам СПФа сделан). Да и вариантов разрешения проблем почти всегда несколько.

yug писал(а):
Вопрос: как при таких драконовских условиях форт-система может работать, причём и с сохранением традиционной "идеологии кучи"? Ведь она должна и компилировать новый код, и выполнять его.

не верно с идеалогией кучи. Не редко Форт-системы держат код, данные, имена в различных местах, просто сейчас времена виндов, и так получается проще. Впрочем и у линухов память "плоская".

yug писал(а):
Была такая задумка: спроектировать форт-систему специально под архитектуру Пентиума-4/Атлона с разделением ресурсов по сегментам. Но даст ли это какой-нибудь выигрыш?

скорее проигрыш по скорости и проигрыш в простоте.

yug писал(а):
Прямой шитый код уже не катит - в нём "идеология кучи" выражена сильнее всего. Косвенный шитый... О его независимости от платформы можно слагать легенды. Да и для разделения ресурсов он приспособлен как нельзя кстати:
1. машкод присутствует только в низкоуровневых словах;
2. в самой форт-системе он представлен всего одной ячейкой, правда используемой нерационально: она ссылается на следующую ячейку, с которой код и начинается.

про следующую ячейку не понял 8( поясните.
есть еще более красивая, но пока не реализованная модель, которая позволяет безнаказанно тягать код по памяти:)
один у нее недостаток - скорость низкая.
про то, что создать "защищенную форт-систему" только с косвенным ШК я говорил все время, правда Михаил меня так и не понял 8(
yug писал(а):
Но что мешает перенести этот самый код в другое место, не трогая ничего в высокоуровневых словах? Правда, есть одно "но", этакая ложечка дёгтя: структура < CREATE ... DOES> ... >. Её невозможно сделать традиционными форт-средствами без фокусов с машинным кодом. Есть древнее решение этой проблемы - фиговское < <BUILDS ... DOES> ... >, но оно было "при царе Горохе, когда людей было трохи" и сейчас не используется.

утверждение не верно. Все можно. Только обычно проще сделать использовав трюк. Причем проще не потому, что проще, а потому что лень прикинуть несколько вариантов и выбрать лучший. В моем форке http://fforum.winglion.ru/viewtopic.php?t=531 DOES> высокоуровневый, например.
насчет builds не помню, да и не прижилось.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб окт 27, 2007 10:39 
To mOleg:
Подробнее о реализации низкоуровневых слов под КШК можно узнать у Баранова или Семёнова (имею обе книги в бумаге). Сам принцип КШК состоит в двух разыменованиях кодовой ячейки в линейной последовательности кода. На саму ячейку указывает один из регистров проца, например SI/ESI, который как бы имитирует IP проца. При первом разыменовании получаем не сам код, а его адрес, т.е. шитый код - это последовательность cfa исполняемых слов (справедливо и для ПШК). После второго разыменования всегда имеем адрес машкода, его обычно выполняем командой JMP ячейка.
Всё это делает блок <Next> интерпретатора кода:
Код:
LODSW
MOV  BX, AX
JMP  [BX]

(реализация фиг-форт 16-разрядов, дося (с) Ю.А. Семёнов "Программирование на языке форт").
ИМХО стандарт фиг-форт признаёт только КШК, хоть он и самый медленный. Зато платформонезависимый!
Погнали дальше. Низкоуровневое слово - это обычный машинный код, в конце которого обязательно стоят вышеприведённые 3 команды NEXT. В соответствии с семантикой NEXT точка входа в него должна быть записана в ячейке с адресом cfa. А сам код обычно компилируется в поле параметров, т.е., начиная со СЛЕДУЮЩЕЙ ЯЧЕЙКИ.
Для справок блок CALL входа в высокоуровневое слово (у Семёнова - $COL):
Код:
ADD  BP, -2
ADD  BX, 2
MOV  [BP], SI
MOV  SI, BX
NEXT

Здесь BP - указатель стека возвратов, а BX - зарезервированный системой регистр для быстрого доступа к полям кода и параметров.
И блок DOES (справедливо ТОЛЬКО для фиг-форта!)
Код:
SUB  BP, 2
ADD  BX, 2
MOV  [BP], SI
MOV  SI, [BX]
ADD  BX, 2
PUSH  BX
NEXT

Делает то же самое, что и CALL, но дополнительно загоняет в стек данных pfa дочернего слова для последующей обработки высокоуровневым обработчиком. Слово <BUILDS создаёт в дочернем слове 2 поля кода, а слово DOES> их программирует: в первое заносит адрес своего обработчика (см. выше), а во второе - адрес входа в высокоуровневый исполнительный код материнского слова. Красиво, хоть и громоздковато, да и последующими стандартами отменено.
Меня интересует, можно ли сделать < CREATE ... DOES> ... > платформеннонезависимым?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб окт 27, 2007 11:28 
Для всех танкистов:
Проблема < CREATE ... DOES> ... > реально существует только для косвенного шитого кода (см. Баранов). Для подпрограммного и прямого кодов её нет.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб окт 27, 2007 12:11 
Справка. Решение проблемы < CREATE ... DOES> ... > по Баранову (если кто не читал).
1. Слово DOES> в отличие от фига сделано IMMEDIATE.
2. Оно компилирует служебное слово (;CODE), которое при исполнении программирует поле кода дочернего слова.
3. После этого слова всегда подразумевается машинный код, он там и есть: CALL NEAR $DOES, его туда вгоняет DOES>, потому оно и IMMEDIATE. У Баранова там JSR, что то же самое.
4. Этот код работает не как вызов подпрограммы, а как JMP с загоном в стек данных адреса высокоуровневого обработчика - схема характерная для прямого шитого кода.
5. Дальше идёт высокоуровневый обработчик.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Идеология компилятора и защищённый режим
СообщениеДобавлено: Сб окт 27, 2007 23:05 
Не в сети

Зарегистрирован: Сб янв 27, 2007 22:00
Сообщения: 106
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
yug писал(а):
Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями).

Эта идеология полностью игнорируется операционными системами, работающими на этих самых интел-процах. Все они предпочитают нормальную плоскую память. И слава богу.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб окт 27, 2007 23:53 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Вообще, разнести код и данные полезно во всех смыслах. И CREATE не создает проблем, и гарвардская архитектура более приятна. Если ориентироваться сразу на гарвардскую, то сэмулировать ее можно всегда.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 04:45 
Не в сети
Moderator
Moderator
Аватара пользователя

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

Спасибо за просвещение ;)

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 09:33 
Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными?
Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1.

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

Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 12:22 
Мне пришла мысль по поводу секционирования форта классической реализации.
1. Секция кодофайла.
2. Секция стека возвратов.
3. Секция стека данных.
4. Секция USER-ARRAY.
5. Секция буферов ввода-вывода: TIB, блочные, файловые и проч.

Особенность - нельзя слова работы со стеком делать высокоуровневыми
Код:
: DUP SP@ @ ;
: PICK CELLS SP@ + @ ;

поскольку @ использует в качестве форт-адреса оффсет кодофайла, а не стека данных, а SP@ вообще теряет всякий смысл. Ну получили текущий оффсет вершины стека в егоном сегменте, а что с ним делать?

Ещё может быть организовать динамическое переключение между стеками данных и возвратов, чтобы использовать все пушки-попки и EBP для работы со стеком как с массивом (полезно при реализации PICK, OVER и проч.)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 14:39 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Мне пришла мысль по поводу

Да, любому, кто знакомится с фортом, приходит в голову куча разных мыслей :D

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 14:55 
Цитата:
Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно
похожее делается через виртуализацию: у каждого процесса свое адресное пространство, а выделенные страницы памяти могут лежать в каком угодно месте физической памяти (или, обратно: отображаться на любую часть адресного пространства).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 28, 2007 16:23 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
yug писал(а):
Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).


Windows использует все же линейную модель, все сегментные регистры указывают на дескрипторы с базовым адресом 0 и пределом 4 Гб. Так что простого перемещения программ нет.

А в чем проблема с 4 Гб? Уже минимум две такие в пределах моей досягаемости, служат рабочими станциями для удаленного захода туда. Гигабайт стоит дешевле 40 у.е., это вообще не тот вопрос. И в ближайшие годы в компьютерах будет больше - и 8, и 16.


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

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


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

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


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

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