Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А как бы ты сделал это расширение 64 К в 8080 до хотя бы 1 М при том, что регистры остаются 16-битными ? Можно, конечно, без этого странного сложения seg<<4 + ofs, но по существу все равно выйдет то же самое.
Я не про эту сегментную модель. Она как раз нормальна для данной ситуации. Но есть куча других аспектов.
В 8080 не было OF. В 8086 его добавили... в старший байт. При том, что в младшем было место, там и сейчас 3 бита тупо захардкожены в те же 100 что были в 8080. Кажется, мелочь? Уже тогда "стреляет" в виде издевательств, что из 8087 вытаскивается бит... в PF. LAHF/SAHF не работают с OF. В результате, отделить, что в Flags относится к condition, а что — к режиму, становится сильно сложнее. (Потом стреляет ещё и в ранней amd64.)
Изначально ненужные команды, но реализация которых — это чемодан набитый кирпичами без ручки. RCL/RCR со сдвигом более чем 1 бит — даже в ассемблере никто никогда не использовал. CMC — кому когда нужна?
8087: нафига стек регистров? Просто 4 регистра (никогда не использовалось больше) с прямой адресацией — помогло бы эффективнее и проще и изначально, и потом.
Ладно, это минимум. Дальше было хуже, см. ниже.
PD>Сам 8086 уродским не был, если учесть основную задачу (расширить АП сверх 64 Кбайт) и помнить, что делался он на 2-3 года. Не взяли бы его для IBM PC — о нем никто бы и не помнил сейчас, кроме историков PD>80186 — без серьезных изменений, да и не использовался. PD>А вот 80286 — да, уродство. Точнее, набор решений, которые оказались невостребованными (переключение LDT, переключение задач). Но уже было обязательным обеспечить хоть какую-то совместимость c 8086/88, так как нельзя было просто объявить все DOS-программы несуществующими и начать с нуля. PD>И Интел быстро исправилась. Плоская модель в 32-битном режиме 80386 — никакое не уродство.
Плоская модель сама по себе — да. А вот всё вокруг неё — нет.
Та же виртуальная память:
— Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать.
— Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству.
Далее, 32-битный режим:
— Почему префиксы 0x66, 0x67 явно декларирован с самого начала как NOP для байтовых доступов? Если бы сделали их reserved, не требовалось бы потом вводить REX для 64-битного.
— Они фактически изменили систему команд (декодер точно другой), значит, можно сделать многое иначе. В 1-байтовом наборе дохрена команд, которые редкие и которым не нужно быть такими короткими: как минимум IN[S], OUT[S], CMC, HLT, XLAT, CLI, STI, CLD, STD, ENTER, LEAVE, IRET, LAHF, SAHF, HLT, AAM, AAD... устал перечислять, но там примерно 60 кодов можно было высвободить. Почему это не сделано? Intel был в состоянии это сделать. Кстати, BCD helpers можно было убить уже тогда же из 32-битных (было сделано только для 64).
В результате мы сейчас имеем многобайтовые префиксы типа EVEX[2], всё короткое давно занято.
— Почему 32-битные версии регистров доступны по умолчанию? По-нормальному доступ к ним надо было явно вынести на флаг в CR0. Последствия кривого решения — проблемы с переключалками типа DESQview, если они не готовы к работе на 386, причём проблемы мистические, трудно идентифицируемые (пока все не оттоптались по этим грабелькам).
— Зачем SMSW, SGDT, etc. непривилегированные? Такое впечатление, что кто-то намеренно напакостил. Основы виртуализации были известны ещё 10 лет до того даже в том тупейшем варианте, который у Попек+Гольдберг (что для современной виртуализации как машина Тьюринга с её ленточкой).
Противоестественные реализации некоторых команд. Почему для BSF, BSR ставится ZF, против логики, что он должен ставиться по нулю _результата_, а не источника? Почему не сделать запись какого-нибудь -1 если источник — ноль?
CPUID надо было ввести ещё в 186 хотя бы в виде реализации как NOP (а потом добавлять реальные действия), если вообще началось развитие и различие версий.
Я уж не вспоминаю, что там уже явно были видны проблемы параллеления декодера, и сделать оформление длины команды в явном виде существенно бы облегчило работу. Но будем предполагать, что это бы они не потянули.
Я всё о таких вещах. Все они — нежелание подумать дальше полшага вперёд и сделать так, чтобы себе же было удобно не только в текущей версии, но и чуть-чуть позже... Но нет, "в своём гамаке я желаю полноценно трахаться на лыжах" (c). Фантастическое невежество и бескультурье там, где приложив чуть-чуть ума можно было получить значительно более качественный результат.
Здравствуйте, netch80, Вы писали:
N>В 8080 не было OF. В 8086 его добавили... в старший байт. При том, что в младшем было место, там и сейчас 3 бита тупо захардкожены в те же 100 что были в 8080. Кажется, мелочь? Уже тогда "стреляет" в виде издевательств, что из 8087 вытаскивается бит... в PF. LAHF/SAHF не работают с OF. В результате, отделить, что в Flags относится к condition, а что — к режиму, становится сильно сложнее. (Потом стреляет ещё и в ранней amd64.) N>Изначально ненужные команды, но реализация которых — это чемодан набитый кирпичами без ручки. RCL/RCR со сдвигом более чем 1 бит — даже в ассемблере никто никогда не использовал. CMC — кому когда нужна? N>8087: нафига стек регистров? Просто 4 регистра (никогда не использовалось больше) с прямой адресацией — помогло бы эффективнее и проще и изначально, и потом. N>Ладно, это минимум. Дальше было хуже, см. ниже.
Ну тут я могу еще кое-что добавить. BCD операции, например. Но тогда они казались нужными, да и, видимо, совместимость с 8080 требовалась.
N>Плоская модель сама по себе — да. А вот всё вокруг неё — нет. N>Та же виртуальная память: N>- Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать.
Потому что механизмы от 286 оказались ненужными. Фактически весь механизм защиты и адресации от 286 в 386 аннигилирован. Он остается, как же иначе, но по сути роли не играет, его программируют так, чтобы не мешал. А реально защита идет на страничном механизме.
Вспомни, зачем сделали 4 кольца. 0-е для ядра ОС, 1- для драйверов, так что их падение не приведет к падению ОС. 2- например, для DB engine. Ну и 3. И никто не стал в 286 процессоре это использовать. Равно как никто не стал использовать задачи процессора и переключение LDT. Идея оказалась невостребованной.
N>- Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству.
Это не понял. Что за форсирование маппинга ?
N>Далее, 32-битный режим: N>- Почему префиксы 0x66, 0x67 явно декларирован с самого начала как NOP для байтовых доступов? Если бы сделали их reserved, не требовалось бы потом вводить REX для 64-битного. N>- Они фактически изменили систему команд (декодер точно другой), значит, можно сделать многое иначе. В 1-байтовом наборе дохрена команд, которые редкие и которым не нужно быть такими короткими: как минимум IN[S], OUT[S], CMC, HLT, XLAT, CLI, STI, CLD, STD, ENTER, LEAVE, IRET, LAHF, SAHF, HLT, AAM, AAD... устал перечислять, но там примерно 60 кодов можно было высвободить. Почему это не сделано? Intel был в состоянии это сделать. Кстати, BCD helpers можно было убить уже тогда же из 32-битных (было сделано только для 64). N>В результате мы сейчас имеем многобайтовые префиксы типа EVEX[2], всё короткое давно занято. N>- Почему 32-битные версии регистров доступны по умолчанию? По-нормальному доступ к ним надо было явно вынести на флаг в CR0. Последствия кривого решения — проблемы с переключалками типа DESQview, если они не готовы к работе на 386, причём проблемы мистические, трудно идентифицируемые (пока все не оттоптались по этим грабелькам). N>- Зачем SMSW, SGDT, etc. непривилегированные? Такое впечатление, что кто-то намеренно напакостил. Основы виртуализации были известны ещё 10 лет до того даже в том тупейшем варианте, который у Попек+Гольдберг (что для современной виртуализации как машина Тьюринга с её ленточкой).
N>Противоестественные реализации некоторых команд. Почему для BSF, BSR ставится ZF, против логики, что он должен ставиться по нулю _результата_, а не источника? Почему не сделать запись какого-нибудь -1 если источник — ноль?
N>CPUID надо было ввести ещё в 186 хотя бы в виде реализации как NOP (а потом добавлять реальные действия), если вообще началось развитие и различие версий.
N>Я уж не вспоминаю, что там уже явно были видны проблемы параллеления декодера, и сделать оформление длины команды в явном виде существенно бы облегчило работу. Но будем предполагать, что это бы они не потянули.
N>Я всё о таких вещах. Все они — нежелание подумать дальше полшага вперёд и сделать так, чтобы себе же было удобно не только в текущей версии, но и чуть-чуть позже... Но нет, "в своём гамаке я желаю полноценно трахаться на лыжах" (c). Фантастическое невежество и бескультурье там, где приложив чуть-чуть ума можно было получить значительно более качественный результат.
Все, в общем, верно. Но в основном совместимость. Ну что прикажешь делать с теми же CLI/STI ? В 86 один код, а в 386 другой ? А SGDT вроде как еще от 286 пришла, и там был какой-то резон ее сделать непривилегированной. А может, и не было. Не подумали.
А в целом — типичное "развивающее" решение. Это когда не делают как следует с нуля, а делают с оглядкой на предыдущие решения. Конечно, многое можно было сделать лучше. Но сама архитектура отнюдь не плоха, а это все же мелочи.
С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну тут я могу еще кое-что добавить. BCD операции, например. Но тогда они казались нужными, да и, видимо, совместимость с 8080 требовалась.
Нет, ну для периода примерно до Pentium они ещё имели какой-то смысл. Потом уже оказалось, что делать то же самое на бинарке крупными порциями (хотя бы по 2-3 цифры) уже выгоднее.
N>>- Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать. PD>Потому что механизмы от 286 оказались ненужными. Фактически весь механизм защиты и адресации от 286 в 386 аннигилирован. Он остается, как же иначе, но по сути роли не играет, его программируют так, чтобы не мешал. А реально защита идет на страничном механизме. PD>Вспомни, зачем сделали 4 кольца. 0-е для ядра ОС, 1- для драйверов, так что их падение не приведет к падению ОС. 2- например, для DB engine. Ну и 3. И никто не стал в 286 процессоре это использовать. Равно как никто не стал использовать задачи процессора и переключение LDT. Идея оказалась невостребованной.
В 286 — по другой причине, что он сам был какой-то убогий и переходной — попытка фактически реанимировать iAPX432 поверх 8086.
А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
А сами Intel сделали SMM, который по их нумерации получается номер -1.
Ну так стоило ли так грубо и тупо вырезать? Что, одного бита в свободной области было жалко? Там до сих пор есть резерв.
N>>- Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству. PD>Это не понял. Что за форсирование маппинга ?
Всё просто. Если ты посмотришь на такую пачку архитектур, как MIPS, POWER, и даже SystemZ, то там можно (а в некоторых (было) обязательно), что в режиме супервизора маппинг (трансляция) виртуальных адресов в физические просто идемпотентна! То есть этот уровень работает в физических адресах. Ну просто нафиг ему не сдалось заниматься ещё и тем, что самому себе обеспечивать страничные каталоги, искать где их размещать и как правильно управлять, чтобы самому себе не вышибить почву из-под ног...
Если то, что называется Software-Managed Address Translation (гуглится, куча работ), то в этом случае все эти страничные каталоги и подкаталоги просто не существуют — это случай MIPS. Там супервизор командует напрямую кэшом трансляций (translation lookaside buffer (TLB) у большинства включая Intel). Но (у SystemZ) иерархия страничных каталогов в памяти, но супервизору трансляцию обычно отключают.
А у x86 эта трансляция если включена, то принудительно на всех. В результате получается куча костылей. Ты видел, как инициализируются современные ОС?
В одном из вариантов (очень долго был основным) сначала надо в нижнем мегабайте создать хотя бы один корневой каталог и один подкаталог 0 (первые 4MB в 32 битах). Именно там — потому, что до верхней памяти не добраться.
И они создаются с идемпотентной трансляцией.
Далее когда уже включили — можно сменить на другой каталог (а их надо делать для каждого процесса свой, если процесс не чисто ядерный).
Если надо перейти в реальный режим — тоже два этапа: сначала ужаться каталогами (а также GDT) в первый мегабайт, идемпотентно, и тогда отключать.
Сейчас больше используют unreal mode на 4GB и это не нужно в таком виде, больше свободы. Но чтобы переключиться потом в 64 бита, всё равно нужен ещё один прыжок режима.
И это я только про то, что видно процессору. А ещё надо структуры для самой ОС, где расписано, где она держит эти каталоги. И эти структуры тоже надо где-то держать. Если фиксированного места на них не хватает, задача становится ой нетривиальной — надо сделать так, чтобы собственные же структуры не затереть, не сдвинуть, если нельзя...
Пока писал, вспомнил ещё один момент. В Intel его тоже могли знать, потому что уже был VAX в полную силу доступен. Корневой каталог страниц свой на каждый процесс. Но если меняется маппинг для ядерной половины, его надо менять у всех процессов, на это есть особый контроль при переключении процесса. Что мешало сделать раздельные корневые каталоги хотя бы на две половины адресного пространства, и верхнюю не менять лишний раз? В VAX таких каталогов 4. В ARM сделали два каталога и управляемую границу между ними. Зачем x86 создал трудности на ровном месте?
PD>Все, в общем, верно. Но в основном совместимость. Ну что прикажешь делать с теми же CLI/STI ? В 86 один код, а в 386 другой ?
Нет. В 16-битном режиме (неважно, 8086, 386, Corei14...) один. В 32-битном (начиная с 386) другой. В 64-битном, возможно, третий.
Между ними и так существенная разница, и сделать различие в кодогенераторе и в декодере — только добавить к уже существующему.
PD> А SGDT вроде как еще от 286 пришла, и там был какой-то резон ее сделать непривилегированной. А может, и не было. Не подумали.
Я 101% уверен, что просто не подумали.
PD>А в целом — типичное "развивающее" решение. Это когда не делают как следует с нуля, а делают с оглядкой на предыдущие решения. Конечно, многое можно было сделать лучше. Но сама архитектура отнюдь не плоха, а это все же мелочи.
Ну _в общем и целом_, да, она не худшая. У неё достаточно гибкости, чтобы ещё конкурировать. Но при этом количество костылей, подпорок, ненужных и заброшенных частей ужасает.
PD>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
Здравствуйте, netch80, Вы писали:
N>А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
А они реально используются ? Драйверы там отделены от ОС ? Если нет — то для чего используются ?
N>А сами Intel сделали SMM, который по их нумерации получается номер -1.
Это да. Но это нельзя было реализовать в рамках Ring3-0, не получилось бы compatibility с 286.
N>Всё просто. Если ты посмотришь на такую пачку архитектур, как MIPS, POWER, и даже SystemZ, то там можно (а в некоторых (было) обязательно), что в режиме супервизора маппинг (трансляция) виртуальных адресов в физические просто идемпотентна! То есть этот уровень работает в физических адресах. Ну просто нафиг ему не сдалось заниматься ещё и тем, что самому себе обеспечивать страничные каталоги, искать где их размещать и как правильно управлять, чтобы самому себе не вышибить почву из-под ног...
N>Пока писал, вспомнил ещё один момент. В Intel его тоже могли знать, потому что уже был VAX в полную силу доступен. Корневой каталог страниц свой на каждый процесс. Но если меняется маппинг для ядерной половины, его надо менять у всех процессов, на это есть особый контроль при переключении процесса. Что мешало сделать раздельные корневые каталоги хотя бы на две половины адресного пространства, и верхнюю не менять лишний раз? В VAX таких каталогов 4. В ARM сделали два каталога и управляемую границу между ними. Зачем x86 создал трудности на ровном месте?
Все логично. Но это еще один регистр типа CR3. А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1. Более того, формально ее просто нет, совсем нет деления на 2 части. Так что пришлось бы по каждому адресу делать проверки, нужно ли его транслировать или нет, и если да, то через какой каталог. В общем, это некоторое усложнение, и , видимо, они решили сделать проще.
И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма. Никто не стал делать ОС в формате 16:32, но вообще-то ее сделать было можно, и не могла фирма не обеспечить это. Представь себе, что кто-то бы сделал ОС, в которой небольшие сегменты Ring0 лежат в 32-битном пространстве вперемежку с сегментами Ring3 — в общем, 32-битный вариант Windows 3.1...
Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
N>Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
Вот с этим объяснением не согласен. Itanium делали же Intel вместе с HP. В обеих компаниях топам захотелось ?
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
PD>А они реально используются ? Драйверы там отделены от ОС ?
Ты о ком именно?
VAX? Да, отделены.
ARM? У Apple — да, но другими механизмами (те драйверы, что отделены, фактически user level). А дополнительные уровни — на гипервизора (понятно, почему отдельно) и EL3 — это близко к SMM в x86: суперпривилегированный уровень, который знает аппаратные тонкости. Вообще из-за secure mode и реалмов их сравнивать напрямую не получится.
Но в итоге то, что "драйвер", может быть разделено между всеми уровнями.
PD>Все логично. Но это еще один регистр типа CR3.
Да.
PD> А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1.
Вот и зафиксировали бы хотя бы на 1:1.
PD> Более того, формально ее просто нет, совсем нет деления на 2 части. Так что пришлось бы по каждому адресу делать проверки, нужно ли его транслировать или нет, и если да, то через какой каталог. В общем, это некоторое усложнение, и , видимо, они решили сделать проще.
Скорее "быстро". Проще для железячников, да — ценой серьёзного усложнения для софта. Причём упрощение для железа небольшое, а вот усложнение для софта — серьёзное.
PD>И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма.
Нет, конечно. Страничный и сегментный механизм в 386 никак не связаны. Даже тот факт, что страничный не включается без защиты, это просто волюнтаристское решение. Его можно было спокойно включать без защищённого режима, и это тоже бы работало.
Где есть связь — это в IBMовских SystemZ и POWER. Там в обоих одинаково (понятно, почему) аналог селектора сегмента используется для выбора конкретного корня страничной трансляции (из до 2^16 вариантов, что перегиб — реально редко кто использует больше 2). Вот если бы Intel подумал в эту сторону — было бы интереснее. Но они сделали так, что уже в 386 вся эта сегментация стала использоваться только для указания левых параметров типа в какой битности мы сейчас будем работать.
PD> Никто не стал делать ОС в формате 16:32, но вообще-то ее сделать было можно, и не могла фирма не обеспечить это. Представь себе, что кто-то бы сделал ОС, в которой небольшие сегменты Ring0 лежат в 32-битном пространстве вперемежку с сегментами Ring3 — в общем, 32-битный вариант Windows 3.1...
Я не понял, что именно мне представлять. Это явно уже было: в случае запуска 16-битных приложений в 32-битной среде, как нативных Windows, так и в DOS-режиме. Но от этого, как известно, старались быстро уйти ("быстро" это 5-10 лет, со стандартной инерцией IT).
PD>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
Я тоже до такой степени не помню. Но вижу, что, например, 64-битный длинный режим нельзя включить в один заход: надо перейти сначала в 32 и потом переключаться флажком, который находится именно в CS (в его подробностях в GDT). А переключение в стиле loadall больше не делают.
Но интересно увидеть таки ссылку.
PD>>>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
N>>Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
PD>Вот с этим объяснением не согласен. Itanium делали же Intel вместе с HP. В обеих компаниях топам захотелось ?
Причины могли быть разные. HP — например, чтобы сохранить инвестиции в уже сделанные и кое-как работавшие наработки, и надежда на долгое плодотворное сотрудничество со вполне себе сделавшим имя успешным партнёром. А вот для Intel попытка рывка в неизведанное — призрачный шанс вполне мог застить очевидные соображения.
Здравствуйте, netch80, Вы писали:
PD>> А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1.
N>Вот и зафиксировали бы хотя бы на 1:1.
PD>>И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма.
N>Нет, конечно. Страничный и сегментный механизм в 386 никак не связаны. Даже тот факт, что страничный не включается без защиты, это просто волюнтаристское решение. Его можно было спокойно включать без защищённого режима, и это тоже бы работало.
N>Я не понял, что именно мне представлять. Это явно уже было: в случае запуска 16-битных приложений в 32-битной среде, как нативных Windows, так и в DOS-режиме. Но от этого, как известно, старались быстро уйти ("быстро" это 5-10 лет, со стандартной инерцией IT).
Соединил твои ответы, чтобы дать один свой
Страничный и сегментный механизмы связаны, и вот как
Адрес-то формально 48 битный, то есть 16:32. Другое дело, что реально 0:32, то есть flat model. Ну а если все же кто-то решил бы делать адресацию на 16:32 ? Не запретишь.
Вот смотри. Упоминаю CS, но может быть любой сегментный регистр. Для простоты считаю, что все они идут через LDT
CS1 base = 0, limit = 1 MB, ring 0
CS2 base = 1MB limit = 1 MB, ring 3
CS3 base = 2MB limit = 1 MB, ring 0
CS4 base = 3MB limit = 1 MB, ring 3
и т.д.
Могу я так запрограммировать LDT ? Имею право.
В итоге в линейном пространстве лежат куски по 1 MB . Права в страничном механизме — первый должен быть S, второй U, третий S, четвертый U и т.д.
А еще учти, что можно завести
CS5 base = 0, limit = 1 MB, ring 3
то есть тот же самый, что и CS1, но ring3.
Так что зафиксировать деление 32-битного на 2 части просто нельзя. Когда нет этого сегментного механизма — тогда мы изначально имеем дело с 32-битным пространством, в нем правило деления на части можно определить, а тут, увы...
PD>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
N>Я тоже до такой степени не помню. Но вижу, что, например, 64-битный длинный режим нельзя включить в один заход: надо перейти сначала в 32 и потом переключаться флажком, который находится именно в CS (в его подробностях в GDT). А переключение в стиле loadall больше не делают. N>Но интересно увидеть таки ссылку.
Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Соединил твои ответы, чтобы дать один свой PD>Страничный и сегментный механизмы связаны, и вот как PD>Адрес-то формально 48 битный, то есть 16:32. Другое дело, что реально 0:32, то есть flat model. Ну а если все же кто-то решил бы делать адресацию на 16:32 ? Не запретишь.
Да нету там адресации 16:32.
Было 2^14 (два бита ушли на RPL) сегментов умножить на 2^32 адресов, и тут же из них сделали один 32-битный "линейный", в котором вся информация о том, какой сегмент использовался, тупо выброшена. Всё, её нету. И уже из этих 32 бит линейного делают 32 бита физического независимо от того, какой сегмент это был.
Или даже если делается 36 бит физического (PSE36), то всё равно из 32 логических.
Или если page fault, то информация о сегментации потеряна, обработчик page fault тоже ничего не знает, из какого сегмента это пришло. Даже если бы он восстановил это разбирая команду, на которой фолт, то в TLB он не сможет ничего занести.
Поищи видео по словам "lost in mirror maze". Вот этот самый лабиринт зеркал — это максимум, что у тебя получится. До 2^14 отражений кусков одного и того же пространства.
Поэтому это просто красивый пшик...
Опять же, сравни с SystemZ — где сделано без потери данных. Есть address space number (ASN) — параметр: для юзерского приложения равен 1 — primary (для 99% обычных приложений только оно используется), 2 — secondary, >=3 — прочие. Есть методы (хоть местами странные) систематически ходить через другой ASN. У каждого ASN своё дерево страничных каталогов. И когда лукап отработан железом, то ASN выбирает, какой физический адрес страницы. А если ушло в обработчик (страницы нет, писать нельзя, и т.п.), обработчик получает напрямую, какой ASN был, и может в зависимости от этого подключить что ему угодно и как ему угодно, и в TLB эта информация сохраняется. Вот это уже действительно честное виртуальное 47-битное пространство (16:31) в S/370...S/390, и 80-битное (16:64) в z/Architecture (расширенная до 64).
(Почему 31, а не 32, позволялось для адреса — я не нашёл с ходу, потом надоело искать. По сути неважно.)
PD>CS1 base = 0, limit = 1 MB, ring 0 PD>CS2 base = 1MB limit = 1 MB, ring 3 PD>CS3 base = 2MB limit = 1 MB, ring 0 PD>CS4 base = 3MB limit = 1 MB, ring 3
[...]
PD>Так что зафиксировать деление 32-битного на 2 части просто нельзя.
Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит).
А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
И при наличии прав доступа через страницы такие же механизмы для не-кодовых сегментов вообще теряют смысл — поэтому в реальных ОС в long mode в DS/ES/SS грузится одно и то же значение — "всем всё можно". (Базовый адрес и длину там и так процессор игнорирует.)
PD> Когда нет этого сегментного механизма — тогда мы изначально имеем дело с 32-битным пространством, в нем правило деления на части можно определить, а тут, увы...
См. выше. При правах доступа по страницах, доступных в принципе (i386 и далее) или единственно оставшихся (amd64) — это уже бесполезно или недоступно. Ну а то, что сегментация показывает внутрь того же адресного пространства, и делает её бесполезной.
PD>>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
Меня в этом удивило именно то, что "с виртуальными машинами".
В этой архитектуре битность режима выполнения определяется тем, что загружено согласно селектору в CS — в соответствующем месте в памяти в слове было указание, 16 или 32. Ломать этот механизм совсем было бессмысленно. Поэтому на него же нагрузили включение 64-битного режима, и это выглядит достаточно оптимальным — в пределах уже сделанного извращения
А вот с виртуальными машинами важнее, думаю, только то, что раз в них исполняются системы любой древности (хоть PC-DOS 1.0), то должно было работать всё, что поддерживали предыдущие процессоры. Но это и так примерно очевидно.
Здравствуйте, netch80, Вы писали:
N>Поэтому это просто красивый пшик...
Ну не совсем. Да, в итоге будет 32 бита. Но limit в дескрипторе не отменен, и если он не 4Г, то нарвешься не на page fault, а на general protection fault. А так да, в итоге 4 Г, конечно
PD>>CS1 base = 0, limit = 1 MB, ring 0 PD>>CS2 base = 1MB limit = 1 MB, ring 3 PD>>CS3 base = 2MB limit = 1 MB, ring 0 PD>>CS4 base = 3MB limit = 1 MB, ring 3
N>[...]
PD>>Так что зафиксировать деление 32-битного на 2 части просто нельзя.
N>Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит).
Это если со старшим. А если сегменты как я нарисовал, то так не получится.
N>А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
Насчет доступа — согласен, а в остальном все остается. Лежат себе в 32-битном пространстве 1 Мб куски с правами S и U вперемежку. Почему лежат — а так LDT настроили. И не получится никакого разделения АП на U/S части. А запретить нельзя.
N>Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
Конечно, не использовалась. Но не могла фирма Intel не дать возможность ее использовать. Даже если понимала, что никому не понадобится — все равно обеспечить возможность должна была дать.
N>См. выше. При правах доступа по страницах, доступных в принципе (i386 и далее) или единственно оставшихся (amd64) — это уже бесполезно или недоступно. Ну а то, что сегментация показывает внутрь того же адресного пространства, и делает её бесполезной.
Бесполезно — да. А обеспечить работу были обязаны. А ну как все же кто-то решит использовать не flat, а как я написал.
PD>>>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>>Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
N>Меня в этом удивило именно то, что "с виртуальными машинами".
Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Поэтому это просто красивый пшик...
PD>Ну не совсем. Да, в итоге будет 32 бита. Но limit в дескрипторе не отменен, и если он не 4Г, то нарвешься не на page fault, а на general protection fault. А так да, в итоге 4 Г, конечно
Формально, GPF — это термин Windows, и распространяется он на оба случая. В процессоре есть разница между #GP (13) и #PF (14). Но это я уже придираюсь к терминам.
Но важнее тут именно то, что при наличии страничной защиты, и активном нежелании программистов бодаться со сложной структурой адресации (вместо одной плоской) — этот механизм тут же перестал использоваться, как только появилась первая возможность. В книгах по тому, как переходить с программирования под Win16 — под Win32, это было написано английским (или переведённым) по фоновому много раз.
N>>Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит). PD>Это если со старшим. А если сегменты как я нарисовал, то так не получится.
Так сегменты в таком виде немедленно перестали использовать. Кому оно такое нужно?
А схема "старшая половина — супервизору" — не знаю кто первый придумал, но в VAX она была закреплена в железе. (Точнее, там было просто 3 квадранта (один в резерве) и каждый под любое, и формально могли их переставить наоборот, но никто так не делал.) А вслед за ним это начали делать чуть менее чем все.
N>>А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
PD>Насчет доступа — согласен, а в остальном все остается. Лежат себе в 32-битном пространстве 1 Мб куски с правами S и U вперемежку. Почему лежат — а так LDT настроили. И не получится никакого разделения АП на U/S части. А запретить нельзя.
Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
Во многих версиях ОС, на самом деле, к супервизору относилась не только старшая половина, но и первые (индекс 0) 4MB. Потому что 1) было удобно идемпонентно отражать первый мегабайт, у которого спец. функции, 2) удобно делать это цельным подкаталогом, 3) NULL должен был давать исключение. Но потом от этого в основном ушли.
Так что, повторюсь, можно. И даже удобнее, если вдруг кому надо, это делать на страничном механизме, чем на сегментации. Но — в обоих никому не нужно. Вот сегментация и умерла.
N>>Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
PD>Конечно, не использовалась. Но не могла фирма Intel не дать возможность ее использовать. Даже если понимала, что никому не понадобится — все равно обеспечить возможность должна была дать.
Реально они могли отменить это не на 64 битах (как AMD позже), а уже на 32. Но на это им не хватило решительности.
N>>Меня в этом удивило именно то, что "с виртуальными машинами".
PD>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
Здравствуйте, netch80, Вы писали:
N>Так сегменты в таком виде немедленно перестали использовать. Кому оно такое нужно?
Да я разве спорю, что нужно ? Не в этом же вопрос. А в том, что коль уж сделали так, то пришлось обеспечить возможность такого, даже если и не нужно.
N>Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
Ну чередование — это просто мой пример. Можно еще 100500 других вариантов предложить. Суть-то простая — при наличии сегментного механизма и сегментов произвольного размера невозможно "в железе" зафиксировать правила деления АП на U и S. Вот им и пришлось делать одинаковые правила трансляции адресов по страничному механизму для U и для S
N>Так что, повторюсь, можно. И даже удобнее, если вдруг кому надо, это делать на страничном механизме, чем на сегментации. Но — в обоих никому не нужно. Вот сегментация и умерла.
Тут спорить я никак не могу.
PD>>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
N>Если найдёте откуда, прошу закинуть сюда.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
PD>Ну чередование — это просто мой пример. Можно еще 100500 других вариантов предложить. Суть-то простая — при наличии сегментного механизма и сегментов произвольного размера невозможно "в железе" зафиксировать правила деления АП на U и S. Вот им и пришлось делать одинаковые правила трансляции адресов по страничному механизму для U и для S
Ну это уже чистое "сгорел сарай, гори и хата". Если у старого механизма проблемы, то зачем усиливать от этого проблемы на новом?
Впрочем, вопрос риторический, и можно не продолжать эту тему.
PD>>>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями. N>>Если найдёте откуда, прошу закинуть сюда. PD>Если найду — обязательно. Но вряд ли найду.
Здравствуйте, rm2, Вы писали:
rm2>Рыночная капитализация на текущий момент в 2.7 раза меньше чем у аmd (82 vs 222). rm2>Идут активные слухи о разделении компании и продаже по частям.
Здравствуйте, rm2, Вы писали:
rm2>https://www.ixbt.com/news/2024/09/06/intel-50-qualcomm.html
rm2>Как то это прямо так скажем совсем не то что я лично хотел. Я бы хотел чтобы amd intel догнала, и дальше они в каком то разумном соотношении аля 50 на 50 конкурировали друг с другом.
