Пространства адресов

l_inc

Это я говорю исключительно о сегментах. Страницы и механизм поддержки "Виртуальной памяти" пока отдыхают. Речь идет о максимальном размере данных, которые может адресовать программа, пользуясь своими сегментами (не в Windows). И давайте разделять - защищенный режим с сегментами и тот же защищенный режим, но еще и со страницами.

Нет не бред! Команды ветвления - это те, в результате которых изменяется значение регистра eip. Это и call и jmp и условые переходы и ret, retn, ret <число>.

Вот это - бред... частичный. Если в команде записан относительный адрес - то да. Если абсолютный - то от начала сегмента кода. Речь шла об абсолютных адресах.

Боже ж ты мой... Посмотри на клавиатуру - 'к' там рядом с 'о'. Это опечатка - можно было и догадаться! Или ты просто внаглую смеешься над опечатками? Это не стекло, а стек. За опечатку - спасибо, я за издевательства - ГНУ!

Опять речь идет только о сегментах. Про гранулярность я знаю. А вот про то, что максимальный адрес относительно начала сегмента, по которому можно обратится в АП сегмента - равен размеру этого сегмента - этого наверное ты не знаешь!

Опять идет чистое терминологическое припирательство. И все потому что "мне лень читать дальше". Нет лучше уж прочитать все! Прочитай и ты - поймешь - где ошибка, где я написал недостаточно информации, а где - уже твои глюки (все же ночь на дворе).

 

Дайте замечания к "Материалу"!

 

AndreyMust19

Сегменты к виртуальной памяти отношения не имеют.

Бред. Во-первых, значение eip меняется в результате исполнения любой инструкции. Инструкции, способные изменить eip на значение, не равное своей длине называются командами передачи управления, а не "ветвления".

Бред. Инструкция условного перехода не может содержать абсолютный адрес. Если инструкция передачи управления содержит абсолютный адрес, то она также содержит селектор сегмента, не зависящий от содержимого cs.

Больше не отвечаю. Я не способен корректировать бред, выдаваемый с такой скоростью и в таких количествах.

 

Какие нафиг замечания?
Если у тебя call и ret это команды ветвления, то дальше читать как-то не тянет.
Это команды передачи управления, но никак не ветвления.
Даже jmp - это не ветвление.
Ты себе ветку представняеш вообще? Хотя-бы обычного дерева (того что в лесу растёт ).

Код (Text):

1.                                 /----
2.                                /
3. Вот это ветка  --------------<
4.                                \
5.                                 \----
6.  
7. А вот это нет  ----------------------

Так вот ветвление - это исключительно условные переходы.

 

l_inc и

cppasm

Вот! Точно! Это бред! А я думаю - как эти команды назвать? Которые

Короче все те, которые изменяют обычный ход программы. Команды передачи управления, а не ветвления! Спасибо за ценное замечание.
Так что насчет 243 и 244 постов - согласен - бред!!! Бегу исправлять (я же говорил что ночь на дворе, а думать ночью - нельзя). Все замечания в 243 - насчет условных ветвлений, а не операций передачи управления, о которых я речь веду!

Ложусь спать!!! Завтра (не устром, я завтра) со свежей головой буду писать (а то похоже у менять столько опечаток, что ни один пост не обходится без комментариев).

 

Вспомнил что уже читал этот расчёт на 64Террабайт, как раз в эпоху P1 вместе с аналогичной "байкой" про то что 286 может адресовать 2Гб ) Тогда вынес из него два впечатления:
Первое впечатление - неправильное - похожее на картинки AndreyMust19, и только потом разобрался что на самом деле это не так )
AndreyMust19 перечитай #228

