Здравствуйте, m2l, Вы писали:
m2l>Дальше заявляешь сомнительный тезис, что идеи в 80286 оказались не верны и развитие пошло по другому пути.... Модель многозадачности и виртуальной памяти до сих пор используется та что была в 286-м, да, её немного дополняли (когда допустим добавляли PAE или в 386, 486 дополнительными типами табличных записей),
И снова повторю (чтобы уже было в истории):
1. Страничная трансляция в 386 быстро стала основным механизмом работы ОС. Сегментация по-настоящему не используется.
2. В long mode сегментации вообще нет, сегментные регистры используются фактически с другой целью (задание некоторых параметров текущего режима). Вся нагрузка легла на страничную трансляцию.
Это не "немного дополняли", это полная замена логики.
Здравствуйте, VladD2, Вы писали:
VD>А Видовс 2000 оказался куда более глючным чем NT 3.1, так как в нем дрова видеократ перенесли в ядро и сделали поддержку Директ-3Д.
Неверно. GDI перенесли в ядро в NT4.0. И она стала "летать", в отличие от NT3.x
PD>Ну да. Но я ничего не знаю про ОС, в которых бы использовалась не flat модель, а полный 16:32
Кстати, и едва ли они были возможны, разве что в порядке эксперимента. Отказ от flat- модели означал бы, что указатель должен был бы быть 48-битным, то есть в виде пары 16:32. В 16-битной модели так и есть, только 16:16, со всем удовольствиями в виде huge указателей. Делать то же самое в 32-битной модели тогда не имело смысла — и так 4 Гб величина на тот момент запредельная. Ну а сейчас тем более не имеет смысла — улучшать таким образом 32-битную модель незачем, когда есть 64.
Здравствуйте, netch80, Вы писали:
N>(Хотя вот подумал — кто мешает держать их и в GDT?)
Мне в свое время показалось странным, что вообще Windows 3.11 использовала LDT. Коли уж нет задач в смысле TR/TSS и нет LDT под каждую задачу — зачем нужна LDT, почему не обойтись одной GDT ? Единственное объяснение — может, хотели в 2 раза увеличить объем доступной памяти ? Хотя одной GDT можно адресовать 2^13 * 64 кб, но все же надо помнить, что 64-Кбайтные сегменты отнюдь не были обязательны, там вполне могли быть сегменты малого размера, ну а тогда могло бы просто не хватить места в GDT.
Здравствуйте, netch80, Вы писали:
N>Itanium мог работать или поверх SRAM вместо DRAM (умножай ценник памяти на 10-20) или если бы оправдались прогнозы на RDRAM (который оказался пшиком от патентных мошенников), или если бы было качественное предсказание времени доступа, пусть даже с prefetchʼем (работает сейчас только для некоторых шаблонов потоковой обработки). RDRAM умер, SRAM не вошла в силу, потоковая мультимедия не стала >99% работ на процессоре. С DDR5 длительность максимальной задержки доступа DRAM только выросла. Шансов для EPIC как для архитектуры в сколь-нибудь массовом или серверном сегменте (где нужно много RAM) нет и будет не скоро. (Намёк на Эльбрус2000 с таким же EPIC.)
На практике никто не говорил, что они работать не могут. Крутились там часто SQL-сервера от MS и прочее. Считалось высокопроизводительным тогда, проработало емнип до 2010-го или 2011-го. Другое дело, что с середины — второй половины нулевых смысла не стало предпочитать эту платформу, системам на базе amd64 (Opteron и Xeon). Стоило дороже, совместимость хуже.
M>> Выйди он хотя бы в 1999-м — и скорее всего, amd64 не появился бы, а рынок был бы поделен на сегменты с IA-32 и IA-64.
N>Нет, рынок был бы перехвачен RISCʼами (POWER, MIPS, Alpha).
Что-то они не особо перехватили, MIPS сдулся, DEC кончился, его наследники Alpha сдули, частично она воплотилась в AMD-ных процессорах, и как-то все это произошло еще до amd64. Косвенно, может быть Alpha сдулась и из-за Itanium в том числе. Power не сдулся, но он занимал и занимает нишу мощных серверов/мейнфреймов от IBM.
M>> В принципе, Itanium совсем не плох оказался и в начале нулевых успел занять заметную долю на высокопроизводительных серверах и рабочих станциях.
N>1%? Или больше?
По-моему больше, впрочем не помню. Но в реальности встречал эти сервера.
N>Чистейшая легаси. Вон Fujitsu клепает SPARC для таких, и о чём это говорит?
Здравствуйте, netch80, Вы писали:
N>Но насчёт "недоступности" 16-битных операций неверно: какой-нибудь "add ax, bx" точно так же беспроблемно компилируется в 64-битном режиме.
Да, сейчас посмотрел, это я чего-то сейчас не то говорил, большинство 16-ти битных операций с регистрами доступны и в 64-битном режиме. Но не все, кстати.
N>"Пересечение по опкодам" это о чём вообще? Естественно, для 64 бит компилировать надо чуть иначе.
Префикс REX для 64-битных операций имеет опкод от 0x40h до 0x4fh, что пересекается со всеми вариантами INC и DEC над регистрами общего назначения.
Здравствуйте, Michael7, Вы писали:
N>>Но насчёт "недоступности" 16-битных операций неверно: какой-нибудь "add ax, bx" точно так же беспроблемно компилируется в 64-битном режиме. M>Да, сейчас посмотрел, это я чего-то сейчас не то говорил, большинство 16-ти битных операций с регистрами доступны и в 64-битном режиме. Но не все, кстати.
Таки не знаю, какие не все.
N>>"Пересечение по опкодам" это о чём вообще? Естественно, для 64 бит компилировать надо чуть иначе. M>Префикс REX для 64-битных операций имеет опкод от 0x40h до 0x4fh, что пересекается со всеми вариантами INC и DEC над регистрами общего назначения.
Так остались двухбайтовые варианты INC/DEC (кодируемые FE/0, FF/0). Они доступны в любых режимах.
(Ну да, чуть длиннее стали.)
Здравствуйте, netch80, Вы писали:
N>Я сомневаюсь, что 80186 стоило включать в этот список.
Были писюки и на 80186, довольно экзотичные но были.
А, вот, кстати, в вики глянул:
Процессоры семейства Intel 80186 практически не применялись в компьютерах, лишь некоторые фирмы выпустили такие ПК: Mindset, Compis (шведский школьный компьютер), RM Nimbus (британский школьный компьютер), Unisys ICON (канадский школьный компьютер), HP 200lx (handheld PC), и настольный ПК Tandy 2000.
Ну не помню точно весь список, кроме однобайтовых inc/dec еще кучку просто выбросили: двоично-десятичную арифметику, bound, into может еще что- то, lahf/sahf выкидывали в первых amd64 — потом вернули. Еще c jmp аккуратнее надо.
M>>Префикс REX для 64-битных операций имеет опкод от 0x40h до 0x4fh, что пересекается со всеми вариантами INC и DEC над регистрами общего назначения.
N>Так остались двухбайтовые варианты INC/DEC (кодируемые FE/0, FF/0). Они доступны в любых режимах. N>(Ну да, чуть длиннее стали.)
Длинее, да. В целом отличий достаточно, чтобы 16-ти битный код потребовал специальной перекомпиляции.
Но в общем, я уже говорю, что поторопился сказать про недоступные 16-ти битные операции, какое-то затмение нашло. Может потому что думал о том, что в 64-битном режиме в любых ОС невозможен запуск DOS-подсистемы и соответственно ms-dos софта, только эмуляция. Но это из-за отсутствия виртуального 8086-го, который был в ia-32.
Здравствуйте, Michael7, Вы писали:
M>Мог встречаться с ним, если видел модем USRobotics Courier — там унутре емнип как раз 80186 стоял
Сталкивался со Sportster. О Courier слышал много, но не вспомню сейчас, видел ли. У самого в конце 90-х был внутренний модем на 2400ю В начале нулевых — тоже внутренний, но уже на 56 Кб.
Вот такой Sportster у приятеля был. ЕМНИП, на 14400. Я на нем настройки перебирал, разные варианты строки инициализации испытывал.
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>>Itanium мог работать или поверх SRAM вместо DRAM (умножай ценник памяти на 10-20) или если бы оправдались прогнозы на RDRAM (который оказался пшиком от патентных мошенников), или если бы было качественное предсказание времени доступа, пусть даже с prefetchʼем (работает сейчас только для некоторых шаблонов потоковой обработки). RDRAM умер, SRAM не вошла в силу, потоковая мультимедия не стала >99% работ на процессоре. С DDR5 длительность максимальной задержки доступа DRAM только выросла. Шансов для EPIC как для архитектуры в сколь-нибудь массовом или серверном сегменте (где нужно много RAM) нет и будет не скоро. (Намёк на Эльбрус2000 с таким же EPIC.)
M>На практике никто не говорил, что они работать не могут.
Съел кусок текста при редактировании — имелось в виду конкурировать с нормальной эффективностью (хотя бы не медленнее x86 с аналогичными параметрами).
Просто работать он, конечно, мог. Иногда даже обгонял благодаря усиленным характеристикам, но это и стоило соответственно.
M>>> Выйди он хотя бы в 1999-м — и скорее всего, amd64 не появился бы, а рынок был бы поделен на сегменты с IA-32 и IA-64. N>>Нет, рынок был бы перехвачен RISCʼами (POWER, MIPS, Alpha). M>Что-то они не особо перехватили, MIPS сдулся, DEC кончился, его наследники Alpha сдули, частично она воплотилась в AMD-ных процессорах, и как-то все это произошло еще до amd64. Косвенно, может быть Alpha сдулась и из-за Itanium в том числе. Power не сдулся, но он занимал и занимает нишу мощных серверов/мейнфреймов от IBM.
Ну вот именно что конкуренция подбила. Я ещё ARM тут почему-то забыл.
Кстати, могли и M68k оживить. Мотороле в начале 90-х не хватило ресурсов сделать нормальный OoO (Intel и то смог его сделать только потому, что им перепал контракт на кластер Red), а если бы они на этом не сорвались, то у нас были бы хорошие шансы увидеть конкуренцию между двумя CISC.
M>>> В принципе, Itanium совсем не плох оказался и в начале нулевых успел занять заметную долю на высокопроизводительных серверах и рабочих станциях. N>>1%? Или больше? M>По-моему больше, впрочем не помню. Но в реальности встречал эти сервера.
Я тоже встречал. Но как-то очень быстро кончились...
N>>Чистейшая легаси. Вон Fujitsu клепает SPARC для таких, и о чём это говорит? M>Что они успели занять критично важные ниши.
Скорее что никто не хочет платить за переписывание на новые архитектуры...
(хм, местами уже исходников не осталось)
Здравствуйте, Michael7, Вы писали:
N>>Таки не знаю, какие не все.
M>Ну не помню точно весь список, кроме однобайтовых inc/dec еще кучку просто выбросили: двоично-десятичную арифметику, bound, into может еще что- то, lahf/sahf выкидывали в первых amd64 — потом вернули. Еще c jmp аккуратнее надо.
Ну в этом смысле да. Но это нельзя назвать 16-битными. bound, into универсальны.
aaa, das и прочие в этой группе — 8-битные. Завязки именно на 16 бит я нигде не вижу.
И вообще доля этих команд была ничтожной.
M>>>Префикс REX для 64-битных операций имеет опкод от 0x40h до 0x4fh, что пересекается со всеми вариантами INC и DEC над регистрами общего назначения.
N>>Так остались двухбайтовые варианты INC/DEC (кодируемые FE/0, FF/0). Они доступны в любых режимах. N>>(Ну да, чуть длиннее стали.)
M>Длинее, да. В целом отличий достаточно, чтобы 16-ти битный код потребовал специальной перекомпиляции.
В 16 битах все команды работают по-прежнему. А если компилировать в 64, то там других изменений достаточно, чтобы говорить о вообще другой системе команд.
M>Но в общем, я уже говорю, что поторопился сказать про недоступные 16-ти битные операции, какое-то затмение нашло. Может потому что думал о том, что в 64-битном режиме в любых ОС невозможен запуск DOS-подсистемы и соответственно ms-dos софта, только эмуляция. Но это из-за отсутствия виртуального 8086-го, который был в ia-32.
Это да. Но можно переключаться из long в legacy, в котором V86 есть. Дороговато, чуть дешевле входа в полную VM, но можно.
VD>Более того. 95-я была половинчатым решением точно так же без ДОСа не работала. Просто вместе 95-й в поставке шел ДОС 4.х. Можно было легко выйти из 95х и оказаться в ДОСе. Что мы и делали на слабых машинах для запуска ДУМа. Кстати, ДОС в 95х был хорош! Если бы 95 не был нужен ДОС, они бы могли тупо потереть всю память занятую ДОС. Память на дороге не валяется.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, iZEN, Вы писали:
iZEN>>Microsoft Windows Phone для своего времени была хороша
V>Так они просто слили виндофон намеренно отказавшись от бизнеса. Слили стриминговый сервис миксер. Неоднократно сливали магазин приложений для винды и многое другое. Но судя по последним новостям дела у них идут хорошо. Так что может им просто и не нужен мобильный бизнес. Это Вася Пупкин делавший программу для виндофонов разорится, когда они отправятся в помойку, а микрософту хоть бы хны.
Не знаю, кто точно слил, но на местах, когда пришли в магазин выбрать виндофон, продавцы всячески отговаривали от последних моделей смартфонов на Windows Phone. А это были идеальные аппараты с точки зрения юзабельности и количества поддерживаемых приложений/сервисов.
Спустя некоторое время (два-три года уже и сервисы начали отваливаться, Skype прекратили поддерживать для выпущенных смартфонов) и т.д.
сделайте уже полноценный рассказ со всеми нюсами и багфиксами
а то не очень люблю рассказы-лекции
в которых либо говорят — это мы пропустим, без подробностей
а вот -это позже расскажу,
и по итогу до конца рассказа так и не вспоминают больше
Здравствуйте, reversecode, Вы писали:
R>сделайте уже полноценный рассказ со всеми нюсами и багфиксами
Это к кому пожелание и о чем рассказ должен быть?
Здравствуйте, reversecode, Вы писали:
R>автору видео
Автор видео читает лекции студентам и это, по его словам, заключительная лекция курса. Тут как хочешь не удастся подробно рассказать.
А так по истории ВТ, даже персональной, уже нужна хорошая книга, а может и не одна. Кое что даже есть.