Forth http://fforum.winglion.ru/ |
|
Идеология компилятора и защищённый режим http://fforum.winglion.ru/viewtopic.php?f=4&t=996 |
Страница 1 из 2 |
Автор: | yug [ Пт окт 26, 2007 20:43 ] |
Заголовок сообщения: | Идеология компилятора и защищённый режим |
Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями). В то же время идеология форт-компилятора - это весьма вульгарно понятый принцип фон Неймана - "вали код и данные в общую кучу - там разберёмся". Противоречие, однако. И ещё один моментик. В защищённом режиме в секцию кода запрещено не только писать, но и читать оттуда иначе как через EIP/IP. Короче, каменюка сыграет исключение, и префикс CS: не прокатит, как в реальном. Вопрос: как при таких драконовских условиях форт-система может работать, причём и с сохранением традиционной "идеологии кучи"? Ведь она должна и компилировать новый код, и выполнять его. Была такая задумка: спроектировать форт-систему специально под архитектуру Пентиума-4/Атлона с разделением ресурсов по сегментам. Но даст ли это какой-нибудь выигрыш? Прямой шитый код уже не катит - в нём "идеология кучи" выражена сильнее всего. Косвенный шитый... О его независимости от платформы можно слагать легенды. Да и для разделения ресурсов он приспособлен как нельзя кстати: 1. машкод присутствует только в низкоуровневых словах; 2. в самой форт-системе он представлен всего одной ячейкой, правда используемой нерационально: она ссылается на следующую ячейку, с которой код и начинается. Но что мешает перенести этот самый код в другое место, не трогая ничего в высокоуровневых словах? Правда, есть одно "но", этакая ложечка дёгтя: структура < CREATE ... DOES> ... >. Её невозможно сделать традиционными форт-средствами без фокусов с машинным кодом. Есть древнее решение этой проблемы - фиговское < <BUILDS ... DOES> ... >, но оно было "при царе Горохе, когда людей было трохи" и сейчас не используется. Подпрограммный код тоже легко переносится в сегменты при условии его представительства в секции данных (словаре) адресной ячейкой. И с < CREATE ... DOES> ... > тоже проблем не будет - машкод он и в Африке машкод! А как тогда быть с запретом на компиляцию в секцию кода? |
Автор: | вопрос [ Пт окт 26, 2007 21:37 ] |
Заголовок сообщения: | |
Кстати - а как работают реально существующие форты под защищённый режим |
Автор: | Hishnik [ Пт окт 26, 2007 23:13 ] |
Заголовок сообщения: | |
В защищенном режиме вполне можно делать разделение кода и данных. Для чтения/записи в сегмент кода существует такое понятие, как алиас сегмента, создаваемый стандартной функцией ДОС-экстендера. На практике это сегмент с теми же базовым адресом и лимитом, что и сегмент кода, но в котором установлены флаги, разрешающие чтение и запись. Так что никакого запрета на модифицировние сегмента кода на деле нет. |
Автор: | mOleg [ Сб окт 27, 2007 01:29 ] |
Заголовок сообщения: | |
эхехех. 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 не помню, да и не прижилось. |
Автор: | yug [ Сб окт 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> ... > платформеннонезависимым? |
Автор: | yug [ Сб окт 27, 2007 11:28 ] |
Заголовок сообщения: | |
Для всех танкистов: Проблема < CREATE ... DOES> ... > реально существует только для косвенного шитого кода (см. Баранов). Для подпрограммного и прямого кодов её нет. |
Автор: | yug [ Сб окт 27, 2007 12:11 ] |
Заголовок сообщения: | |
Справка. Решение проблемы < CREATE ... DOES> ... > по Баранову (если кто не читал). 1. Слово DOES> в отличие от фига сделано IMMEDIATE. 2. Оно компилирует служебное слово (;CODE), которое при исполнении программирует поле кода дочернего слова. 3. После этого слова всегда подразумевается машинный код, он там и есть: CALL NEAR $DOES, его туда вгоняет DOES>, потому оно и IMMEDIATE. У Баранова там JSR, что то же самое. 4. Этот код работает не как вызов подпрограммы, а как JMP с загоном в стек данных адреса высокоуровневого обработчика - схема характерная для прямого шитого кода. 5. Дальше идёт высокоуровневый обработчик. |
Автор: | yz [ Сб окт 27, 2007 23:05 ] |
Заголовок сообщения: | Re: Идеология компилятора и защищённый режим |
yug писал(а): Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями).
Эта идеология полностью игнорируется операционными системами, работающими на этих самых интел-процах. Все они предпочитают нормальную плоскую память. И слава богу. |
Автор: | Hishnik [ Сб окт 27, 2007 23:53 ] |
Заголовок сообщения: | |
Вообще, разнести код и данные полезно во всех смыслах. И CREATE не создает проблем, и гарвардская архитектура более приятна. Если ориентироваться сразу на гарвардскую, то сэмулировать ее можно всегда. |
Автор: | mOleg [ Вс окт 28, 2007 04:45 ] |
Заголовок сообщения: | |
yug писал(а): To mOleg:
Подробнее о реализации низкоуровневых слов Спасибо за просвещение |
Автор: | yug [ Вс окт 28, 2007 09:33 ] |
Заголовок сообщения: | |
Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными? Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1. А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния? Плоская модель памяти не запрещает создавать в ней сегменты (или секции, кому как нравится). Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость). |
Автор: | yug [ Вс окт 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 ] |
Заголовок сообщения: | |
Цитата: Мне пришла мысль по поводу
Да, любому, кто знакомится с фортом, приходит в голову куча разных мыслей |
Автор: | Гость [ Вс окт 28, 2007 14:55 ] |
Заголовок сообщения: | |
Цитата: Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно похожее делается через виртуализацию: у каждого процесса свое адресное пространство, а выделенные страницы памяти могут лежать в каком угодно месте физической памяти (или, обратно: отображаться на любую часть адресного пространства).
|
Автор: | Hishnik [ Вс окт 28, 2007 16:23 ] |
Заголовок сообщения: | |
yug писал(а): Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).
Windows использует все же линейную модель, все сегментные регистры указывают на дескрипторы с базовым адресом 0 и пределом 4 Гб. Так что простого перемещения программ нет. А в чем проблема с 4 Гб? Уже минимум две такие в пределах моей досягаемости, служат рабочими станциями для удаленного захода туда. Гигабайт стоит дешевле 40 у.е., это вообще не тот вопрос. И в ближайшие годы в компьютерах будет больше - и 8, и 16. |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |