Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
yug писал(а): А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния?
С помощью страничной адресации. Точно также, как и Линукс.
[quote="yug"]А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния? [/quote]
С помощью страничной адресации. Точно также, как и Линукс.
|
|
|
|
Добавлено: Пн окт 29, 2007 11:55 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
yug писал(а): Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными? В каких всех отношениях? боюсь, что тут необходимо уточнение. Не стоит забывать, что СПФ делался под определенную задачу, а именно для написания eserv. yug писал(а): Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1. форт - не компилятор. (хотя бывает и такое). yug писал(а): А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния? окошки к гарвардской архитектуре отношения не имеют, как и вся линейка ix86 yug писал(а): Плоская модель памяти не запрещает создавать в ней сегменты (или секции, кому как нравится).
например как? пример для винды пожалуйста. yug писал(а): Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?) как минимум 4 штуки за последние несколько дней. только напомню, что под виндовсом более 2Г под одну задачу не отводится. yug писал(а): Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. все на уровне системы, а не прикладных задач. а вообще сейчас важнее страничная организация памяти. yug писал(а): Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).
на это все забили
[quote="yug"]Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными?[/quote] В каких всех отношениях? боюсь, что тут необходимо уточнение. Не стоит забывать, что СПФ делался под определенную задачу, а именно для написания eserv.
[quote="yug"]Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1. [/quote] форт - не компилятор. (хотя бывает и такое).
[quote="yug"]А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния? [/quote] окошки к гарвардской архитектуре отношения не имеют, как и вся линейка ix86
[quote="yug"]Плоская модель памяти не запрещает создавать в ней сегменты (или секции, кому как нравится). [/quote] например как? пример для винды пожалуйста.
[quote="yug"]Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?)[/quote] как минимум 4 штуки 8) за последние несколько дней. только напомню, что под виндовсом более 2Г под одну задачу не отводится.
[quote="yug"]Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится.[/quote] все на уровне системы, а не прикладных задач. а вообще сейчас важнее страничная организация памяти.
[quote="yug"]Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).[/quote]
на это все забили
|
|
|
|
Добавлено: Вс окт 28, 2007 17:01 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
yug писал(а): Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).
Windows использует все же линейную модель, все сегментные регистры указывают на дескрипторы с базовым адресом 0 и пределом 4 Гб. Так что простого перемещения программ нет.
А в чем проблема с 4 Гб? Уже минимум две такие в пределах моей досягаемости, служат рабочими станциями для удаленного захода туда. Гигабайт стоит дешевле 40 у.е., это вообще не тот вопрос. И в ближайшие годы в компьютерах будет больше - и 8, и 16.
[quote="yug"]Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).[/quote]
Windows использует все же линейную модель, все сегментные регистры указывают на дескрипторы с базовым адресом 0 и пределом 4 Гб. Так что простого перемещения программ нет.
А в чем проблема с 4 Гб? Уже минимум две такие в пределах моей досягаемости, служат рабочими станциями для удаленного захода туда. Гигабайт стоит дешевле 40 у.е., это вообще не тот вопрос. И в ближайшие годы в компьютерах будет больше - и 8, и 16.
|
|
|
|
Добавлено: Вс окт 28, 2007 16:23 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно похожее делается через виртуализацию: у каждого процесса свое адресное пространство, а выделенные страницы памяти могут лежать в каком угодно месте физической памяти (или, обратно: отображаться на любую часть адресного пространства).
[quote]Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно[/quote] похожее делается через виртуализацию: у каждого процесса свое адресное пространство, а выделенные страницы памяти могут лежать в каком угодно месте физической памяти (или, обратно: отображаться на любую часть адресного пространства).
|
|
|
|
Добавлено: Вс окт 28, 2007 14:55 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Мне пришла мысль по поводу
Да, любому, кто знакомится с фортом, приходит в голову куча разных мыслей
[quote]Мне пришла мысль по поводу [/quote]
Да, любому, кто знакомится с фортом, приходит в голову куча разных мыслей :D
|
|
|
|
Добавлено: Вс окт 28, 2007 14:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Мне пришла мысль по поводу секционирования форта классической реализации.
1. Секция кодофайла.
2. Секция стека возвратов.
3. Секция стека данных.
4. Секция USER-ARRAY.
5. Секция буферов ввода-вывода: TIB, блочные, файловые и проч.
Особенность - нельзя слова работы со стеком делать высокоуровневыми
Код: : DUP SP@ @ ; : PICK CELLS SP@ + @ ;
поскольку @ использует в качестве форт-адреса оффсет кодофайла, а не стека данных, а SP@ вообще теряет всякий смысл. Ну получили текущий оффсет вершины стека в егоном сегменте, а что с ним делать?
Ещё может быть организовать динамическое переключение между стеками данных и возвратов, чтобы использовать все пушки-попки и EBP для работы со стеком как с массивом (полезно при реализации PICK, OVER и проч.)
Мне пришла мысль по поводу секционирования форта классической реализации.
1. Секция кодофайла.
2. Секция стека возвратов.
3. Секция стека данных.
4. Секция USER-ARRAY.
5. Секция буферов ввода-вывода: TIB, блочные, файловые и проч.
Особенность - нельзя слова работы со стеком делать высокоуровневыми
[code]: DUP SP@ @ ; : PICK CELLS SP@ + @ ;[/code]
поскольку @ использует в качестве форт-адреса оффсет кодофайла, а не стека данных, а SP@ вообще теряет всякий смысл. Ну получили текущий оффсет вершины стека в егоном сегменте, а что с ним делать?
Ещё может быть организовать динамическое переключение между стеками данных и возвратов, чтобы использовать все пушки-попки и EBP для работы со стеком как с массивом (полезно при реализации PICK, OVER и проч.)
|
|
|
|
Добавлено: Вс окт 28, 2007 12:22 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными?
Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1.
А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния?
Плоская модель памяти не запрещает создавать в ней сегменты (или секции, кому как нравится).
Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).
Тогда такой вопрос: являются ли приложения, сваянные под спф-ом во всех отношениях полноценными?
Ведь другие компиляторы как раз разделяют коды и данные, да и в асме это рекомендация №1.
А разве окошки гарвардскую архитектуру не юзают? А как они тогда поддерживают многозадачность и защищают задачи от взаимовлияния?
Плоская модель памяти не запрещает создавать в ней сегменты (или секции, кому как нравится).
Для справок: сегментация впервые появилась в 8086 как средство увеличения физической памяти (16-разрядный адрес может обращаться только к 64 Кб памяти). Появление 386 привело к 32-разрядному адресу, а значит к возможности прямого обращения к 4 Гб (кто-нибудь видел комп с такой оперативкой?). Сегментация вроде бы и потеряла актуальность, но защищённый режим как разновидность многозадачного без неё не обходится. Да и замена адресов в программах на оффсеты позволяет размещать их в памяти где угодно (называется переносимость).
|
|
|
|
Добавлено: Вс окт 28, 2007 09:33 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
yug писал(а): To mOleg: Подробнее о реализации низкоуровневых слов
Спасибо за просвещение
[quote="yug"]To mOleg: Подробнее о реализации низкоуровневых слов[/quote]
Спасибо за просвещение ;)
|
|
|
|
Добавлено: Вс окт 28, 2007 04:45 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Вообще, разнести код и данные полезно во всех смыслах. И CREATE не создает проблем, и гарвардская архитектура более приятна. Если ориентироваться сразу на гарвардскую, то сэмулировать ее можно всегда.
Вообще, разнести код и данные полезно во всех смыслах. И CREATE не создает проблем, и гарвардская архитектура более приятна. Если ориентироваться сразу на гарвардскую, то сэмулировать ее можно всегда.
|
|
|
|
Добавлено: Сб окт 27, 2007 23:53 |
|
|
|
|
|
Заголовок сообщения: |
Re: Идеология компилятора и защищённый режим |
|
|
yug писал(а): Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями).
Эта идеология полностью игнорируется операционными системами, работающими на этих самых интел-процах. Все они предпочитают нормальную плоскую память. И слава богу.
[quote="yug"]Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями).[/quote]
Эта идеология полностью игнорируется операционными системами, работающими на этих самых интел-процах. Все они предпочитают нормальную плоскую память. И слава богу.
|
|
|
|
Добавлено: Сб окт 27, 2007 23:05 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Справка. Решение проблемы < CREATE ... DOES> ... > по Баранову (если кто не читал).
1. Слово DOES> в отличие от фига сделано IMMEDIATE.
2. Оно компилирует служебное слово (;CODE), которое при исполнении программирует поле кода дочернего слова.
3. После этого слова всегда подразумевается машинный код, он там и есть: CALL NEAR $DOES, его туда вгоняет DOES>, потому оно и IMMEDIATE. У Баранова там JSR, что то же самое.
4. Этот код работает не как вызов подпрограммы, а как JMP с загоном в стек данных адреса высокоуровневого обработчика - схема характерная для прямого шитого кода.
5. Дальше идёт высокоуровневый обработчик.
Справка. Решение проблемы < CREATE ... DOES> ... > по Баранову (если кто не читал).
1. Слово DOES> в отличие от фига сделано IMMEDIATE.
2. Оно компилирует служебное слово (;CODE), которое при исполнении программирует поле кода дочернего слова.
3. После этого слова всегда подразумевается машинный код, он там и есть: CALL NEAR $DOES, его туда вгоняет DOES>, потому оно и IMMEDIATE. У Баранова там JSR, что то же самое.
4. Этот код работает не как вызов подпрограммы, а как JMP с загоном в стек данных адреса высокоуровневого обработчика - схема характерная для прямого шитого кода.
5. Дальше идёт высокоуровневый обработчик.
|
|
|
|
Добавлено: Сб окт 27, 2007 12:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Для всех танкистов:
Проблема < CREATE ... DOES> ... > реально существует только для косвенного шитого кода (см. Баранов). Для подпрограммного и прямого кодов её нет.
Для всех танкистов:
Проблема < CREATE ... DOES> ... > реально существует только для косвенного шитого кода (см. Баранов). Для подпрограммного и прямого кодов её нет.
|
|
|
|
Добавлено: Сб окт 27, 2007 11:28 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
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> ... > платформеннонезависимым?
To mOleg:
Подробнее о реализации низкоуровневых слов под КШК можно узнать у Баранова или Семёнова (имею обе книги в бумаге). Сам принцип КШК состоит в двух разыменованиях кодовой ячейки в линейной последовательности кода. На саму ячейку указывает один из регистров проца, например SI/ESI, который как бы имитирует IP проца. При первом разыменовании получаем не сам код, а его адрес, т.е. шитый код - это последовательность cfa исполняемых слов (справедливо и для ПШК). После второго разыменования всегда имеем адрес машкода, его обычно выполняем командой JMP ячейка.
Всё это делает блок <Next> интерпретатора кода:
[code]LODSW MOV BX, AX JMP [BX][/code] (реализация фиг-форт 16-разрядов, дося (с) Ю.А. Семёнов "Программирование на языке форт"). ИМХО стандарт фиг-форт признаёт только КШК, хоть он и самый медленный. Зато платформонезависимый! Погнали дальше. Низкоуровневое слово - это обычный машинный код, в конце которого обязательно стоят вышеприведённые 3 команды NEXT. В соответствии с семантикой NEXT точка входа в него должна быть записана в ячейке с адресом cfa. А сам код обычно компилируется в поле параметров, т.е., начиная со СЛЕДУЮЩЕЙ ЯЧЕЙКИ. Для справок блок CALL входа в высокоуровневое слово (у Семёнова - $COL): [code]ADD BP, -2 ADD BX, 2 MOV [BP], SI MOV SI, BX NEXT[/code] Здесь BP - указатель стека возвратов, а BX - зарезервированный системой регистр для быстрого доступа к полям кода и параметров. И блок DOES (справедливо ТОЛЬКО для фиг-форта!) [code]SUB BP, 2 ADD BX, 2 MOV [BP], SI MOV SI, [BX] ADD BX, 2 PUSH BX NEXT[/code]
Делает то же самое, что и CALL, но дополнительно загоняет в стек данных pfa дочернего слова для последующей обработки высокоуровневым обработчиком. Слово <BUILDS создаёт в дочернем слове 2 поля кода, а слово DOES> их программирует: в первое заносит адрес своего обработчика (см. выше), а во второе - адрес входа в высокоуровневый исполнительный код материнского слова. Красиво, хоть и громоздковато, да и последующими стандартами отменено.
Меня интересует, можно ли сделать < CREATE ... DOES> ... > платформеннонезависимым?
|
|
|
|
Добавлено: Сб окт 27, 2007 10:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
эхехех.
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 не помню, да и не прижилось.
эхехех.
[quote="yug"]Идеология интел-процов, начиная с 8086 и кончая современными многоядерными 4-ми пеньками с гипертрейдингом базируется как известно на работе с сегментами (в защищённом режиме их называют также секциями). В то же время идеология форт-компилятора - это весьма вульгарно понятый принцип фон Неймана - "вали код и данные в общую кучу - там разберёмся". Противоречие, однако. И ещё один моментик. В защищённом режиме в секцию кода запрещено не только писать, но и читать оттуда иначе как через EIP/IP. Короче, каменюка сыграет исключение, и префикс CS: не прокатит, как в реальном.[/quote] вы не правы по той причине, что все (практически без исключений) форты работают с той моделью памяти, которую предлагает ОС (либо наиболее простую из моделей). Многосегментных форт-систем было много под досом, а вот под виндой это не удобно 8( с другой стороны, приведенная вами проблема достаточно просто обойдена в DSFORTH(который по мативам СПФа сделан). Да и вариантов разрешения проблем почти всегда несколько.
[quote="yug"]Вопрос: как при таких драконовских условиях форт-система может работать, причём и с сохранением традиционной "идеологии кучи"? Ведь она должна и компилировать новый код, и выполнять его.[/quote] не верно с идеалогией кучи. Не редко Форт-системы держат код, данные, имена в различных местах, просто сейчас времена виндов, и так получается проще. Впрочем и у линухов память "плоская".
[quote="yug"]Была такая задумка: спроектировать форт-систему специально под архитектуру Пентиума-4/Атлона с разделением ресурсов по сегментам. Но даст ли это какой-нибудь выигрыш?[/quote] скорее проигрыш по скорости и проигрыш в простоте.
[quote="yug"]Прямой шитый код уже не катит - в нём "идеология кучи" выражена сильнее всего. Косвенный шитый... О его независимости от платформы можно слагать легенды. Да и для разделения ресурсов он приспособлен как нельзя кстати: 1. машкод присутствует только в низкоуровневых словах; 2. в самой форт-системе он представлен всего одной ячейкой, правда используемой нерационально: она ссылается на следующую ячейку, с которой код и начинается.[/quote] про следующую ячейку не понял 8( поясните. есть еще более красивая, но пока не реализованная модель, которая позволяет безнаказанно тягать код по памяти:) один у нее недостаток - скорость низкая. про то, что создать "защищенную форт-систему" только с косвенным ШК я говорил все время, правда Михаил меня так и не понял 8( [quote="yug"]Но что мешает перенести этот самый код в другое место, не трогая ничего в высокоуровневых словах? Правда, есть одно "но", этакая ложечка дёгтя: структура < CREATE ... DOES> ... >. Её невозможно сделать традиционными форт-средствами без фокусов с машинным кодом. Есть древнее решение этой проблемы - фиговское < <BUILDS ... DOES> ... >, но оно было "при царе Горохе, когда людей было трохи" и сейчас не используется.[/quote]
утверждение не верно. Все можно. Только обычно проще сделать использовав трюк. Причем проще не потому, что проще, а потому что лень прикинуть несколько вариантов и выбрать лучший. В моем форке http://fforum.winglion.ru/viewtopic.php?t=531 DOES> высокоуровневый, например.
насчет builds не помню, да и не прижилось.
|
|
|
|
Добавлено: Сб окт 27, 2007 01:29 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
В защищенном режиме вполне можно делать разделение кода и данных. Для чтения/записи в сегмент кода существует такое понятие, как алиас сегмента, создаваемый стандартной функцией ДОС-экстендера. На практике это сегмент с теми же базовым адресом и лимитом, что и сегмент кода, но в котором установлены флаги, разрешающие чтение и запись. Так что никакого запрета на модифицировние сегмента кода на деле нет.
В защищенном режиме вполне можно делать разделение кода и данных. Для чтения/записи в сегмент кода существует такое понятие, как алиас сегмента, создаваемый стандартной функцией ДОС-экстендера. На практике это сегмент с теми же базовым адресом и лимитом, что и сегмент кода, но в котором установлены флаги, разрешающие чтение и запись. Так что никакого запрета на модифицировние сегмента кода на деле нет.
|
|
|
|
Добавлено: Пт окт 26, 2007 23:13 |
|
|
|
|