Второе впечатление - недоумение - почему 8k + 8k десктрипторов, а не 8k * 8k (вся глобальная таблица заполнена дескрипторами локальных таблиц)? (AndreyMust19 обрати внимание сегментов не 6, а 8k + 8k или 8k * 8k или ещё больше если завести несколько глобальных таблиц, но несколько глобальных таблиц это уже как бы программное расширение

И только теперь (спасибо defaultplayer за поднятую тему) понял - как раз во время первых пеньков стало очевидным, что память больше 4Гб в обозримом будущем станет реальностью, а затем и повседневностью, потому и возник вопрос - а годится ли для этого случая IA-32? или пора уже сейчас думать об альтернативах к ней?
Вот на этот вопрос Интел и ответила таким "изящным" ходом - размер памяти адресуемый 8k * 8k дескрипторов, а тем более несколькими глобальными таблицами слишком огромен, чтобы помещать его в рекламу архитектуры - нормальный человек просто не воспримет это число , а 64Террабайт как раз впечатляюще огромно, психологически приемлемо и легко подтверждается простым "рассчётом": 8k + 8k дескрипторов 4Гб сегментов Отсюда и родилось это фантастическое АП, которого на самом деле нет и никогда не было . Хотя если бы разрешили каждому сегменту иметь (или не иметь) собственные страницы памяти, то и проблем с совместимостью бы не возникло и это АП стало бы реальностью, но не стало и значит уже не станет

 

Y_Mur
Собственно, задача (процесс) может иметь адресное пространство очень большого объёма, однако в каждый момент времени сможет обращаться лишь к ограниченному объёму. В случае 32-разрядного защищённого режима (а говорим, в общем-то, о нём) главным ограничителем выступает линейный адрес, имеющий длину 32 бита. С помощью ОС можно обеспечить задаче свыше 4 Гбайт адресного пространства, но для этого нужно ввести функции, переотображающие части линейных адресов на другие физические путём изменений в таблицах страниц. На практике такие системы встречались не так уж и редко, но на ИА-32 ничего подобного не видел: вероятно, из-за того, что расширять 4 Гбайта особого смысла не было, ведь подобными извращениями занимались на машинах с совсем коротким виртуальным адресом (обычно 16 бит).

 

SII

Пример применения функций AllocateUserPhysicalPages \ MapUserPhysicalPages есть у Рихтера и где-то мне попадалась статейка как раз про расширение пространства адресов под win32 с использованием "окна памяти" в которое отображаются разные физические страницы из доступных 64Гб (под ДОС то этот приём был самым обычным делом), значит кому-то это всё таки нужно
Сам тоже ни разу не пробовал, и физической памяти у меня сейчас 1Гиг

 

Y_Mur
Ну, сам механизм предусмотрели на всякий случай, а пользуется ли кто-то реально -- фиг знает. Про эти функции, если честно, благополучно забыл, почему и говорил, что под ИА-32 не видел Может, этим пользуются мощные СУБД типа Оракла на компах с памятью более 4 Гбайт, но с такими монстрами дела иметь не приходилось.

 

А нет вру - пробовал расширять АП создавая окно через FileMapping чисто для проверки таковой возможности, но если бы довелось реально работать с такой памятью, то предпочёл бы запустить несколько процессов имхо их синхронизация проще и удобнее чем эта возня с окном да и многоядерность в этом случае задействуется автоматически

 

Y_Mur
Подобный изврат может пригодиться, например, для хранения крупных индексов целиком в ОЗУ. Всяко быстрее переключать адресное окно, чем подгружать данные с диска.

 

наткнулся на такую академическую программу от майкрософт, как и windows research kernel, называется она Curriculum Resource Kit, представляет собой сбор материалов поясняющих концепции на которых основаны винХП и 2003 сервер. выкачать архив можно отсюда http://www.microsoft.com/resources/sharedsource/windowsacademic/curriculumresourcekit.mspx
39 метров. Кого действительно интересует, что представляет из себя виртуальный адрес виндоус, то в каталоге UnitOS5 есть презентация 5.3_WinAddrTranslation.ppt, в ней смотреть страницы 15-17.

 

defaultplayer
А выдернуть их отдельно? а то интересно что пишет M$, но не на столько чтобы качать 39 метров

 

пожалуйста

 

Ну вот вопрос и решился. И скорее надо смотреть 14-17, т.к. решающая фраза находится на 14-м слайде.
Причём даже несмотря на первую фразу на четвёртом слайде.

 

l_inc

да, именно, хотел подправить, но вы опередели, да и я думаю кто захочет тот все почитает
l_inc

SII

я вот говорил что майкрософт смещение в сегменте называет segment-relative address а интел offset, но все мы забыли расшифровку инструкции LEA, которая и дает ответ на то, как интел называет смещение. Так вот логическое АП - это множество эффективных адресов в сегментах, я думаю если так сказать это небудет ошибкой.

 

а какнибуть в Gif -анимайшен можно перевести сей богомерзкий формат (как впрочем многие форматы от мсявок)? а то смотреть нечем...

 

l_inc
defaultplayer
Ну что ж, в этой презентации на стр. 14 действительно написано, что виртуальный адрес Винды -- это линейный адрес Интел. С чем вас и поздравляю. Но в таком случае не забудьте заметить, что Майкрософт в МСДН неоднократно врёт, заявляя, что в функции передаётся виртуальный адрес. Он туда передаваться не может по, надеюсь, совершенно понятным причинам.

В общем, моё мнение: у Майкрософт бардак с терминологией. Вызван он, скорей всего, полной непроработанностью этого вопроса изначально вкупе со стремлением к кроссплатформенности, из-за чего в документации для пользователей избегали давать сколько-нибудь привязанные к железу определения.

Пы.Сы. А вот, например, фраза из даташита от АМДшны процов:

Как видим, АМД называет виртуальными 48-разрядные величины -- по всей вероятности, то, что в интеловских талмудах называется логическими.

Так что любая документация -- вещь очччень относительная...