Comments 6
ведь мы все еще в 16 битном режиме процессора, который позволит нам написать максимум аналог DOS'а что почти никому уже и не нужно
С тем, что "почти никому [это] уже и не нужно", я соглашусь. А вот "максимум аналог DOS'а" -- это совершенно неверно. Известны многозадачные операционные системы, работавшие на машинах с объёмом памяти порядка 64 и даже меньше килобайт, без каких-либо средств защиты памяти. В частности, у DEC таким был двухзадачный FB-монитор системы RT-11, да и их самая развитая ОС RSX-11M (бабка Винды, между прочим) в минимальном варианте могла работать на моделях без MMU, располагавших 56 Кбайтами ОЗУ. Ранние варианты OS/360 могли работать в многозадачном режиме, имея 64 Кбайта памяти (позднее, по мере роста функционала системы, этот объём возрос формально до 128 Кбайт).
В общем, по сравнению с изрядной частью техники 1960-70-х годов, даже исходный IBM PC с гибкими дисками, имевший всего 32 Кбайта ОЗУ, был не такой уж слабой машинкой -- а ведь объём памяти быстро возрос до знаменитых 640 Кбайт, и уж там можно было разгуляться вволю. То, что ДОС оставалась крайне убогой системой, недалеко ушедшей от CP/M, не означает, что само железо ни на что большее не годилось
Изначально Intel дала целых 4 кольца защиты
Вообще, не изначально: стоило б в самом начале пояснить, что у 8086/8088 никакой защиты не было в принципе, а защита и преобразование адресов появились в 80286, где и были введены эти четыре кольца; именно тогда и придумали термин "реальный режим", чтоб обозначить единственный режим работы 8086, в котором для совместимости работал и 80286 сразу после сброса.
Вообще, несколько уровней защиты -- идея на тот момент не новая, её успела, например, DEC реализовать в VAX-11 (тоже четыре уровня) и даже в некоторых моделях PDP-11 (три уровня вместо более распространённых двух). На практике это, однако, оказалось (почти) бесполезным.
0xFFFF800000000000
Для удобства чтения лучше крупные числа разделять на группы разрядов, например: 0xFFFF'8000'0000'0000. Сей способ поддерживается и в некоторых языках программирования.
Кстати говоря, адрес не обязательно должен быть именно таким -- зависит от конкретной реализации, хотя подробности уже не помню (в AMD сидели извращенцы, придумавшие "канонические адреса" и прочие усложнения жизни вместо того, чтоб просто поддерживать полноценный 64-разрядный физический адрес, как это сделано, скажем, в мэйнфреймах z/Architecture, и иметь, тем самым, обычное линейное адресное пространство от нуля до физического максимума на данной модели).
Еще есть TLB (Translation Lookaside Buffer) — это кэш, служащий главным ускорителем всей памяти компьютера
Память он как раз вообще никак не ускоряет, что далее вполне корректно написано. Делиться, кстати, на отдельные кэши или TLB команд и данных они не обязаны -- это всё особенности конкретных реализаций, а не требования архитектуры.
Кстати говоря, информация про кэши в данном случае вообще излишня и лишь отвлекает внимание.
защита памяти как раз работает через отдельные CR3 на каждый процесс
Неточно: сам CR3 всего один на логический процессор, но его содержимое изменяется операционной системой при переключении между процессами.
В этой статье я не считаю нужным полностью рассматривать и MTRR, поэтому я решил оставить на следующие статьи, чтобы не раздувать текущий текст.
На самом деле, во вводной статье следует много что оставить за бортом, включая описание отдельных битов элементов таблиц переадресации и т.д.: читателю надо дать общую картину преобразования виртуального адреса в физический, а не грузить его сразу кучей интимных подробностей, из-за которых общая картина теряется.
На самом деле, вместо всего этого множества букв куда полезней был бы рисунок вроде вот этого:
Сей конкретный рисунок -- процесс преобразования адреса в Системе 370, которое принципиально выполняется точно так же, как преобразование адресов в любых современных процессорах с MMU, отличаясь лишь деталями (например, в Системе 370 -- всего два уровня таблиц переадресации -- таблицы сегментов и таблицы страниц, а не пять, как, скажем, в современной z/Architecture: 24-разрядный виртуальный адрес не требует для эффективной работы многих уровней, в отличие от 64-разрядного).
Детали, конечно, важны -- но лишь тогда, когда общее понимание уже сложилось.
спасибо, сейчас буду поправлять статью) вопросик небольшой — я картинки не встраивал, потому что боялся авторских прав, вообще на хабре как дела с этим обстоят?
Понятия не имею про авторские права, но, думаю, никаких проблем нет со скриншотами из официальной документации, если прямо писать, что это скриншот из официальной документации, а не приписывать авторство себе. Рисунок выше -- технически мой, из моего перевода "Принципов работы Системы 370", но он, понятно дело, нарисован псевдографикой "по образу и подобию" IBMовского оригинала.
На практике это, однако, оказалось (почти) бесполезным.
Да, из живых ОС дополнительными уровнями разве что Minix пользуется, да и тот у большинства бегает не на основном CPU. Правда, есть ещё отдельные режимы работы помимо этих 0-3 (как минимум для SMM и виртуализации), и они вполне востребованы.
Ну, и SMM, и виртуализация -- это другое™, речь о бесполезности именно колец защиты.
В действительности, польза могла бы быть в комбинации с использованием сегментов для реализации механизма множества адресных пространств и вызова программ, функционально аналогичного мэйнфреймам IBM (там это реализовано по-другому, отдельными механизмами, но это уже второй вопрос). Но для ПК польза от этого не очень-то велика (хотя можно было бы сделать, скажем, графическую подсистему не в ядре самой ОС, а на промежуточном уровне, и позволить через шлюзы вызывать её прямо из прикладных программ, а ей -- при необходимости обращаться прямо к адресным пространствам прикладных программ, не дёргая постоянно ОС, а значит, получив приличный выигрыш в скорости).
Написание ядра ОС с нуля. Ч2 — Анатомия памяти