Здравствуйте, 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). Фантастическое невежество и бескультурье там, где приложив чуть-чуть ума можно было получить значительно более качественный результат.