OSDev

Смотрите. Есть сегментная (RM / PM), есть страничная (PM only) адресация. И всё. Я правильно понял?
Но и там, и там процессор для каждого mov [fourbytes2], EAX выполняет кучу (иногда абсолютно ненужных) преобразований.
А если у меня работает, например, только 1 процесс, использующий все 4 GB, никакого иного способа нет (без всяких адресных заморочек)?
Ведь жалко процессорный потенциал - съедается неимоверно, на самом деле. Или я не в курсах, и там внутрипроц.-ая оптимизация "сжимает" подобный mov до такта?

Все от архитектуры зависит. Полагаю, вопрос про x86.
Там есть кеширование, и кешируются как таблицы страниц, так и операции доступа по различным адресам. Зачастую процессор будет писать данные в кеш, а не в память, и только периодически "дампить", поскольку память есть внешнее устройство для самого процессора, и чтобы туда что-то отправить, уже действительно нужно относительно немало действий (как минимум, выставить адрес на шине + дождаться готовности памяти + отправить данные).
Если же рассматривать реальный режим, то преобразования через таблицы страниц отпадают и остается только присваивание в нужную ячейку памяти. Лишние преобразования сводятся к seg * 16 + reg. Не так уж и много, учитывая, что это по идеи можно сделать через одно обращение к АЛУ в виде небольшого костыля.
На других же архитектурах сегментов и страниц может и не быть. На том же AVR нет ни страниц, и сегментов: сиди и обращайся по любым адресам без всяких преобразований.
Некоторые из ARM-ов такие же, насколько я знаю.

Но в любом случае, операции с памятью всегда значительно медленней операций с регистрами, и с этим можно только смириться.

В RM и 32-битном PM сегменты не отключаемые, но можно не включать страницы. Зато в 64-битном PM сегментов просто нет, но страницы не отключаемые. Количество тактов команды mov в общем-то не зависит от режима адресации. Только в страничном режиме есть задержка при пересечении границ страниц. Но и страницу можно сделать размером 2МБ или даже 1ГБ, тогда получится почти сплошная адресация.

На самом-то деле для поддержки всего этого требуется приличное количество "железа", которое зачастую лежит мёртвым грузом. Все сколько-нибудь распространённые ОС защищённого режима под IA-32 не используют ни сегментацию, ни аппаратное переключение задач, ни несколько кругов защиты, ни ряд других аппаратных фишек (недаром при разработке 64-разрядного расширения архитектуры от всего этого отказались, и эти механизмы работают только в 16/32-разрядных режимах) -- а в процессоре-то всё это приходится поддерживать ради совместимости.

Что касается времени исполнения инструкций и влияния на него всех этих наворотов, то здесь вопрос очень непростой. Например, что вообще понимать под временем выполнения инструкции? Число тактов с момента, когда процессор "захотел" её выполнить, и до момента её фактического окончания? Ну так это время может составить в особо плохом случае несколько сотен, а то и тысяч тактов. Или же эффективное время исполнения инструкции в конкретном случае? Оно вполне может составить один такт, и даже более того: за один такт может быть выполнено несколько инструкций. В любом случае, в "тормозах" при выполнении указанные Вами механизмы почти не виноваты: они, конечно, добавляют некоторое время, но оно незначительно по сравнению с остальными затратами (составляют всего несколько процентов, которые к тому же в большинстве случаев благополучно "маскируются" в процессе реального выполнения).

страничная ещё в vm86 работает.
Нету так как есть наследство с которым и надо бороться страницами чтобы из разрозненных кусков собрать 4ГБ.

Не до такта, а до 3-х тактов. Это скорость работы с кэш памяти. Есть алгоритмы которые оптимизируют работу с учетом кэша.
В большинстве задач кэш отрабатывает, только в некоторых специфичных он не справляется и тогда страничная задержки могут быть существенными.

Всё ясно. Буду пока переваривать инфу.

Мне нужно обрабатывать десятки мегабайт видео-буферов - поэтому я так и пекусь за производительность. Архитектура x86, да.

В реальном режиме мне не доступно выше 1МБ. Поэтому "*16 + сдвиг" не прокатит. А в защищённом надо воротить этот дескрипторный изврат. Ну, допустим, для определённой страницы памяти хранится кэш. Но, во-первых, этот кэш должен тоже перепроверяется на изменение/не изменение для каждого обращения к памяти, пусть и по укороченному пути; а, во-вторых, переключение задач или смена сектора/страницы каждый раз его должна сбрасывать, если я правильно понял. Пусть это и не так часто происходит, но это тоже обидная потеря тактов. Тем более если учесть, что переключение задач, помноженное на сегментирование процессов - это не такое уж и маленькое число.

