OSDev

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

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

_________________
Found a CPU. LAPIC ID: 00

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

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



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

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

Ну а в порядке флуда, единственно кошерная архитектура -- некий гибрид из System/360 + VAX-11 + ARM (естественно, заимствующий лучшие, а не худшие черты этих архитектур).

Есть 2 механизма сегментный и страничный.
В чем сходства и различия? Страничный механизм позволяет организовать сегменты также как и сегментный. Механизмы контроля доступа одинаковые биты у дескрипторов одинаковые. Так что говорить что страницы не защищают это бред.

1. Существенное отличие - это гранулярность. В страничном это одна страница в сегментном это байт. Это изменяет алгоритмы работы железа.
2. Второй это виртуализация. Страницы скрывают процесс преобразования адресов. И это огромный плюс.

Представить свопинг без страничного механизма вообще-то трудно.

Думаю идею микроконтроллер на плис можно развить неплохо.
http://marsohod.org/index.php/projects/66-makeavr

Ядро ОС на ПЛИС, а код на микроконтроллере.

Дальнейшее обсуждение и ответ на твой вопрос, 418ImATeapot, здесь viewtopic.php?p=3842#p3842.

Тут я пользуюсь терминологией Таненбаума. У которого написано (если я правильно помню)


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

_________________
Found a CPU. LAPIC ID: 00

На мой взгляд, сегментная модель памяти - зло, и я в свое время был очень рад, когда узнал, что AMD в своей 64-битной отпилили от x86 кучу мусора наросшего на нем за последние 20 лет, в том числе и сегментную модель. (Хотя на сколько я знаю ее не отпилили, но хотели. Причиной стали тоны кирпича доставленные в огород AMD программистами VmWare).

Поддержка сегментной модели ОЧЕНЬ сильно усложняет логику ядра ОС. Вывод из собственного опыта. Я как и товарищ, начавший эту ветку форума, в свое время пытался реанимировать/пересмотреть эту модель но пришел к тому же выводу, что и все остальные разработчики ОС. И да, сегментная модель печально скажется на производительности, так как при каждом переключении процессов/потоков вам нужно будет валидировать сегменты, перегружать LDTR и на основании нового значения LDTR перегружать сегментные регистры. В классической плоской модели, вам нужно перегружать сегментные регистры ТОЛЬКО при переходах ядро-программа и все, при переключении процессов/потоков на все эти сегменты кладется болт.

P.S.: А вы подумали как вы будете пиcать ядро и программы для вашей не плоской модели памяти? Если вы рассматриваете только ассемблер, то флаг вам в руки. Однако если вы предполагали использование какого бы то ни было компилятора, то можете забыть.