Говоря про mov, я имею в виду время, допустим, 1 миллиона mov-ов, идущих один за другим, разделённое на их количество, в пределах одного А) сегментированного, или Б) одним сегментом/страницей во всю RAM, процесса (пункт Б немного более предпочтительней, так как там планируется основная вычислительная нагрузка).

Нужен предельно быстый перебор массивов "двордов" с их обработкой в регистрах. Я правильно пониаю, что наиболее производительный вариант для 32бит будет минимальнейшее количество страниц, распределённых по всей памяти? То есть, всё-таки страничный вариант в таком случае будет работать быстрее, чем сегментный?

В идеале хотелось бы адресовать всё одним 32-разрядником. Почему нет такого режима? Это так странно...

Всё упирается в кэш и его эффективное использование, а не в механизм преобразования из виртуальных адресов в реальные. Последний будет сильно сказываться лишь в том случае, если подряд идущие доступы к памяти все выполняются по сильно разным виртуальным адресам (относящимся к разным страницам) и при этом таких разных доступов много. Дело тут в том, что сама информация, необходимая для работы страничного механизма, кэшируется процессором в специальной кэш-памяти -- TLB называется. Поэтому, выполнив один раз преобразование виртуального адреса для некоторой страницы, для чего требуется прочитать из памяти таблицы переадресации, процессор в дальнейшем выполняет преобразования других виртуальных адресов, относящихся к этой же странице, используя информацию из TLB, что многократно быстрей, поскольку не требует лишнего обращения к памяти. Естественно, ёмкость TLB ограничена, поэтому его можно переполнить, если постоянно адресовать совсем разные страницы. Для сегментов же подобного "ускорятора" не предусмотрено, поскольку сама сегментация реально не используется. Соответственно, при каждой перезагрузке сегментного регистра требуется выбрать его дескриптор из памяти, выполнить необходимые проверки и т.д., что медленно.

То же касается и обычного кэша данных. Он не резиновый, поэтому для обеспечения высокой производительности необходимо обрабатывать данные смежными группами, а не носиться по всей памяти сразу. Кроме того, есть специальные команды, обеспечивающие предварительную загрузку данных в кэш: если такая команда выдана достаточно рано, процессор может дальше обрабатывать данные, уже находящиеся в кэше, и параллельно загружать новую порцию.

Что же касается адресации, то она реально и выполняется одним 32-разрядным адресом. Загружаете сегментные регистры постоянными значениями -- и вперёд. Все ОС защищённого режима именно так и делают.

panotnap
Прежде временная оптимизация вредит разработки. А именно это и наблюдается у вас.

Суммарное время переключение процессов это 0.001 от вычислительной мощности компьютера. Так что число это маленькое. И пока оно не будет хотя бы 0.1 задумываться даже не стоит.
А вот мултипроцесность и защищенность гораздо важнее. А то будет как с win98 на которой нормально работать нельзя было, так как она раз в пару часов падала. Из за ошибок в прикладном ПО.


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



Ничего странного. В старые времена. В ПК было предусмотренно наличие дополнительных плат - карты расширения PCI. Так вот в каждой плате может быть своя память. Куда её деть? Поэтому 4ГБ поделили поровну половину отдали под основную память, половину для карт расширения 2ГБ.
А если вспомнить ещё раньше, то там были EISA карты. И там деление было 15 МБ основной памяти 1 МБ резервной.
А ещё раньше ОЗУ было меньше, всего 32Кб. И под ISA расширения отводилось 4*64 кБ и 10*64 под основную память.
Плюс БИОСу тоже нужна ОЗУ, так что он тоже откусывает кусочек от основной памяти - причем в самом неожиданном месте(местах).

panotnap
Забыл спросить.

А почему не делаете на видеокарте, как все современные программы? Там канал между процессором и памятью шире. Чем между ЦП и основной памятью.

Не представляю себе, как это сделать из самопальной ОСи. Было бы, конечно, здорово использовать видеопамять карты... Но максимум, на что я пока расчитываю - это ВЕЗА. Я её ещё не щупал на практике, но там вроде таких возможностей не предоставляется - только отображение в монитор. Ещё висит вопрос с широкоформатными разрешениями, которых бы очень хотелось установить, но которых в VBE нет и не предвидется.