Comments 165
Да, в первых BIOS была опция с А20. Недокументированные возможности DOS использовали в TSR программах.
Про достаточность 640К ляпнул Билли, ему это периодически напоминают в новых изданиях популярной книги по администрированию UNIX
В те времена, когда он это ляпнул, 640К это был астрономически огромный кусок памяти.
Дело даже не в этом, классический пример создания мифов и выдёргивания из контекста. Слова сказанные на компьютерной выставке в 1981 касались сравнения с текущими конкурентами. Как если бы сейчас выпустили бы домашний компьютер с терабайтом памяти (у спецсерверов такое есть уже сегодня). Было бы совершено логично сказать, что с таким компьютером вы не испытаете нехватку памяти ни с одной программой. Но народ внезапно решил неявно дополнить это утверждение словами «на все времена», что разумеется не может быть точным.
С учетом того, что он этого не говорил, но все это ему приписывают.
Можно где то почитать про DOS-777 или хотя бы пару фактов о существовании?
Ну и на тему A20 у вас странные выводы.
Так как мне лень я тут цитаты кину
```В реальном режиме по адресации памяти декларируется полная совместимость с процессором 8086, который своей 20-битной адресной шиной охватывает пространство физической памяти в 1 Мбайт. На самом деле, на радость разработчикам программного обеспечения PC, 80286 имеет ошибку, «узаконенную» и в следующих поколениях процессоров. При вычислении физического адреса возможно возникновение переполнения, которое с 20-битной шиной адреса просто игнорируется. Если, например, Seg=FFFFh и EA=FFFFh, физический адрес, вычисленный по формуле РА=16 х Seg + EA=10FFEF, процессором 8086 трактуется как 0FFEF — адрес, принадлежащий первому мегабайту. Однако на выходе А20 процессора 80286 в этом случае установится единичное значение, что соответствует адресу ячейки из второго мегабайта физической памяти. Для обеспечения полной программной совместимости с 8086 в схему PC был введен специальный вентиль Gate A20, принудительно обнуляющий бит А20 системной шины адреса. Не оценив потенциальной выгоды от этой ошибки, управление вентилем узаконили через программно-управляемый бит контроллера клавиатуры 8042. Когда оперативная память подешевела, а «аппетит» программного обеспечения вырос, в эту небольшую область (64К-16 байт) стали помещать некоторые резидентные программы или даже часть операционной системы, а для ускорения управления вентилем появились более быстрые способы (Gate A20 Fast Control)```
```Intel разработал переход между режимами только в одном направлении. Микропроцессор начинал работу только в реальном режиме, когда происходило тестирование всех 16 Мб памяти, но для использования всего этого ресурса необходимо было перейти в защищенный режим. Иначе пользователь мог довольствоваться только 1 Мб памяти. Обратного перехода от защищенного режима к реальному не существует — требуется перезагрузка. Кроме того, защищенный режим реализовывал только частично чаяния программистов. Вся огромная память 80286 была разделена на сегменты по 64 К. Вместо того, чтобы свободно использовать весь ресурс памяти, программистам приходилось мудрствовать, чтобы преодолеть эти барьеры между сегментами.```
а софта написали не то, что много — а дохрена как много.
```В итоге это означало, что появление 32-разрядных процессоров не вызвало заметных изменений по данной теме, поскольку специальный вход процессоров (A20M — A20 Mask) остался. Упомянутый вход современного процессора есть не что иное, как маскирование бита A20 физического адреса для эмуляции адресного пространства 8086 в реальном режиме работы процессора. А это связано и с тем, адресная линия A20 используется также для переключения из реального режима в защищенный.```
P.S. А в 64 битных, для обратный совместимости появился Long Mode :)
Можно где то почитать про DOS-777 или хотя бы пару фактов о существовании?
Ну и на тему A20 у вас странные выводы.
Так как мне лень я тут цитаты кину
```В реальном режиме по адресации памяти декларируется полная совместимость с процессором 8086, который своей 20-битной адресной шиной охватывает пространство физической памяти в 1 Мбайт. На самом деле, на радость разработчикам программного обеспечения PC, 80286 имеет ошибку, «узаконенную» и в следующих поколениях процессоров. При вычислении физического адреса возможно возникновение переполнения, которое с 20-битной шиной адреса просто игнорируется. Если, например, Seg=FFFFh и EA=FFFFh, физический адрес, вычисленный по формуле РА=16 х Seg + EA=10FFEF, процессором 8086 трактуется как 0FFEF — адрес, принадлежащий первому мегабайту. Однако на выходе А20 процессора 80286 в этом случае установится единичное значение, что соответствует адресу ячейки из второго мегабайта физической памяти. Для обеспечения полной программной совместимости с 8086 в схему PC был введен специальный вентиль Gate A20, принудительно обнуляющий бит А20 системной шины адреса. Не оценив потенциальной выгоды от этой ошибки, управление вентилем узаконили через программно-управляемый бит контроллера клавиатуры 8042. Когда оперативная память подешевела, а «аппетит» программного обеспечения вырос, в эту небольшую область (64К-16 байт) стали помещать некоторые резидентные программы или даже часть операционной системы, а для ускорения управления вентилем появились более быстрые способы (Gate A20 Fast Control)```
```Intel разработал переход между режимами только в одном направлении. Микропроцессор начинал работу только в реальном режиме, когда происходило тестирование всех 16 Мб памяти, но для использования всего этого ресурса необходимо было перейти в защищенный режим. Иначе пользователь мог довольствоваться только 1 Мб памяти. Обратного перехода от защищенного режима к реальному не существует — требуется перезагрузка. Кроме того, защищенный режим реализовывал только частично чаяния программистов. Вся огромная память 80286 была разделена на сегменты по 64 К. Вместо того, чтобы свободно использовать весь ресурс памяти, программистам приходилось мудрствовать, чтобы преодолеть эти барьеры между сегментами.```
а софта написали не то, что много — а дохрена как много.
```В итоге это означало, что появление 32-разрядных процессоров не вызвало заметных изменений по данной теме, поскольку специальный вход процессоров (A20M — A20 Mask) остался. Упомянутый вход современного процессора есть не что иное, как маскирование бита A20 физического адреса для эмуляции адресного пространства 8086 в реальном режиме работы процессора. А это связано и с тем, адресная линия A20 используется также для переключения из реального режима в защищенный.```
P.S. А в 64 битных, для обратный совместимости появился Long Mode :)
Можно где то почитать про DOS-777 или хотя бы пару фактов о существовании?
Ну, не знаю. А данная заметка не годится в факты о существовании? В ДОС 6.21 вручную было поправлено несколько мест, чтобы никто не трогал эту вонючую А20.
Цитат я тоже могу накидать. Замечу, что
Обратного перехода от защищенного режима к реальному не существует — требуется перезагрузка.-это только для 286, который промелькнул и исчез. Начиная с 386 такой проблемы нет, можно ходить туда-сюда.
МС поступила логично, начав городить новые ОС уже в защищенном режиме, хотя можно было ДОС перевести в 32-х разрядный реальный режим и нормально работать.
С 1995 по почти 2004 мы и работали под ДОС в 32 разрядах безо всяких DMPI и прочих ужасов. Это особенно удобно, если на компьютере бесконечно работает только одна программа, тогда ДОС является лишь загрузчиком, не сжирающим память как Windows.
Ограничение было на размер кода (но не данных) — не более 16 Мбайт. Я и сейчас на такие объемы кода не выхожу.
Могильщиком этого режима стали флешки. С ними под ДОС трудно работать.
```Ну, не знаю. А данная заметка не годится в факты о существовании? В ДОС 6.21 вручную было поправлено несколько мест, чтобы никто не трогал эту вонючую А20.
Цитат я тоже могу накидать. Замечу, что```
нет конечно.
Что значит не трогал A20?
Системе вообще на это насрать по большому счету.
в himem можно принудительно указать как работать.
```это только для 286, который промелькнул и исчез```
именно, так как костыли говно и палка начались с него
```
```аботали под ДОС в 32 разрядах безо всяких DMPI ```
и как вы трансляцию памяти делали?
И нормально не получалось, так как за спиной легоси которые надо тянуть, коотрое в общем и сейчас есть и intel обещал все это в 2020/21 выкидывать, но воз и ныне там.
```Ограничение было на размер кода (но не данных) — не более 16 Мбайт. ```
на 80286 вы можете работать с 1 гигабайтом, собственно так сервера и жили, основанные на этой платформе.
```Могильщиком этого режима стали флешки. С ними под ДОС трудно работать.```
Не вижу трудностей работы и сейчас. Хотя, что вы думаете под режимом работы, остается загадкой.
Цитат я тоже могу накидать. Замечу, что```
нет конечно.
Что значит не трогал A20?
Системе вообще на это насрать по большому счету.
в himem можно принудительно указать как работать.
```это только для 286, который промелькнул и исчез```
именно, так как костыли говно и палка начались с него
```
```аботали под ДОС в 32 разрядах безо всяких DMPI ```
и как вы трансляцию памяти делали?
И нормально не получалось, так как за спиной легоси которые надо тянуть, коотрое в общем и сейчас есть и intel обещал все это в 2020/21 выкидывать, но воз и ныне там.
```Ограничение было на размер кода (но не данных) — не более 16 Мбайт. ```
на 80286 вы можете работать с 1 гигабайтом, собственно так сервера и жили, основанные на этой платформе.
```Могильщиком этого режима стали флешки. С ними под ДОС трудно работать.```
Не вижу трудностей работы и сейчас. Хотя, что вы думаете под режимом работы, остается загадкой.
На тот же момент и вправду хватало. Однако язык ему тогда лучше бы и вправду было за зубами придержать)
Не существует хоть какого-нибудь пруфа что он вообще это говорил.
Главная проблема цитат в Интернете в том, что люди сразу верят в их подлинность.
— В. И. Ленин.
Да не ляпал это никогда «Билли», сто раз уже опровергали.
Это беда и боль проприетарного ПО.
В 2008 году в Москву приезжал Эндрю Мортон — один из ведущих разработчиков ядра линукс. Я задал ему вопрос относительно скандальной (в тот момент) истории с очередным изменением API стека USB в ядре, из-за которой пришлось править все без исключения драйвера устройств, которые были хоть кому-то нужны.
Он объяснил это словом «эволюция». Эволюция — это не только выживание самых приспособленных, это ещё и отмирание неудачных и/или ненужных. По его словам, в ядре Windows в тот момент было четыре разных реализации usb api, и разработчики операционной системы вынуждены были поддерживать все четыре реализации из-за огромного количества драйверов, которые просто невозможно было заставить производителей переписать. «У нас же, — сказал Эндрю, — ровно одна реализация USB, и это лучшая реализация USB API в мире».
Я проникся.
В 2008 году в Москву приезжал Эндрю Мортон — один из ведущих разработчиков ядра линукс. Я задал ему вопрос относительно скандальной (в тот момент) истории с очередным изменением API стека USB в ядре, из-за которой пришлось править все без исключения драйвера устройств, которые были хоть кому-то нужны.
Он объяснил это словом «эволюция». Эволюция — это не только выживание самых приспособленных, это ещё и отмирание неудачных и/или ненужных. По его словам, в ядре Windows в тот момент было четыре разных реализации usb api, и разработчики операционной системы вынуждены были поддерживать все четыре реализации из-за огромного количества драйверов, которые просто невозможно было заставить производителей переписать. «У нас же, — сказал Эндрю, — ровно одна реализация USB, и это лучшая реализация USB API в мире».
Я проникся.
Это беда и боль проприетарного ПО.
Не совсем. Протоколы и форматы данных начинают хранить эту же проблему независимо от свободности софта, который их реализует. Один кто-то когда-то сделал ляп, тот закрепился, ещё несколько слоёв поверх и изволь поддерживать до финальной смерти технологии в целом...
UFO just landed and posted this here
А разрешение пробелов перед правилами чем-то бы сломало парсеры в принципиальном смысле (возник бы конфликт интерпретации)?
Так точно. Если вы пишите что-нибудь типа:
Но
то если это стоит после таба — это команда выполнитьPATH=/supersecret/path;$$PATH my_secret_program
my_secret_program. А если после пробела — то изменение переменной PATH внутри самого Makefile.Но
sedmail по сравнению с make — это куда круче. Формат файла из трёх колонок разделённых табуляцией, в каждой из которых несколько полей, разделённых пробелом — это что-то на полпути к Whitespace.Это вы ещё рекомендации использовать пробелы для отступов вместо табов во многих языках (вроде PEP-8) не видели, вот уж где анахронизм.
Вы уж если рассказываете историю, так рассказывайте до конца. Тот факт, что A20 отключается ровно на один раз мог бы подтолкнуть вас к правильному выводу: проблема была не в какой-то конкретной программе, но в загрузчике, очевидно. Иначе было бы странно отключать её один раз при запуске, а потом включать. А да, загрузчик этот тоже был порождением Microsoft. Вот тут вся история описана.
Была ещё и вторая вещь, которая тоже на A20 опиралась:
Соотвественно MS/DOS тоже пришлось как-то поддерживать эту схему. Но только проблема в том, что теперь по адресу 5 было бы неплохо разместить
Опять-таки: для старых версий DOS линия A20 спасала, но в MS-DOS 5 проблему решили проще, просто разместив по адресу 0x1000C0 ещё один
А насчёт MMX… вспомните лучше какой чудесный костылик Intel изобрёл, когда XMM регистры до YMM расширял… Это же просто пьестня!
Так что нет, развлекуха с совместимостью продолжается и будет продолжаться (у разрабочиков Linux тоже есть много интересных историй, которые они могут рассказать: это ж внутри ядра у них там нестабильный API и они могут что угодно менять, а интерфейс самого ядра, наоборот, стабильно-железобетонный и там тоже много интересных трюков, за прошедшие годы, накопилось).
Была ещё и вторая вещь, которая тоже на A20 опиралась:
CALL 5 и адрес PSP:6. Это совместимость с CP/M. Дело в том, что у CP/M не было фунации, возращающей количество доступной программам памяти, но зато “официальным” способом вызова CP/M был CALL 5… который содержал адрес первой команды CP/M в адресе 6.Соотвественно MS/DOS тоже пришлось как-то поддерживать эту схему. Но только проблема в том, что теперь по адресу 5 было бы неплохо разместить
FAR JMP… но куда он будет прыгать? А вот куда: F01D:FEF0 (это если памяти больше 64K, иначе всё пересчитывается, но так, чтобы адрес оставался равным 0x1000C0).Опять-таки: для старых версий DOS линия A20 спасала, но в MS-DOS 5 проблему решили проще, просто разместив по адресу 0x1000C0 ещё один
FAR JMP. И такие программы у Microsoft тоже имелись.А насчёт MMX… вспомните лучше какой чудесный костылик Intel изобрёл, когда XMM регистры до YMM расширял… Это же просто пьестня!
Так что нет, развлекуха с совместимостью продолжается и будет продолжаться (у разрабочиков Linux тоже есть много интересных историй, которые они могут рассказать: это ж внутри ядра у них там нестабильный API и они могут что угодно менять, а интерфейс самого ядра, наоборот, стабильно-железобетонный и там тоже много интересных трюков, за прошедшие годы, накопилось).
Честно говоря, в тот момент все ходили и скрежетали зубами по поводу потерянных двух недель. Никто и не собирался дальше ковыряться в ДОС'е, а, тем более, создавать свою ОС.
Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.
Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.
Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.Вы не слышали, но Microsoft-то слышал! Любая программа, слинкованная Microsoft'овским линкером с опцией /EXEPACK, к примеру (но только на системах, где она загружалась в первые 64K). В MS-DOS входила даже специальная программа LOADFIX, которая использовалась, чтобы таких зверей загружать при использовании EMM386 (когда A20 не выключается)!
А сделать флаг в exe-заголовке «Не выключать А20», видимо, религия не позволяла.
Могу только повторить, что:
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Могу только повторить, что:
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
В случае MS-DOS она хотя бы постепенно отмерла (даже в мире Windows теперь минимум её остатков, типа \ как разделитель пути). И с A20 был хоть какой-то исторический смысл. А вот я почти ежедневно вою на SIP, где закрепление недостатков первой наколенной реализации может никогда и не уйти...
А сделать флаг в exe-заголовке «Не выключать А20», видимо, религия не позволяла.Причём тут религия? Не позволяло то, что они не считали, что этот заголовок проживёт хоть сколько-нибудь долго. Напомню: в 1986м году появилась MS DOS 4 (не путать с PC DOS 4) с новым форматом файлов и шла разработка DOS 5 (перед выпуском переименованная в OS/2), где этот формат должен был быть основным.
При этом программ, которые будут использовать больше мегабайта памяти ещё не было и они, в старом формате, вообще не планировались.
Так кому мог потребоваться этот бит?
Ну а когда планы пришлось эта… маленько подкорректировать — было уже поздно.
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.К сожалению альтернатива — выпуск прекрасной, чистой, очень понятной операцинки… которая будет прекрасно смотреться на полках разных компьютерных музеев после коммерческого провала.
Вы ведь тоже вашу 32-битную поделку под MS-DOS пользовали, а не под перепроектированнаой и вычищанной Windows NT… а почему, собственно?
Вы ведь тоже вашу 32-битную поделку под MS-DOS пользовали, а не под перепроектированнаой и вычищанной Windows NT… а почему, собственно?
Потому что в 1995 году никаких Windows у нас еще не было, а компьютеры уже были 32-х разрядными. Зато потом легче было переходить, уже имея 32-х разрядные программы, хоть и под ДОС.
Вопрос был риторический, но спасибо за то, что ответили на него. То есть вы купили новенькие, 32-х разрядные компьютеры, поставили на них старенькую (ибо никакой другой у вас не было) версии DOS и ожидали что всё будет работать.
А почему, собственно, вы считаете, что кто-то другой должен был, купив в 1987м году IBM PC AT должен был получить проблемы и искать как их решать — для того, чтобы вы в 1995м могли без проблем запустить свою 32-битную программу?
Ведь ситуация — один в один: программы ещё старые, рассчитыанные на 8086, а компьютеры — уже новые, на основе 20286… и всё должно работать, иначе техподдержку замучают…
P.S. Кстати ведь и с разработкой MMX-программ всё то же самое: Pentium MMX появился в 1996м, если бы для использования MMX нужно было ждать 1998го, то, боюсь, никто ничего бы под MMX так и не написал. Вообще. Ибо в 1999м появился уже Pentium III с поддержкой SSE (которую как раз можно было сразу встроить в операционную систему, так как в 1999м вышла как раз весьма популярная Windows 98SE, а в 2000м, соотвественно, Windows 2000).
А почему, собственно, вы считаете, что кто-то другой должен был, купив в 1987м году IBM PC AT должен был получить проблемы и искать как их решать — для того, чтобы вы в 1995м могли без проблем запустить свою 32-битную программу?
Ведь ситуация — один в один: программы ещё старые, рассчитыанные на 8086, а компьютеры — уже новые, на основе 20286… и всё должно работать, иначе техподдержку замучают…
P.S. Кстати ведь и с разработкой MMX-программ всё то же самое: Pentium MMX появился в 1996м, если бы для использования MMX нужно было ждать 1998го, то, боюсь, никто ничего бы под MMX так и не написал. Вообще. Ибо в 1999м появился уже Pentium III с поддержкой SSE (которую как раз можно было сразу встроить в операционную систему, так как в 1999м вышла как раз весьма популярная Windows 98SE, а в 2000м, соотвественно, Windows 2000).
UFO just landed and posted this here
DOS 5 никогда не переименовывалась в OS/2. IBM после выпуска OS/2 v 1.2 отдал ее Майкрософту
Ну разумеется PC DOS 5.0 никогда не переименовывался в OS/2. Это вообще другая операционка. Но OS/2, во время разработки, называлась-таки DOS 5. А DOS 4 — это была многозадачная версия DOS для 8086. В частности в ранних бетах имеется “DOS Command Interpreter Version 5.00”, а в SDK для OS/2 1.0 имеется файлик 5CRT0.ASM, в котором есть вот такие вот комментарии:
;Purpose: ; Microsoft C Compiler Runtime for MS-DOS ; --------------------------------------- ; ; How startup works in a few words - ; ; The startup and termination is performed by a few modules ; ; 5crt0.asm DOS 5 specific init/term ; 5crt0msg.asm DOS 5 error messages ; 5crt0dat.asm remainder of shared DOS 5 init/term
там была вытесняющия многозадачность, типа десквю…
до 5 версии pc-dos это был «улучшенный DOS» от IBM для их же машин. Майки оставили за собой некий вид OEM части и MS-DOS майки по факту так же сами не продвали, а были дистрибьютеры. С 5 версии пошли явные разногласия и пошла скупка стороннего ПО и интеграция. Это и dblspace у майко и стекер у pc-dos и другие вещи. По сути это мы можем сейчас наблюдать у intel и amd, где AMD скупает сторонние технологии, например аналог intelRST :)
Не совсем так. До версии 3.30 разработкой DOS, в основном, занимался Microsoft. Версия 4 (вытесняющая многозадачность в реальном режиме, все дела, баранки к чаю) была выпущена несколькими OEMами в Европе, но, насколько известно, никогда не продавалась в US. Ах, да, там появлися и формат NE. Версия 5, на базе, разумееся, DOS 4 (Microsoft'овской DOS 4!) — это как раз была «DOS 4 для защищённого режима» и она превратилась, в конце-концов, в OS/2. С помощью IBM, разумеется.
А вот PC DOS 4 и PC DOS 5 — это вообще разработка в основном IBM изначально, которую, наоборот, уже Microsoft лицензировал (без нескольких утилит, которые Microsoft пришлось переписать). И вот они уже превратились, в конце-концов в MS-DOS 4.01 и MS-DOS 5.0. Никакого отношения к изначальным проектам Microsoft, связанным с многозадачными DOS 4 (реального режима) и DOS 5 (для защищённого режима) они не имеют.
А вот PC DOS 4 и PC DOS 5 — это вообще разработка в основном IBM изначально, которую, наоборот, уже Microsoft лицензировал (без нескольких утилит, которые Microsoft пришлось переписать). И вот они уже превратились, в конце-концов в MS-DOS 4.01 и MS-DOS 5.0. Никакого отношения к изначальным проектам Microsoft, связанным с многозадачными DOS 4 (реального режима) и DOS 5 (для защищённого режима) они не имеют.
и что нам говорит C компилятор для MS-DOS?
А сделать флаг в exe-заголовке «Не выключать А20», видимо, религия не позволяла.
В этом и есть основная суть прогресса. Сейчас добавление такого флага очевидно большинству разработчиков, но для этого надо было насовершать ошибок вроде этой.
```Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.```
все эти программы дела давно минувших дней.
из интересного
```Intel больше не поддерживает шлюз A20, начиная с Haswell. Стр. 271 Руководства Intel по системному программированию, том. 3A от июня 2013 г. гласит: «Функциональность A20M # используется в основном в более старых операционных системах и не используется в современных операционных системах. На новых процессорах Intel 64 A20M # может отсутствовать». ```
все эти программы дела давно минувших дней.
из интересного
```Intel больше не поддерживает шлюз A20, начиная с Haswell. Стр. 271 Руководства Intel по системному программированию, том. 3A от июня 2013 г. гласит: «Функциональность A20M # используется в основном в более старых операционных системах и не используется в современных операционных системах. На новых процессорах Intel 64 A20M # может отсутствовать». ```
Не сразу понял, в чём дело, пришлось гуглить, почему именно F01D:FEF0 и почему нельзя было просто засунуть 0000:00C0, поэтому добавляю пояснение:
В CP/M системные вызовы осуществлялись через CALL 5, соответственно в байте по адресу 5 была инструкция перехода, а в слове по адресу 6 — адрес этой функции.
В CP/M не было функции для определения количества памяти, однако было соглашение, что адрес системного вызова из п.1 является началом блока, занятого системой. То есть программа читала слово по адресу 6 и могла юзать всю память до этого номера.
Это были времена 8080, сегментов не было, а количество памяти не превышало 64 кб, поэтому всё прекрасно работало. Ну а потом пришёл 8086 с сегментной адресацией памяти, совершенно другой системой команд, но Microsoft зачем-то решила сохранить программную совместимость с CP/M, сохранив логику работы пп. 1 и 2.
При этом решение Microsoft мне непонятно. Зачем извращаться с сегментами и заворотом памяти, когда вместо JMP FAR на адрес 0x1000C0 можно было бы просто откусить под это дело несколько байт в конце сегмента, т.е. был бы JMP NEAR на адрес FFF8 (при этом из-за relative кодирования по адресу 6 было бы FFF5, что больше, чем F01D), а регистр SP бы инициализировался в FFF6.
Они
тогда переходить под 64 бита
тогда переходить под 64 бита
При этом решение Microsoft мне непонятно.Оно вам непонятно, потому что вы в другую эпоху живёте.
Поставьте себя на место Типа Патерсона в 1979м году. Стомость оперативной памяти — 10 долларов за килобайт (это тогдашних долларов, сегодняшних будет где-то долларов 30). Яростная борьба за кадлый байт уже не идёт, но экономия десятка байт — ещё не считается чем-то излишним. IBM 5150, напомню, выпускался с оперативной память 16KiB, 32KiB или 64KiB. И хотя в минималную модель PC DOS не впихнули, но на средней — он уже вполне работал. Решение, применённое Seattle Computer Products (а не Microsoft, заметьте) несколько байт вполне себе экономит. А про то, что через три года появится какой-то там новомодный 80286й — никто не думал.
P.S. Обратите внимание, что прыжок-то идёт на адрес 0xC0, который, внезапно, лежит посреди таблицы прерываний. Прерывание 0x30, если быть точным. Это тоже — оно самое, экономия народных байтов и миллисекунд. Под DOS зарезервированы 32 вектора по 4 байта, нам столько не нужно, так что съэкономить лишние 8 байт — почему бы и нет?
А про то, что через три года появится какой-то там новомодный 80286й — никто не думал.
В данном случае ничто не мешало поменять эту реализацию, когда появился 80286, один мегабайт памяти стал вполне себе доступным, и вылезла проблема с А20. Но вместо этого просто сделали костыль с записью магического значения в 0x1000C0.
В данном случае ничто не мешало поменять эту реализацию, когда появился 80286, один мегабайт памяти стал вполне себе доступным, и вылезла проблема с А20.Ало, ало, ало. 80е годы!
Internet — это что-то для гиков, а Compuserve пользуется дай бог несколько процентов покупателей!
Вы можете поменять что-то в железе. Вы можете добавить что-то в BIOS. Но вы не можете поменять ничего в уже проданном софте.
Да, наверное если бы кто-то мог хотя бы представить себе, во что это выльется, то сделали бы патч в BIOS, который бы патчил DOS, который патчил бы программы, скопилированные Microsoft Pascal.
Но поскольку планировалось, что A20 никто дёргать не будет, а кому нужно больше мегабайта памяти — не будут использовать DOS вообще… то они даже функции в BIOS не предусмотрели, позволяющей с A20 работать (она в PS/2 появилась). Только функция «запустить код в защищённом режиме» (которая, собственно, только одна-единственная и должна была знать про линию A20).
Но вместо этого просто сделали костыль с записью магического значения в 0x1000C0.А чем плох костыль? С ним, насколько мне известно, никто никогда никаких проблем не имел.
То, что с чем столкнулся автор статьи решало совсем другую (хотя и похожую проблему), напоминаю.
ФИДО вспомните
И какой процент пользователей IBM PC им пользовался? В 1984м-то году? С учётом того, что софт для FIDO появился в июне 1984го, а IBM PC AT был представлен миру в августе того же 1984го… как-то непохоже, чтобы можно было всерьёз рассчитывать на то, что все покупатели IBM PC AT будут пользоваться FidoNet…
Все как то рывками.
A20 надо шире смотреть. 80286 был «чудесным» процессором из говна и палок.
Переход в защищенный режим, который не кто не использовал, MMU (который использовали храбрые). Дополнительный режим работы для win 3.x для него, os/2 которая использовала фишки 80286 но глючила T_T, хотя опять же глючило старое наследие dos.
Потом уже вышел 80386 проц и с этого момента, мы в какой то степени потеряли RT на intel. Посмотреть на современный x64. костыль V86 в 64 битном режиме? Костыль на кастыле и кастылем погоняет.
из длинного режима перейти в режим наследственный и как факт двойной сброс mmu
ну нахер так было делать то?
```она в PS/2 появилась```
Появилось оно там по другой причине, так как опрос контроллера в клаве это был длительный и тормозной процесс. A20 стали делать через микруху отдельную, а потом уже и в чипсет.
A20 надо шире смотреть. 80286 был «чудесным» процессором из говна и палок.
Переход в защищенный режим, который не кто не использовал, MMU (который использовали храбрые). Дополнительный режим работы для win 3.x для него, os/2 которая использовала фишки 80286 но глючила T_T, хотя опять же глючило старое наследие dos.
Потом уже вышел 80386 проц и с этого момента, мы в какой то степени потеряли RT на intel. Посмотреть на современный x64. костыль V86 в 64 битном режиме? Костыль на кастыле и кастылем погоняет.
из длинного режима перейти в режим наследственный и как факт двойной сброс mmu
ну нахер так было делать то?
```она в PS/2 появилась```
Появилось оно там по другой причине, так как опрос контроллера в клаве это был длительный и тормозной процесс. A20 стали делать через микруху отдельную, а потом уже и в чипсет.
V86 в 64 битном режиме?Это хто такое выпускает? У AMD и Intel такого нету.
Появилось оно там по другой причине, так как опрос контроллера в клаве это был длительный и тормозной процесс.А вам не кажется, что если бы A20 планировалось дёргать часто, то вряд ли бы его опрос сделали бы “длительным и тормозном процессом”?
Переход в защищенный режим, который не кто не использовал, MMU (который использовали храбрые).Да, но планы-то были совсем другие. Вспомните iAPX32. Вот 80286 был такой себе упрощённой версией его. Без инструкций произвольной длины в битах, но с поддержкой защищённых друг от друга объектов и прочего.
Кто ж виноват, что никто из разработчиков не хотело пользоваться вот этими вот всеми теоретическими изысканиями, а хотели всего-навсего большого объёма памяти и удобной работы с этой памятью! У Intel планы были совсем-совсем другие. Там вообще про персоналки не думали, когда 80286й начинали разрабатывать.
```Это хто такое выпускает? У AMD и Intel такого нету.```
?
en.wikipedia.org/wiki/Virtual_8086_mode
ru.wikipedia.org/wiki/X86-64
```Да, но планы-то были совсем другие. ```
не были другими, попытка поиграть в больших — но разработка сложна.
```Там вообще про персоналки не думали, когда 80286й начинали разрабатывать.``` — а про, что думали? Тут же у нас три участника как минимум крупных intel который был мелким поцам, майки которые были мелкими поцами и ibm — который мелким поцам не был и был уже вполне себе гигантом. Нельзя выдирать, что то одно из истории не проследив цепочку действий и событий.
?
en.wikipedia.org/wiki/Virtual_8086_mode
ru.wikipedia.org/wiki/X86-64
```Да, но планы-то были совсем другие. ```
не были другими, попытка поиграть в больших — но разработка сложна.
```Там вообще про персоналки не думали, когда 80286й начинали разрабатывать.``` — а про, что думали? Тут же у нас три участника как минимум крупных intel который был мелким поцам, майки которые были мелкими поцами и ibm — который мелким поцам не был и был уже вполне себе гигантом. Нельзя выдирать, что то одно из истории не проследив цепочку действий и событий.
ru.wikipedia.org/wiki/X86-64Как всегда русская Wikipedia урезана. Если гляните на табличку из английской, то увидите, что либо 64 бита, либо V86, но никак не одновременно.
Это, собственно, причина, из-за которой Microsoft выкинул поддержку DOS в Windows x64. А если бы было так, как вы пишите, то вряд ли бы он на это решился.
UFO just landed and posted this here
Не могли. Для полной виртуализации такого рода нужны AMD-V/VT-x, а они появились через пару лет после выхода Athlon 64.
Могли бы прикрутить что-нибудь типа Dosbox (благо в NT для всяких Alpha и MIPS'ов у них такое было), но… не захотели. Сказали: «раз уж процессор не поддерживает, то и бог с ним… пора наконец закопать стюардессу».
Конечно через несколько лет AMD-V/VT-x появились и стюардессу откопали… но уже только для тонких ценителей.
Могли бы прикрутить что-нибудь типа Dosbox (благо в NT для всяких Alpha и MIPS'ов у них такое было), но… не захотели. Сказали: «раз уж процессор не поддерживает, то и бог с ним… пора наконец закопать стюардессу».
Конечно через несколько лет AMD-V/VT-x появились и стюардессу откопали… но уже только для тонких ценителей.
UFO just landed and posted this here
Это кому как. Это если вы в игры хотите играться, то не нужно. А если какую-нибудь вычислительную задачу запустите?
UFO just landed and posted this here
Слабое же у вас воображение. Legacy так просто не умирает. У меня есть знакомый, который лет 10 назад помогал оптимизировать эмулятор PDP-11 для Itanium. Потому что Saudi Aramco скорости не хватало. Вроде раза в два ускорили. А казалось бы: где PDP-11, а где Itanium (интересно что они теперь с тем эмулятором сделали? портировали на x64-64 или теперь будут Itanium эмулировать?).
Это ITшникам тяжело представить как софт 20-летней давности можно использовать, а в тяжёлой индустрии, где проекты рассчитываются на десятилетия 10-20 лет — вообще не срок. И совт столько же времени используется и дорабатывается.
А вот тут можно взять свеженький компилятор Ada/C/C++ под DOS. C++17, кой-какие фишки C++20, все дела. Да, он 32х битный и если вы делаете прям целую операционную систему, то можно, наверное, замутить интерпретацию в 16-битном режиме и переключения в защищённый режим без интерпретации, если используется DPMI. Но разработка этого всего — время и деньги.
Гораздо проще сказать “хотите DOS… пускайте 32-битную версию Windows… можно в виртуалке… и уже там — можете уже и свои приложения для DOS запускать”.
Те вы думаете, я дал две ссылки просто так и сам не посмотрел? :)
```Там вообще про персоналки не думали, когда 80286й начинали разрабатывать.``` — а про, что думали? Тут же у нас три участника как минимум крупных intel который был мелким поцам, майки которые были мелкими поцами и ibm — который мелким поцам не был и был уже вполне себе гигантом. Нельзя выдирать, что то одно из истории не проследив цепочку действий и событий.
И всё же IBM был лишь одним из многих клиентов Intel.
У Intel было много процессоров, не вызвавших интереса у IBM — 8089, 80186, уже упомянутый 432… — и 80286 вполне мог бы оказаться в их ряду; покупатели нашлись бы и без IBM.
да вы правы, на 286 никто засчещеный режим не использовал, нормально заработал только с 386…
Да использовали os/2 и win 3.1
Но 80286 прошел как страшный сон, он был дорог и не кто не использовал новые возможности, а когда он стал дешевым как 8086, то его использовали как 8086 на стероидах по частотам. Я сейчас говорю про массы и ухожу от серверной темы.
Но 80286 прошел как страшный сон, он был дорог и не кто не использовал новые возможности, а когда он стал дешевым как 8086, то его использовали как 8086 на стероидах по частотам. Я сейчас говорю про массы и ухожу от серверной темы.
Тем не менее, 16-битный защищенный режим таки был в ходу некоторое время
MMU (который использовали храбрые).
Если MMU это страничный маппинг памяти — в 286 его не было.
Посмотреть на современный x64. костыль V86 в 64 битном режиме? Костыль на кастыле и кастылем погоняет.
У AMD есть типа оправдание — на момент создания архитектуры amd64 они были нищими на грани банкротства. Это Intel имел тонны денег, но летал в эмпиреях (iAPX432, Rambus, Netburst, IA64...)
V86 и кучу другого мусора из Long mode выкинули
Зато кучу другого мусора в десятки раз толще — оставили не переделав.
Зачем однобайтовые коды команд для всяких hlt, in, out, cmc, std, enter? А потом мучительно ищут куда бы впихнуть VEX.
Зачем оставили rcl, rcr, когда они даже на 1 бит не нужны при наличии shld/shrd (а тем более на несколько битов)?
Почему xchg остался блокирующим по умолчанию?
Почему set${cc} пишут 1 байт в регистр (из-за чего в коде почти всегда перед ними чистят регистр xor'ом)?
Почему конструкция команды не изменена на более лёгкую для быстрого парсинга (например, дискрет в 2 байта, и насколько возможно везде mod-reg-r/m и sib вынесены вперёд)?
Почему PF никому нахрен не нужный сохраняется в текущем виде, а OF в старшем байте, а в результате lahf/sahf (которые, заметим, возвращены в архитектуру ради удобства виртуалок) он не управляется? В младшем байте 2 свободных бита, да и PF можно было для арифметики применить для переполнения.
Почему сегментные регистры не превращены в long mode как индексы каталогов страниц (как в SystemZ и POWER), что заметно упростило бы виртуализацию?
Все эти проблемы были уже хорошо известны к моменту, когда они стартовали (этак 1997), так что тут чистый прощёлк. И я перечислил не больше четверти от того, что можно и легко было бы исправить.
А потом мучительно ищут куда бы впихнуть VEX.Дык это не из-за Long Mode! VEX (и MVEX/EVEX) так вычурно сделали из-за 32-битного режима. Так-то они выкинули с десяток опкодов в 64-битном режиме. Для команд, которые в 64-битном режиме будут использовать простор… но пока только вместо ARPL вкрутили MOVSXD…
И я перечислил не больше четверти от того, что можно и легко было бы исправить.Какой процент программ, написанных на ассемблере, можно было бы после этого, после механической конверсии, использовать в 64-битном режиме?
AMD решала простую, логичую, задачу: как расширить 80386 (условно) до 64 бит с минимальным изменением архитектуру и максимальным сохранением вложенней в x86. Они эту задачу решили.
А почти всё, что вы перечислили — совместимость бы поломало, общий код для 32бит и 64бит было бы невозможно написать.
Intel? Да, тот мог бы рискнуть и сделать что-то типа того, что сделал ARM: разработал совсем новую, ни разу не совместимую со старой архитектуру, позволяющую, тем не менее создать процессоры, позволяющие эффективно исполнять обе.
Вместо этого Intel опять решил “широко шагнуть” и опять “порвал штаны”.
А почти всё, что вы перечислили — совместимость бы поломало, общий код для 32бит и 64бит было бы невозможно написать.
Что из того, что я перечислил, реально бы на что-то повлияло?
rcl, rcr: не используются ни одним компилятором, а код, написанный вручную, всё равно надо переносить в деталях.
xchg: ну вставили бы в генерацию seq_cst lock xchg вместо xchg.
set${cc}: кодогенерация бы только упростилась из-за выкидывания постоянных xor (ну и код бы уменьшился).
Длина опкодов: вообще пофиг, меняется очень малая часть.
И так далее...
Кодогенераторы для 32 и 64 и так заметно различные хотя бы из-за размера полей адресов, из-за необходимости учитывать удлинение команды из-за префиксов, из-за rip адресации, различия, в какие команды можно впихивать 32, а в какие 64 бита константы, и ещё 100500 подобных различий.
AMD решала простую, логичую, задачу: как расширить 80386 (условно) до 64 бит с минимальным изменением архитектуру и максимальным сохранением вложенней в x86. Они эту задачу решили.
Да, эту задачу они решили. Но именно под эту задачу вообще не надо было удалять какое-нибудь DAA. Раз удалили — значит, они решали не только эту задачу, но ещё и другие — устранить старое легаси и сделать задел на будущее. Ну и почему они её решили только на 1/3 (в лучшем случае)?
А почти всё, что вы перечислили — совместимость бы поломало, общий код для 32бит и 64бит было бы невозможно написать.
Значит, его сейчас уже невозможно написать. Но почему я вижу его написанным? Наверно, вы где-то ошибаетесь?
Или вы видите в каком-нибудь LLVM идентичную MD-часть для 32 и 64 бит?
Дык это не из-за Long Mode! VEX (и MVEX/EVEX) так вычурно сделали из-за 32-битного режима.
Всё равно очень мало общего у декодеров — меняются размеры, префиксы и т.д. — можно было для 64 бита сделать покороче — и за это им бы весьма сказали спасибо.
Вместо этого Intel опять решил “широко шагнуть” и опять “порвал штаны”.
Это да, но это другая тема.
Кодогенераторы для 32 и 64 и так заметно различные хотя бы из-за размера полей адресов, из-за необходимости учитывать удлинение команды из-за префиксов, из-за rip адресации, различия, в какие команды можно впихивать 32, а в какие 64 бита константы, и ещё 100500 подобных различий.Я боюсь вы никогда не работали с кодогенераторами. Либо если что-то и делали, то это были «монолиты», которые в одной функции проходили от исходной задачи к машинному коду.
Можете глянуть на то, как это сделано в gcc, хотя бы. Ну или LLVM, если хотите.
Разница между кодогенератором под x86-64 и кодогенератором под i686, внезапно, сравнима с разницей кодогенераторов под i386 и i686.
И даже в ядре Linux большая часть кода для 32 бит и 64 бит, внезапно, общая. А это, прямо скажем, весьма и весьма низкоуровеневый код.
Ну и почему они её решили только на 1/3 (в лучшем случае)?Потому что их задачей была экономия транзисторов, а не чего-либо ещё.
Сильно сомневаюсь, что на отказе от поддержки
rcl в 64-битном режиме при сохранении поддержки rol можно много транзисторов наэкономить.Они оставили более, чем достаточно, свободных опкодов. Только вот оказалось, что люди от 32 битов отказываться не очень готовы.
Или вы видите в каком-нибудь LLVM идентичную MD-часть для 32 и 64 бит?А какое имеет отношение LLVM к x86-64? Полная спецификация на x86-64 была разработана и предствалена публике в 2000м, когда LLVM был сугубо исследовательским проектом.
А вот binutils, GCC, Linux — дело другое. И там как раз очень много кода общего.
Впрочем у LLVM тоже, конечно. Ибо это разумно и логично.
Всё равно очень мало общего у декодеров99% — это мало?
меняются размерыДа. У инструкций с опкодами A0-A3 и B9-BF другие размеры
immediate. Это сколько нужно транзисторов, чтобы отследить?префиксыУгу. Инструкции с опкодами 4x являются однобайтовыми инструкциями без операндов в 32-битном режиме и префиксом (причём особым: сразу после него должен идти опкод) в 64-битным. Это сколько транзисторов?
и т.д.Никаких «и т.д.». Описанные выше отличия — это полное и исчерпывающее описание отличий декодеров.
Позже — да добавились ещё отличия, связанные с VEX/EVEX. Но в 2000м году — вот это вот было всё. Сотня транзисторов, может меньше.
можно было для 64 бита сделать покороче — и за это им бы весьма сказали спасибоПрограммисты — может быть. Технологи — очень и очень вряд ли.
Это да, но это другая тема.Это та же самая тема.
Основная проблема Itanic'а была в том, что когда он только появился 64-битного софта ещё не было, а 32-битный там работал отвратительно. Потому что им пришлось делать, фактически, два процессора в одном. Они угрохали весь транзисторный бюджет на, никому не нужный (в первые годы) 64 битный режим, а 32 битный сделали «по остаточному принципу». В результате получили никому не нужную дорогостоящую игрушку.
А вот AMD — поставила задачу: максимально унифицировать 32-биные и 64-битные режимы. С точки зрения разделения ресурсов. И решила её. Там отличий примерно столько же, как при переходе от 16-бит к 32-м в 8086. Даже регистров не сильно больше: да, добавилось 8 новых регистров… зато нет вообще ни одной инстркции, работающей с 32-битными регистрами. Фактически на x86-64 32-битные регистры отсутствуют… хотя «снаружи» это не так просто заметить.
В результате появлась возможно вот это вот продавать (причём большими тиражами продавать!) тем, кому был нужен 32-битный процессор.
Снова обратная совсестимость заруливает, как видите.
Можете глянуть на то, как это сделано в gcc, хотя бы. Ну или LLVM, если хотите.
Видел. А вы в них заглядывали? Что-то сомневаюсь, потому что их содержимое никак не возражает моему тезису (смотрю по gcc): всяких rcl, rcr там просто нет (ещё бы); xchg присутствует только в атомарной части (в которой и так есть зависимость типа "нет mfence — фиг с ним, lock orl $0, target"; и так далее. То есть изменения были бы минимальными. Ну и генерация опкодов — там и так зависимость от режима (где-то часть адресаций выкинута, вместо них rip-based...)
(Кстати, в роли квиза — сумеете заставить llvm сгенерировать rcl? А более чем на 1 бит?)
Сильно сомневаюсь, что на отказе от поддержки rcl в 64-битном режиме при сохранении поддержки rol можно много транзисторов наэкономить.
Можно. Полный barrel shifter другой разводки, если делать на нём, или реализацию циклического сдвига пошагово, если без бочки (и заодно соответствующую микропрограмму). Нельзя на бочке для rol сделать rcl: ширина разная.
Никаких «и т.д.». Описанные выше отличия — это полное и исчерпывающее описание отличий декодеров.
Вы если уж рассказываете про "полное и исчерпывающее", то попробуйте хотя бы проверить себя перед отправкой. Адресация по RIP: другой декодинг методов адресации — вы её забыли? Соответственно ещё как минимум вычисление исходных регистров другое. Отсутствие адресации AH..DH и вместо них SPL..DIL при соответствующем префиксе. Так что вы уже дважды ошиблись.
Во сколько это транзисторов выливается — не думаю, что тут есть инсайдер с данными. Но опять же, если так судить, то и всякие DAA не надо было отменять.
Программисты — может быть. Технологи — очень и очень вряд ли.
Можно подумать, им вообще новая разработка как идея понравилась ;(
Основная проблема Itanic'а была в том, что когда он только появился 64-битного софта ещё не было, а 32-битный там работал отвратительно.
Основная проблема итаника — EPIC. Если бы он справился с проблемами памяти, Intel бы это вытянул. Без этого даже полная замена кодировки не убила бы его.
МожноКак?
Полный barrel shifter другой разводки, если делать на нём, или реализацию циклического сдвига пошагово, если без бочки (и заодно соответствующую микропрограмму). Нельзя на бочке для rol сделать rcl: ширина разная.Но rcl нам же всё равно нужен, 32-битный режим никуда не делся. И shld/shrd тоже нужны. Вы точно уверены, что создание такого странного гибрида, умеющего 8/16/32-битный rcl, но не 64-битный… себя окупит?
Адресация по RIP: другой декодинг методов адресации — вы её забыли?На декодирование она не влияет. Просто в 32-битном режиме вместо значения
rip всегда используется нуль.Соответственно ещё как минимум вычисление исходных регистров другое.Это в каком месте, извините?
Отсутствие адресации AH..DH и вместо них SPL..DIL при соответствующем префиксе.…происходит в 64-битном режиме точно так же, как и в 32-битном. Просто там REX префикс всегда отсутствует.
Но опять же, если так судить, то и всякие DAA не надо было отменять.DAA отменили потому что это было просто и дёшево (с точки зрения транзисторного бюджета). Очень может быть, кстати, что они вообще выбрасывают исключение на этапе исполнения, а не декодирования.
Всё то, что вы предлагаете — гораздо, гораздо сложнее. И усложняет создание гибридного 32бит+64бит процессора.
ARM, который сделал как вы (два совершенно разных декодера для 32-битного и для 64-битного режима) и уже думает о том, как бы от поддержки 32-битного режима отказаться. Ибо дорого. Тразисторы тратяться.
В случае с x86-64 — это не нужно. Потому что и 32-битный режим и 64-битный получаются из гипотетического «смешанного» режима отключением очень небольшой части функциональности и микроскопическими отличиями в декодере (это очень важно для x86, так как из-за необходимости иметь 20 декодеров эта часть занимает весьма внушительную площадь на кристалле, причём не где-то на перефиерии, в L3, где места полно, а «в самом сердце»). Только в 32-битном режиме отключается, условно, чтение и прибавление
rip (вместо этого читается и прибавляется нуль), а в 64-битном, условно же — чтение и прибавление базы cs и ds.Ровно такой же трюк был применён в 80386м, если помните. Там тоже нет отдельного «реального» режима, а вместо этого есть хитрая работа со «скрытыми» регистрами. Отсюда — знаменитый unreal mode.
Можно подумать, им вообще новая разработка как идея понравилась ;(Им за это деньги, в общем-то платят. Но они, как и все, хотят сделать по минимум, а получить по максимуму.
А все ваши мелкие придирки… ну вот не вижу я как их реализовать так, чтобы одновременно поддерживать и старый 32-битный режим с автоматическим префиксом
lock для xchg и новый — без всего этого… и на этом получить каким-то мистическим образом упрощение конструкции, а не усложнение.Основная проблема итаника — EPIC.Нет.
Без этого даже полная замена кодировки не убила бы его.Убила бы.
Вот эту-то информацию я знаю «из первых рук», как раз. От знакомого, который как раз в группе поддержки Itanium'а в Intel работал.
Каждый раз, когда разработчики Itanium'а начинали жаловаться на то, что им достаются устаревшие техпроцессы они получали резонный вопрос «вы можете обеспечить своими чипами замену для Xeon'ов? которая будет быстрее на сущесвующем коде?». Получив резонный ответ «нет, этого мы сделать не можем — архитектура не позволяет» их, со спокойной совестью, вычёркивали из планов, касающихся новейших техпроцессорв.
То есть им приходилось не просто решать «проблемы с памятью». Им приходилось делать это на устаревшем техпроцессе. Pentium 4 вышел в 2000м на 0.13 μm, Tualatin вышел в 200м на нём же… а Itanium 2, тогда же, достался 0.18 μm… когда Madison получил-таки (уже весьма не новый, к тому времени) 0.13 μm… вышел Prescott на 0.09μm… и так далее.
Itanium всегда получал новый техпроцесс позже, чем другие чипы — именно потому, что не мог, с разумной скоростью, исполнять сущесвующие программы.
А Athlon 64 — мог! А Opteron — мог! И потому в них вкладывали всё, что AMD мог в них вложить…
Вот и вся разница.
Именно поэтому как только x86-64 появился у Intel — интерес к Itanic'у сдулся, как воздушный шарик.
Но rcl нам же всё равно нужен, 32-битный режим никуда не делся. И shld/shrd тоже нужны. Вы точно уверены, что создание такого странного гибрида, умеющего 8/16/32-битный rcl, но не 64-битный… себя окупит?
Про shld/shrd я ни слова не говорил — они как раз нужны. Про rcl… во-первых, добавление 64-битного размера для них означает, что надо добавлять ещё одну бочку (ни одна из существующих не подходит). Во-вторых, опять же — почему daa отменено, а rcl нет? Нелогично.
DAA отменили потому что это было просто и дёшево (с точки зрения транзисторного бюджета). Очень может быть, кстати, что они вообще выбрасывают исключение на этапе исполнения, а не декодирования.
Тем более. Чтобы поддержать DAA, не надо было ничего добавлять — как возились с младшим байтом, так и возимся. Чтобы поддержать RCL, надо добавлять поддержку 64-битных сдвигов особого типа. Значит, это работы больше. Так зачем?
Потому что и 32-битный режим и 64-битный получаются из гипотетического «смешанного» режима отключением очень небольшой части функциональности и микроскопическими отличиями в декодере
Тогда прокомментируйте с этой точки зрения, пожалуйста, слухи, что в P4 и ранних Core качество OoO у Intel в 64-битном режиме было сильно хуже, чем в 32 битах, вплоть до полного отсутствия реордеринга. Разве это возможно на универсальном декодере?
Каждый раз, когда разработчики Itanium'а начинали жаловаться на то, что им достаются устаревшие техпроцессы они получали резонный вопрос «вы можете обеспечить своими чипами замену для Xeon'ов? которая будет быстрее на сущесвующем коде?». Получив резонный ответ «нет, этого мы сделать не можем — архитектура не позволяет» их, со спокойной совестью, вычёркивали из планов, касающихся новейших техпроцессорв.
И это точка зрения только исполнителя внизу (ещё вопрос, сколько испорченных телефонов участвовало от точки принятия решения). Вы действительно считаете, что они получали объективную картину? Может, наоборот — потому не вкладывали, что прорыва не получилось (и не могло получиться), и уже после этого стали рассказывать про "существующий код" в качестве отмазки?
Попробуйте оценить со своей точки зрения перспективы (в те же годы) следующего гибрида: полный современный x86-32 плюс возможность переключиться в IA64 (который должен был быть сильно проще и потому не требовать такого безумного декодера). Разве если бы архитектура была сильно лучше x86, он бы не начал получать преимущество, какое получал 32-битный режим 80386 во времена тотального DOS?
Про rcl… во-первых, добавление 64-битного размера для них означает, что надо добавлять ещё одну бочку (ни одна из существующих не подходит).Что значит «ни одна из существующих» не подходит? Вы, я надеюсь, не думаете, что в процессоре есть отдельный шифтер для ROL, отдельный для RCL и так далее. Это всё, размеется, было “свёрнуто” в одну единую конкруткцию ещё во времена 80486.
Увеличить её вдвое — куда проще, чем пытаться какое-то извращение придумать.
Во-вторых, опять же — почему daa отменено, а rcl нет? Нелогично.Более чем логично. Все отменённые инструкции имеют однобайтовый опкод. Которых не хватает и освобождение которых может быть полезным. И которые всё равно отрабатываются сильно по разному. RCL и RCR — входят в “группу сдвигов”, которые декодер может и вообще не различать, в принципе. Просто передавать “тип сдвига” в ALU. Различить их сложно, экономия сомнительна. Так зачем тогда?
Значит, это работы больше. Так зачем?Затем что сдвиги всё равно нужны, а увеличить shifter с 32бит на 64бит — куда проще, чем как-то радикально его переработать. Вот если бы вообще все сдвиги отменить — тогда, может быть, работы и стало бы меньше. Но это уж какой-то совсем кастрированный процессор получился бы.
Разве это возможно на универсальном декодере?А причём тут вообще декодер?
Тогда прокомментируйте с этой точки зрения, пожалуйста, слухи, что в P4 и ранних Core качество OoO у Intel в 64-битном режиме было сильно хуже, чем в 32 битах, вплоть до полного отсутствия реордеринга.Не знаю что там было у Core, но у P4, внезапно, было ALU, работающее на удвоенной частоте (double pumped ALU, можете погуглить). И Northwood, внезапно, исполнял 32-битные операции как две 16-битные, а Prescott — 64-битные как две 32-битных. И да, это, разумеется, усложняло OoO. У Northwood при переходе от 16-битных операций к 32-битным, у Prescott — при переходе от 32-битных к 64-битным.
Никакого отношения к декодеру это не имеет, что легко понять, если вспомнить что никаких таких эффектов в Althon 64 (где x86-64 был реализован изначально, а не “вкручен в авральном порядке”) никогда не было.
Разве если бы архитектура была сильно лучше x86, он бы не начал получать преимущество, какое получал 32-битный режим 80386 во времена тотального DOS?Разумеется! Он получил бы ровно столько же преимуществ, сколько 80386 получил от 32-битности в первые годы после выхода: нуль.
В том-то всё и дело! 80386й вышел в 1985м году. В 1986м он уже продавался в персоналках. Однако несколько лет никого не волновало — работают в нём 32-битные операции или нет! Только в 1992м году появилась Windows 3.1, которая опционально, иногда, могла использовать 32-битные операции! И при запуске выводила буквально следующее:
The Intel 80386 processor in this computer does not reliably execute 32-bit multiply operations. Windows usually works correctly on computers with this problem but may occasionally fail. You may want to replace your 80386 processor.Внезапно, да? Семь лет после выпуска 80386, операционка рекомендует (не требует!), чтобы вы заменили процессор, в котором 32-битные операции не работают.
Правда вышедшая в том же 1992 году OS/2 2.0 уже таки 32-битных операций требовала и не запускалась, если у вас был такой процессор, но, тем не менее… семь лет 32-битность не была востребована. Вообще. Никак.
А активный переход на 32-битный софт начался через десять лет после выхода 80386го, когда Windows 95 вышла.
Попробуйте оценить со своей точки зрения перспективы (в те же годы) следующего гибрида: полный современный x86-32 плюс возможность переключиться в IA64 (который должен был быть сильно проще и потому не требовать такого безумного декодера).Труп. Гарантия 100%. Даже обсуждать нечего.
Просто потому что Athlon 64 люди брали не потому, что там были 64 бита, а потому что он был банально быстрее, чем Athlon XP. В 32-битном режиме. А тут вы такого эффекта обеспечить не можете. Совершенно неважно как там у вас устроена IA64 и какой в ней декодер — если за неё вам нужно будет платить, когда можно и не платить (а кто заставит AMD тоже только такие процессоры выпускать?) — выбор очевиден.
И так Intel тянул сколько мог, буквально пинками загонял всех на IA64 не делая популярных “народных” процессоров 64-битных.
Но на 10 лет, нужных на то, чтобы наработался софт и появились какие-то шансы — его не хватило.
Вы, я надеюсь, не думаете, что в процессоре есть отдельный шифтер для ROL, отдельный для RCL и так далее. Это всё, размеется, было “свёрнуто” в одну единую конкруткцию ещё во времена 80486.
Как минимум — одна для всех сдвигов, кроме RCL/RCR, и одна для них. Совмещать исполнения в варианте, когда сдвиг налево на 10 бит переносит 60 -> 6 для ROL и 60 -> 5 для RCL, настолько дорого, что отдельная бочка будет дешевле.
Возможно, также отдельные для ROL каждого размера (из-за заворота битов), тут уже по обстановке.
Более чем логично. Все отменённые инструкции имеют однобайтовый опкод. Которых не хватает и освобождение которых может быть полезным.
Противоречите себе. С одной стороны, освобождение может быть полезным. С другой стороны, когда я говорил, что этих кодов можно было освободить ещё больше — оказывается, декодер у вас сильно дорогой получается. Всё равно на каждый отменённый опкод это, по вашим же расчётам, плюс пара-тройка вентилей… ну ладно, до десятка, то есть до сотни транзисторов. Что, оно того по-вашему не стоит?
(Более того, в первых версиях можно было даже не отменять фактически, а сделать более длинные копии, декларировав неработу старых версий.)
Просто потому что Athlon 64 люди брали не потому, что там были 64 бита, а потому что он был банально быстрее, чем Athlon XP. В 32-битном режиме.
И ровно то же случилось бы в описанном мной варианте: x86 часть с адекватной скоростью прогресса — и поверх неё IA64 часть, которая вначале так же невостребована, но за счёт её доступности начинает привлекать энтузиастов, некоторые начинают включать этот режим, те, кто хотят 64 бит хотя бы ради маппинга крупных файлов, начинают строить сборки под неё… что, нет?
Вот я думаю, что IA64 бы всё равно не выжил из-за explicit parallelism. А вы считаете, что выжил бы, в описанном варианте и при отсутствии конкурента у AMD?
В том-то всё и дело! 80386й вышел в 1985м году. В 1986м он уже продавался в персоналках. Однако несколько лет никого не волновало — работают в нём 32-битные операции или нет!
Волновало — в пределах средств доступа ко всякой расширенной памяти. DESQview — 1985. EMM386 — 1988. Юниксы типа AT&Tʼшного V/86, Xenix/386, SCO… Ну да, "ширнармассы" в лучшем случае DESQview знали, но что это даёт?
Умножение во всяких EMM, наверно, не было нужно, но кому нужно — знали про этот баг.
Ну и до Windows были всякие DOS/4G[W], а также отдельные программы, которые сами по себе использовали преимущества наличия 32 бит (я помню MultiEdit — реально быстрее работал).
А не для адресной арифметики и сейчас автоматическая ширина int в 32 бита это бесплатный подарок, а не суровая необходимость. (Частично поэтому и не стали вводить тотальный ILP64.)
А активный переход на 32-битный софт начался через десять лет после выхода 80386го, когда Windows 95 вышла.
Вот именно — воспользовались готовым бесплатным подарком на том, что кто-то уже отработал всё и сложил в красивую обёртку. Но тут тогда проблема позднего появления этой обёртки.
Совмещать исполнения в варианте, когда сдвиг налево на 10 бит переносит 60 -> 6 для ROL и 60 -> 5 для RCL, настолько дорого, что отдельная бочка будет дешевле.Мать-мать-мать привычно повторило эхо. Вы это сейчас всерьёз?
Как сделать RCL на бочке от SHLD? Да тривиально: грузим в один регистр содержимое исходного, в другой — сначала C флаг, потом ставшиеся 63 бита. Прокручиваем.
На выходе — то, что нам нужно.
То же самое — в обратную сторону.
То это всё работает именно так — заметно хотя бы по тому, что RCL на 64 бита, внезапно, не эквивалентен RCR на 1 бит, а… просто ничего не делает.
Как вы уже тут много раз пропели SHLD/SHRD нам нужны всё равно — они активно используются. А добавка, по сравнению с ними, для RCL/RCR нужна копеешная.
Такое ощущение, что вы забыли про секретную операцию, никому неведому и нигде не используемую: копирование регистров.
И, разумеется, никакой второй бочки. Или вы вот этот вот шифтер на один бит «второй бочкой» хотите назвать? Побойтесь бога, он в 64 раза проще и меньше!
Возможно, также отдельные для ROL каждого размера (из-за заворота битов), тут уже по обстановке.Там вообще чистый SHLD/SHRD справится. То есть просто, банально:
ROL %CL, %RAX — это вот почти то же самое, что SHLD %CL, %RAX, %RAX (первая команда может работать с памятью, вторая нет, но это не проблемы ALU). Какая, нафиг, «вторая бочка»? Кому, куда, зачем?Всё равно на каждый отменённый опкод это, по вашим же расчётам, плюс пара-тройка вентилей… ну ладно, до десятка, то есть до сотни транзисторов. Что, оно того по-вашему не стоит?Нет. Не стоит. Вообще до сегодняшнего дня только один опкод был переиспользован — а платформе скоро 20 будет. То есть даже и то, что было выкинуто — скорее выкинули не потому, что это было кому-то нужно, а потому что это было сделать просто и дёшево.
И ровно то же случилось бы в описанном мной варианте: x86 часть с адекватной скоростью прогресса — и поверх неё IA64 часть, которая вначале так же невостребована, но за счёт её доступности начинает привлекать энтузиастов, некоторые начинают включать этот режим, те, кто хотят 64 бит хотя бы ради маппинга крупных файлов, начинают строить сборки под неё… что, нет?Она, к сожалению должна не только существовать, но ещё и работать хоть со сколько-нибудь приемлемой скоростью. IA64 радикально отличается не только от x86, но и вообще — от всех распространённых архитектур. 128 регистров 65битных регистров, регистровые окна, фоновая выгрузка в память… архитектура весьма интересная, но как на это смотришь — так возникает ощущение, что это разработали с целью, чтобы его было нереально эмулировать поверх сущесвующего железа.
x86 поверх IA64 (собственно в Itanium 2 дико медленную аппаратную эмуляцию выкинули и перешли на програмную) — несколько более реально… но оно всё равно оказывается медленнее, чем нативная реализация… в качестве запускача старого кода — не годится.
Если хотите посмотреть как можно было сделать более вменяемо — гляньте на ARM. 32-бита и 64-бита там имеют радикально разные декодеры… но вот уже всё, что после — можно сделать общим. В IA64 и x86 — этого и близко нету.
А вы считаете, что выжил бы, в описанном варианте и при отсутствии конкурента у AMD?При отсутствии конкуренции и не такое выживает. Монополия — вещь сурьёзная. Вспомните сколько лет Apple тянула откровенно лажовый PowerPC. Покупали. За неимением альтернативы.
Волновало — в пределах средств доступа ко всякой расширенной памяти. DESQview — 1985. EMM386 — 1988.Тут 32-битность вообще никаким боком. Был востребован V86 — тогдашний аналог AMD-V/VT-x.
Но, опять-таки, если бы Intel привязал VT-x к дико дорогому (по необходимости: стоимость чипов растёт при увеличении размеров нелинейно) IA64, а AMD — выкатил бы его на x86-64… как вы думаете — что стали бы покупать?
Умножение во всяких EMM, наверно, не было нужно, но кому нужно — знали про этот баг.В EMM вообще микроскопическое количество 32-битного кода. Windows 386 вышла в 1987м, но в ней, внезапно, всей 32-битности — запускач на 30K с поддержкой V86. Всё остальное 16-битное и работает даже на XT!
Ну и до Windows были всякие DOS/4G[W], а также отдельные программы, которые сами по себе использовали преимущества наличия 32 бит (я помню MultiEdit — реально быстрее работал).Они не были «до Windows». Это вы могли с ними встретится раньше, в это я верю. Но Watcom C 8.5/386 — это 1991й год. Не сильно раньше Windows 3.1.
Ну да, «ширнармассы» в лучшем случае DESQview знали, но что это даёт?Это даёт то, что вы решаете проблему курицы и яйца. Никто не пишет программы под «перспективное железо». Программы пишут под то, что уже стоит на столах (в датацентрах, в кармане) у пользователей.
А покупают пользователи то, подо что есть софт.
Выскочить из этого круга можно двумя путями:
- Выпустив железо, которое может отлично работать со старым кодом, распространив его, а потом уже — заставить людей писать под него программы. Примеры — 80386, 64-битный ARM (первый силикон — в 2012 году… обязательная поддержка программами — в 2019 году… всё те же самые 6-7 лет).
- Вовремя подсуетившись, когда открывается какая-то радикально новая ниша, где никакого существующего софта пока нету. Так «выстрелил» ARM, хотя на рынке смартфонов ему пришлось соревноваться с MIPS и SH-5. К несчатью для Intel'а никакой новой ниши для «тяжёлых» процессоров не было и нет.
Вот именно — воспользовались готовым бесплатным подарком на том, что кто-то уже отработал всё и сложил в красивую обёртку. Но тут тогда проблема позднего появления этой обёртки.Нет. Воспользовались тем, что железо уже было у половины пользователей 32-битное (возможно, в 1995му году — и больше, чем у половины). Но для того, чтобы оно таким оказалось — оно должно было до этого продаваться и использоваться как 16-битное.
То же самое с переходом на 64-битный x86-64 и 64-битный же ARM.
Apple правда прыгала как хотела — то 64-битный Power выпустит и соотвествующую OS, то перейдёт с него на 32-битный Core, то выпустит новую OS без поддержки 32-битных программ…
Но они могут себе позволить: монополия.
Остальные — нет, не могут.
Как сделать RCL на бочке от SHLD? Да тривиально: грузим в один регистр содержимое исходного, в другой — сначала C флаг, потом ставшиеся 63 бита.
Остроумно, запомню. Но по сути вы тот же транзисторный бюджет потратили на операцию вгрузки на входе значения со специфическим сдвигом (который больше нигде не нужен, кроме как для этой операции). Пронумеруем биты стандартным LE. 127-64 получили первую копию аргумента, выровняв на 64=младший. 63 получил C. Теперь надо: если это 64-битная операция, то 62-0 получают 63-1 входа; если 32-битная, то 62-32 получают 31-1 входа; если 16-битная, то 62-48 получают 15-1 входа… все те же затраты на коммутацию и с особым случаем для RCL/64. Теперь куча коммутаций на загрузке… и таки зачем?
Такое ощущение, что вы забыли про секретную операцию, никому неведому и нигде не используемую: копирование регистров.
Такое ощущение, что вы после воспоминания о копировании регистров не попытались пойти на шаг дальше и представить, как это самое копирование будет сделано в данном случае и какие у него будут специфические затраты.
То это всё работает именно так — заметно хотя бы по тому, что RCL на 64 бита, внезапно, не эквивалентен RCR на 1 бит, а… просто ничего не делает.
Это может быть всего лишь последствием универсализации подхода "берём не больше младших 6 бит" независимо от реальной значимости. (Ну а что им ещё делать?)
О внутреннем устройстве тут это ничего однозначно не говорит.
Там вообще чистый SHLD/SHRD справится.
Кэп, думаете, почему я говорю, что при их наличии RCL не нужны? Более того, на них легко сделать полезный сдвиг более чем на 1 бит, а на RCL — нет.
Да, так вы пробовали получить эту команду из LLVM?
Нет. Не стоит. Вообще до сегодняшнего дня только один опкод был переиспользован — а платформе скоро 20 будет. То есть даже и то, что было выкинуто — скорее выкинули не потому, что это было кому-то нужно, а потому что это было сделать просто и дёшево.
Я так понимаю, только один — это потому что ещё стараются делать одинаково с 32-битным режимом. Ну тогда… без инсайдерских мемуаров мы не поймём, почему это "просто и дёшево" было применено тут, но не в другом месте, поэтому пока что лучше закончить на этом.
Если хотите посмотреть как можно было сделать более вменяемо — гляньте на ARM. 32-бита и 64-бита там имеют радикально разные декодеры… но вот уже всё, что после — можно сделать общим. В IA64 и x86 — этого и близко нету.
Вот уже то (один из аспектов), о чём я спрашивал. Мнение понятно, спасибо. А всё-таки — если бы этого барьера не было — реализация на EPIC выжила бы? При нынешней-то тормозной DRAM?
В EMM вообще микроскопическое количество 32-битного кода. Windows 386 вышла в 1987м, но в ней, внезапно, всей 32-битности — запускач на 30K с поддержкой V86. Всё остальное 16-битное и работает даже на XT!
Я про адресацию и говорю. Точно так же и при переходе 32->64 собственно нативная работа с 64-битными целыми нужна малой доле пользователей (а кому нужна, то нужна по тем же причинам, что и адресация в 64 бита), а вот адресация — вопрос подъёмности кодирования этого всего.
Вспомните сколько лет Apple тянула откровенно лажовый PowerPC.
Чем лажовый?
Теперь куча коммутаций на загрузке… и таки зачем?Чтобы не мучиться с декодером, очевидно. Все сдвиги в x86 аккуратно скомпонованы в такой себе «блок сдвигов». Где 3 бита указывают на вид сдвига, а остальное содержит параметры. Соотвественно вам достаточно эти 3 бита сохранить в микроинструкции, а разбираться со спецификой этих сдвигов будет уже ALU.
А чтобы сгенерировать исключение — вам это всё где-то в другом месте нужно отлавливать.
Такое ощущение, что вы после воспоминания о копировании регистров не попытались пойти на шаг дальше и представить, как это самое копирование будет сделано в данном случае и какие у него будут специфические затраты.Почему же? Как раз про это я помню. Вы вообще размер бочки себе представляете? Гляньте хотя бы на примере ARM1. Это огромная конструкция (ну… в масштабах процессорного ядра). И размер её, внезапно, квадратично зависит от размера регистра. Бочка на 64 бита будет вчетверо больше бочки на 32. Все же подготовительные операции — гораздо меньше во-первых и вы их уже из разработали давным-давно (для 32-битного режима) во вторых. Модификации для 64 бит там не слишком большие.
А всё-таки — если бы этого барьера не было — реализация на EPIC выжила бы? При нынешней-то тормозной DRAM?Фиг его знает, на самом деле. Но вряд ли. EPIC или VLIW, фактически, переносят scheduler в комплятор. А когда у вас новое железо покупается под уже имеющиеся бинарники… это не очень прокатывает. Снова всё упирается в совместимость — в этот раз уже “внутри” платформы.
Это безотностельно к проблемам создания компиляторов под вот это вот всё…
Точно так же и при переходе 32->64 собственно нативная работа с 64-битными целыми нужна малой доле пользователей (а кому нужна, то нужна по тем же причинам, что и адресация в 64 бита), а вот адресация — вопрос подъёмности кодирования этого всего.Совершенно верно — но отсюда и возникает феномен, когда после выхода новой платформы она 6-7 лет исполняет код, написанный для старой.
А если у вас старая и новая не разделяют совсем ничего, то вам, фактически, приходится продавать «два процессора по цене одного» всё это время.
Чем лажовый?Тупо медленный и горячий. Mac Pro G4 Quad заметно отставал от AMD/Intel того времени… но зато требовал жидкостного охлаждения (единственный, вроде бы, до сих пор случай, когда персоналка от крупного производителя штатно продавалась с жидкостным охлаждением). Восхитительный процессор, чего уж там. Ноут на нём Apple так и не осилила (догадайтесь почему).
P.S. Вообще интересный факт, который все, более-менее, знают, но о котором мало кто задумывается. Разработка железа и софта — сравнимые по времени задачи. Разработка процессора «с нуля» занимает пять-шесть лет (столько заняла, скажем разработка iAPX 432 или IA-64). Разработка новой операционки с нуля занимает, внезапно, плюс-минус столько же (чуть-чуть поменьше: NT разрабатывали с 1989го по 1983й, Android — с 2003го под 2008й). Если не с нуля — то и до и другое идёт веселее, конечно. И там и там. Что это значит? А это значит что любая архитектура почти всё время своего существования исполняет код, оптимизированный под предыдущую архитектуру! А код, оптимизированный под новую архитектуру будет исполняться на уже следующем поколении железа… Вот вокруг этого всё развитие «железа» где-то с 60х годов и «крутится».
И размер её, внезапно, квадратично зависит от размера регистра. Бочка на 64 бита будет вчетверо больше бочки на 32.
"Щито?" (tm)
Я не знаю, как достигнуть O(N^2). Честно. O(N log N) — банально. Вертикали, например, биты слова, горизонтали — управляющие биты сдвига и их обработка.
Нижняя горизонталь — соответствует биту 0, вся логика выглядит примерно как
for (i = 1; i <= 31; ++i) {
out1[i] = control[0] ? input[i-1] : input[i];
}
out1[0] = control[0] ? (is_rotate ? input[31] : 0) : input[0];
for (i = 2; i <= 31; ++i) {
out2[i] = control[1] ? out1[i-2] : out1[i];
}
for (i = 0; i < 2; ++i) {
out2[i] = control[1] ? (is_rotate ? out1[30+i] : 0) : out1[i];
}и так далее до out5 при 32 битах.
32 бита — 5 горизонталей по 32 демультиплексора в них. 64 бита — 6 горизонталей по 64 демультиплексора. И так далее.
Чтобы не создавать сложную логику выбора между нулём (или знаковым битом для sar) и значением с круга на больших сдвигах, можно делать двойную бочку (как для shld) и при линейных сдвигах заливать правую нулями, а при кольцевых — копировать входное слово. Ну, в 2 раза толще для всех случаев.
Признайтесь, как вы получили квадратичную зависимость, однако интересно...
Все же подготовительные операции — гораздо меньше во-первых
Заливка одним и тем же словом, не сдвинутым при rol и сдвинутым при rcl — ещё как одна такая горизонталь сдвига на входе.
Не очень много, да. Но накойхер? (фамилиё такое)
EPIC или VLIW, фактически, переносят scheduler в комплятор.
VLIW ни при чём, это слишком общее понятие. А вот EPIC как раз — да, переносит шедулинг в компилятор там, где компилятор не может в принципе знать заранее, как шедулить. Или вы знаете, как ему такое знание обеспечить? (Смену типа памяти не рассматриваем)
Тупо медленный и горячий.
По идее, это не должно зависеть от архитектуры — проблемы были у конкретного исполнения. В целом репутация архитектуры от этого, да, пострадала.
А это значит что любая архитектура почти всё время своего существования исполняет код, оптимизированный под предыдущую архитектуру!
Ну так это стандартное легаси. И задержки там не 6-7 лет, а в разы больше — по 64 битам x86 уже до 20, по 32 подходит к 35. Компиляция под 32 бита даже без cmov вполне типовой вариант. Но какой из этого надо делать вывод?
Признайтесь, как вы получили квадратичную зависимость, однако интересно…А вот. В действительности всё не так, как на самом деле.
Если вы взгляните на реальную, физическую фотку бочки (вот тут, например), то вы обнаружите, что, внезапно, основное место там занимают даже не транзисторы, а проводники (эффект заметен только на больших бочках, конечно, для малых транзисторы лидируют). Ибо они удлиняются на каждом шаге вашего алгоритма.
Для первого шага вам нужно N проводников длины 1, для второго N проводников длины 2, для третьего — N проводников длины 4…
Получаем последовательность:
1+2+4+…+2ˡᵒᵍᴺ-1 = N - 1Ну и их, как вы верно заметили, вам нужно
N штук. N умножаем на N - 1… — это чистый квадрат… получите, распишитесь.Железо и софт — они чуть-чуть по разному устроены.
Не очень много, да. Но накойхер? (фамилиё такое)Я же уже сказал: декодер упростить. Сколько, по вашему, в современном x86 процессоре декодеров? 3, 4, 10? Подумайте.
Подумали?
А вот «бочек» у вас штучки 3-4. Потому обменять сложность в ALU на упрощение декодера — выгодно.В типичном современно процессоре их, внезапно, 20. А теперь думайте: а нафига.
Всё не так сложно, на самом деле
Проблема в том, что современные процессоры — суперскалярные. Вам нужно декодировать 3-4 инструкции за такт. Но вы же понятия не имеете где эти инструкции начинаются! Решение — «двухпроходное» декодирование: вначале 16 «простых» декодеров, вычисляющих только длину, дальше 3-4 «сложных», разбирающих уже саму инструкцию для передачи в ALU.
Главное даже не размеры кристала, а разнесение работы по нему. Ибо бичом современных CPU является локальное тепловыделение.
По идее, это не должно зависеть от архитектуры — проблемы были у конкретного исполнения.Да, но продавалось-то конкретное исполнение. И не один год. Пока у вас монополия — это “прокатывает”. И не так важно какой у вас косяк: то ли процессор сильно горяч, то ли клавиатура ломающаяся… если у покупателя нет альтернативы — он будет “брать что дают”. Ну… не “до бесконца”, конечно (в прошлом веке Apple с таким подходом чуть “не сыграла в ящик”), но довольно долго.
Но какой из этого надо делать вывод?Если у вас есть конкуренты, то вы не можете сменить архитектуру «скачком». Вам нужна либо монополия (Apple, за счёт этого, сделал уже четыре перехода), либо вас будет возвращать обратно.
Правда возможно «вытеснение с соседнего рынка». Хорошим примером является HP, который перевёл Superdome на Xeon'ы… в 2016м году.
Но HP смог это сделать потому, что к моменту перехода он 20 лет продавал железо на x86… на другом рынке.
Ни DEC, ни SGI, ни SUN — этот «фокус» провернуть не могли, потому как Wintel-компьютерами никогда не занимались.
P.S. Более интересный вопрос — это откуда у Apple монополия. Я, к примеру, пробовал как-то работать с MacOS… не смог. Ощущение, что на тебя смирительную рубашку надели. На iOS, по этой же причини, никогда даже не смотрел. Но есть люди, которым “заходит”. Вот как, почему, за счёт чего? Для меня до сих пор загадка. Главное, что они даже сами объяснить, толком, не могут. Мантры, какие-то, произносят.
EPIC или VLIW, фактически, переносят scheduler в комплятор. А когда у вас новое железо покупается под уже имеющиеся бинарники… это не очень прокатывает. Снова всё упирается в совместимость — в этот раз уже “внутри” платформы.
Замечу, что Hexagon — в нише, где от нового железа не требуется выполнять старые бинарники — взлетел и весьма успешен.
Что это значит? А это значит что любая архитектура почти всё время своего существования исполняет код, оптимизированный под предыдущую архитектуру!
У вас неявное допущение, что разработка софта под новый процессор начинается после выпуска этого процессора. Но это не так: Windows XP 64-Bit вышла через четыре месяца после Itanium.
Попробуйте оценить со своей точки зрения перспективы (в те же годы) следующего гибрида: полный современный x86-32 плюс возможность переключиться в IA64 (который должен был быть сильно проще и потому не требовать такого безумного декодера).
Сомневаюсь, что IA64-ядро прямо сильно уж проще x86-32-ядра: вики приводит цифру в 25М транзисторов для Itanium McKinley (2002) и 29М для современного ему P4 Northwood.
Ну и с технологической стороны, на чип нельзя просто напихать вдвое больше транзисторов.
Все же MMU в 80286 был. Только MMU был в рамках защиты сегментов, а уже в 80386 появились и страницы.
```Если MMU это страничный маппинг памяти — в 286 его не было. ``
Преоброзование логический адреса в физический адрес на автоматом с с помощью схемы управления памятью . Которая называется MMU. Правда там были и свои проблема, особенно сильно память страдала фрагментацией.
Они и сделали как могли + спешка, так как была гонка процессоров.
Это сейчас легко рассуждать из будущего. Напомню, что 80286 появилось 16 мегабайт все же. A20 пробовали реализовать по разному, но устройство которое не использовалось и могло переключить без задержки, это контроллер в клавиатуре =)
Это как в камоде, процессоры в флоповодах использовали =)
Это сейчас легко рассуждать из будущего. Напомню, что 80286 появилось 16 мегабайт все же. A20 пробовали реализовать по разному, но устройство которое не использовалось и могло переключить без задержки, это контроллер в клавиатуре =)
Это как в камоде, процессоры в флоповодах использовали =)
A20 пробовали реализовать по разному, но устройство которое не использовалось и могло переключить без задержки, это контроллер в клавиатуре =)Как раз это был дико тормозной способ A20 переключать. Но поскольку у контроллера клавиатуры была лишняя нога, а A20, согласно “планам партии”, планировалось переключать один раз при запуске операционци для защищённого режима (каковых на момент создания IBM PC AT не было и в помине), то… сделали как сделали.
Собственно поначалу всё шло по плану, ксати: DOS использовали на компьютерах с 256KiB-512KiB оперативки, линия A20 там никого не напргала. А Novel Netware и прочие Xenix'ы её переключали её один раз и тоже всё было хорошо.
А вот в 90е годы — начались проблемы.
Ну а потом пришёл 8086 с сегментной адресацией памяти, совершенно другой системой команд,
Система команд 8086 нарочно была сделана совместимой на уровне ассемблерного листинга, и для переноса программы с CP/M-80 на DOS её достаточно было пересобрать кросс-ассемблером.
Зачем извращаться с сегментами и заворотом памяти, когда вместо JMP FAR на адрес 0x1000C0 можно было бы просто откусить под это дело несколько байт в конце сегмента, т.е. был бы JMP NEAR на адрес FFF8 (при этом из-за relative кодирования по адресу 6 было бы FFF5, что больше, чем F01D), а регистр SP бы инициализировался в FFF6.
Наверное, для COM это бы сработало; но для EXE длиннее 64 КБ эти несколько байт оказывались бы посередине кода. И кроме того, потерялась бы возможность читать из PSP объём доступной памяти.
Мало кто знает, что был dos с номером 666…
Так всё ещё глубже. К примеру LOADALL на 80286/80386, который эмулировался обработчиком invalid opcode даже на Core 2 Duo, где этих инструкций уже тридцать лет как не стало.
да, ядро os
да, я помню как ИБИ хотел OS/2 перевести на микроядро, но потом почему тормазнули
да, я помню как ИБИ хотел OS/2 перевести на микроядро, но потом почему тормазнули
Вот OS/2 и himem.sys и были причинами (причём весьма древних версий), что в коде BIOS торчала эта самая совместимость. А если копнуть ещё глубже — то она дожила до Sandy/Ivy Bridge стараниями Gigabyte.
У Gigabyte какая-то нездоровая тяга к обратной совместимости…
Скриншот из прошивки мат.платы 2020 года выпуска
Наркоманы…
Нет, ну вот как так-то? Поддержка 3DMark 01 есть, а поддержки OS/2 (которую, напоминаю, вы до сих по можете купить) — нету.
Вообще-то перевели на модифицированное микроядро Mach, в версии «OS/2 Warp Connect PowerPC Edition». Но запускаться она могла только на ThinkPad-ах 800-й серии (серия с PowerPC, в какчестве CPU) коих было то-ли две, то-ли три модели. И на паре-тройке моделей RS/6000. На webarchive можно разжиться исошником и доками в PDF.
Лично я никогда не видел в программах использования трюка с «заворотом». Если такие и были, это уж совсем какая-то седая древность и дурной стиль.Вообще этот трюк выполнял драйвер HIMEM.SYS, при помощи которого часть DOS можно было загрузить в верхние адреса, чтобы освободить основное пространство ОЗУ. Все наверное помнят параметр DOS=HIGH, ну вот он именно это и делал.
Как раз Himem.sys это и не нужно было делать. Он как раз включал A20.
Вообще с 1995 года мы работали в 32-х разрядном режиме и программа и данные размещались выше первого Мбайта, а Himem.sys использовали только как учетчика занятой памяти. Никакие расширители ДОС при этом не требовались.
Вообще с 1995 года мы работали в 32-х разрядном режиме и программа и данные размещались выше первого Мбайта, а Himem.sys использовали только как учетчика занятой памяти. Никакие расширители ДОС при этом не требовались.
Как раз Himem.sys это и не нужно было делатьЧто именно и кому не нужно было делать, простите?
А вот это смотря какие ему ключи скормить. В позднем досе (который был в Win 95/98 по крайней мере точно) у него поведение линии А20 задавалось ключами.
помоему не himem загружал а qemm386? не или еще emm386, если не ошибся в названии…
да и himem $ qemm386 были огого
да кстати всех с наступившем!!!
Мне кажется, вы зря сюда добавили MMX(и 3Dnow!) — там основная причина совмещения была в экономии транзисторного бюджета для достаточно широких регистров, а не в том, как ОС с ними работает
Вы это сейчас… всерьёз? 8 64 битных регистров даже если использовать 6-транизсторую ячейку — это три тысячи транзисторов. При этом в обычном Pentium было 3.3 миллиона транзисторов, а в Pentium MMX — 4.5 миллиона. Экономия 0.25% разницы — это, конечно, повод для введения новых инстркций и устройства свистопляски для разработчиков…
Регистры были совмещены как раз именно, чтобы новых версий операционок для поддержки MMX не требовалось. Вот уже в XX веке, даже в его начале устновка патчей, для поддержи нового железа, воспринималась нормально. А вот в те времена…
Регистры были совмещены как раз именно, чтобы новых версий операционок для поддержки MMX не требовалось. Вот уже в XX веке, даже в его начале устновка патчей, для поддержи нового железа, воспринималась нормально. А вот в те времена…
One of the important requirements for MMX technology was to enable use of MMX instructions in applications without requiring any changes in the IA system software.
An additional requirement was that an application should be able to utilize performance benefits of MMX technology in a seamless fashion, i.e., it should be able to employ MMX instructions in part of the application, without requiring the whole of the application to be MMX technology-aware.
Albert Yu, Senior Vice President and General Manager, Microprocessor Products Group Intel Corp.
Единственная свистопляска, помнится, была с планированием кода — для недопущения частого переключения FP/MMX регистров. Также стоит добавить, что FEMMS инструкция была быстрее EMMS для этих целей.
И действительно было приятно поднять 3DNow! код на ужё мёртвой тогда OS/2 — но у меня и тогда не сложилось впечатление, что совмещение регистров делалось исключительно ради этого — что ваша цитата как раз и подтверждает («One of the important requirements» — это далеко не «key requirement» ).
Вы утрируете — 8 регистров, которые ничем не запитаны, которые ни с чем и никак не соединяются — выглядят странно. Более реальна цифра в единицы процентов от всего бюджета.
Возможно, вы помните, что было и внедрение x87 инструкций самих по себе, растянувшееся с 1980(8087) по март 1994(последний 80486SX2 без FP) с одной стороны, и случившийся тогда бум multimedia/inet с другой — поэтому все хотели что-то попробовать, но не переусердствовать в усилиях.
К примеру, MIPS 3D(SIMD) инструкции тоже были реализованы в FP регистрах, но сложности с ПО в вертикальной системе у Silicon Graphics тогда не было (и системы патчей в UNIX среде интенсивно применялись — пусть и с помощью почты+дискет ;))
И действительно было приятно поднять 3DNow! код на ужё мёртвой тогда OS/2 — но у меня и тогда не сложилось впечатление, что совмещение регистров делалось исключительно ради этого — что ваша цитата как раз и подтверждает («One of the important requirements» — это далеко не «key requirement» ).
8 64 битных регистров даже если использовать 6-транизсторую ячейку — это три тысячи транзисторов.
Вы утрируете — 8 регистров, которые ничем не запитаны, которые ни с чем и никак не соединяются — выглядят странно. Более реальна цифра в единицы процентов от всего бюджета.
Возможно, вы помните, что было и внедрение x87 инструкций самих по себе, растянувшееся с 1980(8087) по март 1994(последний 80486SX2 без FP) с одной стороны, и случившийся тогда бум multimedia/inet с другой — поэтому все хотели что-то попробовать, но не переусердствовать в усилиях.
К примеру, MIPS 3D(SIMD) инструкции тоже были реализованы в FP регистрах, но сложности с ПО в вертикальной системе у Silicon Graphics тогда не было (и системы патчей в UNIX среде интенсивно применялись — пусть и с помощью почты+дискет ;))
«One of the important requirements» — это далеко не «key requirement»У вас, наверное, плохо с английским. Требования есть требования. А важные требования — это требования, которые вы должны исполнить. Да, это было не единственное требование. Были и другие. Но варианты, когда MMX требует изменений в операционке не рассматривались изначально.
Возможно, вы помните, что было и внедрение x87 инструкций самих по себе“x87 инструкции сами по себе” это 8087й, в котором было в полтора раза больше транзисторов, чем в 8086м. Он чуть не в половину стоимости IBM PC оценивался.
Конечно такую шнягу, мало кому нужную (проблема курицы и яйца: раз ни у кого нет сопроцессора, то программы пишутся без его поддержки, а раз нет поддержки сопроцессора, то он нафиг никому и не нужен) было сложно внедрить.
К примеру, MIPS 3D(SIMD) инструкции тоже были реализованы в FP регистрах, но сложности с ПО в вертикальной системе у Silicon Graphics тогда не было (и системы патчей в UNIX среде интенсивно применялись — пусть и с помощью почты+дискет ;))У MIPS при этом, насколько мне известно, нет двух режимов, в одном из которых можно работать с числами с плавающей точкой, а в другом, альтернативном, с SIMD.
В этой ситуации совмещение регистров не приводит к особым сложностям. Можно всё что угодно использовать вперемешку и FP-регистры просто получают дополнительную функцию.
А вот MMX… там же сколько плясок с бубнами нужно сотворить, чтобы можно было использоваь в одной программе и FPU и MMX!
У MIPS 3 режима FP регистров: fp32, fp64 и 2x fp32(AMD 3Dnow!) — так что всё то же самое.
Точных данных по die area х86 у меня нет, но есть по MIPS 3D — 17й слайд:
— FPU заниамет чуть меньше 15% от всего процессора;
— реализация SIMD(2x fp32) в регистрах FPU — 6-7%;
— реализация самих инструкций — 3%;
— суммарно — +9-10% к FPU, или +1.4-1.5% ко всему процессору (что очень неплохо!).
А если бы делали отдельные физические регистры, то было бы меньше 15%, но ненамного — скорее всего от 7 до 12% — что очень и очень много.
Для х86 архитектуры цифры могут быть несколько иными — но общий порядок где-то такой же.
Я не знаю, что вы писали на MMX/3Dnow, но у меня ни Image Processing (для него MMX и предназначен), ни Computer Graphics (тут 3Dnow предназначен) принципиальных сложностей не было — главное — разводить инструкции по коду. Собственно — именно так везде и было написанно, причём на английском (так что ваше беспокойство о моём трогательно, но не нужно;) )
PS: Я не зря привёл пару FEMMS/EMMS инструкций — у AMD в FEMMS получилось сделать более эффективное переключение, чем у Intel в EMMS. И не спрашивайте, почему;)
Точных данных по die area х86 у меня нет, но есть по MIPS 3D — 17й слайд:
— FPU заниамет чуть меньше 15% от всего процессора;
— реализация SIMD(2x fp32) в регистрах FPU — 6-7%;
— реализация самих инструкций — 3%;
— суммарно — +9-10% к FPU, или +1.4-1.5% ко всему процессору (что очень неплохо!).
А если бы делали отдельные физические регистры, то было бы меньше 15%, но ненамного — скорее всего от 7 до 12% — что очень и очень много.
Для х86 архитектуры цифры могут быть несколько иными — но общий порядок где-то такой же.
Я не знаю, что вы писали на MMX/3Dnow, но у меня ни Image Processing (для него MMX и предназначен), ни Computer Graphics (тут 3Dnow предназначен) принципиальных сложностей не было — главное — разводить инструкции по коду. Собственно — именно так везде и было написанно, причём на английском (так что ваше беспокойство о моём трогательно, но не нужно;) )
PS: Я не зря привёл пару FEMMS/EMMS инструкций — у AMD в FEMMS получилось сделать более эффективное переключение, чем у Intel в EMMS. И не спрашивайте, почему;)
У MIPS 3 режима FP регистров: fp32, fp64 и 2x fp32(AMD 3Dnow!) — так что всё то же самое.То есть вы не можете в один регистр засунуть fp64, а другой пару fp32? Жуть какая. Мне казалось, что там как в ARM: всё можно вперемешку. В один регистр — один fp32, в другой — пару fp32, в третий — вообще четыре. И никакого переключения режимов процессора! Никакой потери данных, записанных «в другом» режиме!
PS: Я не зря привёл пару FEMMS/EMMS инструкций — у AMD в FEMMS получилось сделать более эффективное переключение, чем у Intel в EMMS. И не спрашивайте, почему;)Честно говоря сам факт переключения — куда как важнее, чем его эффективность. Если переключение не нужно, то разделять регистры — разумное решение. В конце-концов 32-битные регистры почти во всех архитектурах — это половинка от 64-битных и это никого не напрягает. А вот если у вас два «типа независимых» набора регистров, то сам тот факт, что вам нужно явно переключаться между режимами, теряя, при этом, содержимое всех регистров — это несколько «новаторское» решение.
Мне казалось, что там как в ARM: всё можно вперемешку. В один регистр — один fp32, в другой — пару fp32, в третий — вообще четыре.
Понимаю… в 64бит регистр 4 х fp32. вот откуда 3к транзисторов ;)
Честно говоря сам факт переключения — куда как важнее, чем его эффективность.Мне начинает казаться, что вы вообще ничего не писали на MMX/3DNow. Потому как у инженеров принято просто оперировать целесообразностью использования — и эффективноесть переключения как рахз напрямую влияет на использование — остальное для мракетологов.
для справки — в софтовом Q2/3DNow было ускорение порядка 80-85%.
Понимаю… в 64бит регистр 4 х fp32. вот откуда 3к транзисторов ;)Не угадали. В ARM вообще блог из 32битных регистров, но векторные инструкции могут использовать два таких регистра или четыре.
Мне начинает казаться, что вы вообще ничего не писали на MMX/3DNow.Нет конечно. В нём был смысл буквально пару лет. После появляния SSE ни то, ни другое не нужно. Недаром поддержку 3DNow! уже даже сама AMD выкинула из своих процессоров много лет назад.
для справки — в софтовом Q2/3DNow было ускорение порядка 80-85%.Это по сравнению с SSE? Извините, но… не верю!
И MMX и 3DNow! были ооооочень короткоживущим костылём. SSE гораздо более логичен. И вышел вскоре после MMX, так что воспользоваться фишками MMX/3DNow! успела только буквально горсточка программ.
В ARM вообще блог из 32битных регистров
Вы явно говорите про поздний ARM. и это называется register file.
Нет конечно. В нём был смысл буквально пару лет.
Чуть больше. lagacy hardware. Впрочем, если бы писали на MMX/3DNow! — то знали бы не в теории, о чём говорите.
Это по сравнению с SSE? Извините, но… не верю!
Q2 — Dec 1997. P3(with SSE) — Feb 1999. Извините, телепортироваться в будущее не мог — так это число — сравнение межу x87 и 3Dnow в самом начале 1998го.
Нет конечно. В нём был смысл буквально пару лет.
ещё раз вернусь к этому — пожалуйста — это ресурс читают и инженеры — не пишите ничего, к чему вы не приложили руку!
а как-же история с Windows 7, в которой обратная совместимость решалась виртуальной машиной в комплекте с ключем от XP для встроенной виртуалки?
У автора превью-картинка с ошибками.
Было полно плат AM3, которые после обновления работали с процессорами AM3+
например, https://www.msi.com/Motherboard/support/890GXMG65#support-cpu
>Вместо этого теперь на веки-вечные MMX и FPU мешают друг другу
Это умерло лет 15 назад.
Опять же, если программа настолько нужная и важная, то и DPMI никто не отменял. Скажем, программки на Паскале для 286 вообще этих проблем с A20 не имели.
Это умерло лет 15 назад.
Опять же, если программа настолько нужная и важная, то и DPMI никто не отменял. Скажем, программки на Паскале для 286 вообще этих проблем с A20 не имели.
В специализированной обработке изображений ничего не умерло.
А DMPI и прочие expanded — жалкие костыли вместо нормального 32-разрядного режима, который физически возможен и без защищенного режима. С тогдашним Паскалем не было проблем, поскольку он не мог создать программ, у которых команд и данных намного больше 1 Мбайта.
А DMPI и прочие expanded — жалкие костыли вместо нормального 32-разрядного режима, который физически возможен и без защищенного режима. С тогдашним Паскалем не было проблем, поскольку он не мог создать программ, у которых команд и данных намного больше 1 Мбайта.
В специализированной обработке изображений ничего не умерло.
Какой смысл в использовании MMX и x87 FPU, когда есть SSE и AVX?
```вместо нормального 32-разрядного режима, который физически возможен и без защищенного режима.```
что такое 32 разрядный режим?
Давайте не придумывать терминологию свою.
Процессор работает в реальном режиме, защищенным и виртуальным v86.
с 80286 win 3.1 водит понятие стандартный режим, который по сути и называется защищенный.
что такое 32 разрядный режим?
Давайте не придумывать терминологию свою.
Процессор работает в реальном режиме, защищенным и виртуальным v86.
с 80286 win 3.1 водит понятие стандартный режим, который по сути и называется защищенный.
Режим реального адреса, при котором код прикладной программы имеет 32-х разрядные адреса и использует 32-х разрядные регистры и без префиксов 66/67. Иногда (например, в справочнике Михаила Гука) он называется нереальным режимом (unreal mode). Почему-то у Гука написано, что такой режим будет работать до первого перехода. Это не так. Но при исключениях действительно приходилось принимать меры, чтобы вернуться в прерванное место выполнения (выше первого мегабайта).
Режим реального адреса, при котором код прикладной программы имеет 32-х разрядные адреса и использует 32-х разрядные регистры и без префиксов 66/67.
Таки нет. Классический unreal mode — это по умолчанию 16-битные регистры, а для использования 32-битных регистров нужны префиксы. Режим полностью совместим с обычным реальным режимом, единственное отличие — снято ограничение на предел адресации внутри сегмента.
Да, процессор можно было перевести в 32-битный режим с помощью специального флага, но тогда на выходе получался геморрой с прерываниями и системными вызовами, да и код все равно только в первых 64кб сегмента можно было размещать. Проще уж было DPMI использовать.
Да никаких особых сложностей не было. Да, каждая прикладная программа имела «внизу» кусок в несколько килобайт: стек и перехват всех исключений. При входе в прерывание все возвращалось в обычный режим, а потом, при выходе, опять переключалось в 32 разряда без 66/67. Стек у нас использовался несильно, поэтому нескольких килобайт стека вполне хватало.
А коды и данные размещались выше первого мегабайта. Пресловутые 640 Кбайт почти не занимались. Я уже несколько раз об этом писал. И коды и данные выше мегабайта и все прекрасно работало под ДОС.
А коды и данные размещались выше первого мегабайта. Пресловутые 640 Кбайт почти не занимались. Я уже несколько раз об этом писал. И коды и данные выше мегабайта и все прекрасно работало под ДОС.
Более интересен не вопрос «как», а вопрос «зачем». В 1989м же был уже DJGPP. А в 1991м же вышел Watcom C 8.5 с поддержкой DOS/4GW, который позвлял без всех этих сложностей обходиться. И ещё сколько-то этих расширителей было.
Зачем изобретать велосипед, который может оказаться с чем-нибудь несовместим (как в итоге и вышло), если есть куча готовых решений, не требующих столько героизма?
Зачем изобретать велосипед, который может оказаться с чем-нибудь несовместим (как в итоге и вышло), если есть куча готовых решений, не требующих столько героизма?
Почему велосипед? Скорее гоночный автомобиль)) Без всяких расширителей и безо всяких селекторов-дескрипторов и DMPI берешь память и используешь.
А при переходе с ДОС на Windows переделывать пришлось EXE-заголовки, а сами программы так 32-х разрядными как были, так и остались.
И, кроме этого, этот был, возможно, самый быстрый режим работы:
А при переходе с ДОС на Windows переделывать пришлось EXE-заголовки, а сами программы так 32-х разрядными как были, так и остались.
И, кроме этого, этот был, возможно, самый быстрый режим работы:
Скорее гоночный автомобиль))Гоночный авомобиль, как бы, ездит быстрее автомобиля. Ваше же поделие работае явно не быстрее (или быстрее? за счёт чего?). Зато создало вам кучу проблем на ровном месте.
А при переходе с ДОС на Windows переделывать пришлось EXE-заголовки, а сами программы так 32-х разрядными как были, так и остались.А если бы не любовь к велосипедостроению, то они как работали бы, так и продолжали бы работать.
То есть какой геморой вы получили от велосипедостроения — понятно. А вот какой выигрыш… извините, но нет.
Потому что «берешь память и используешь… а потом две недели дизассемблируешь DOS… а потом ещё переделываешь под Windows»… это ни разу не преимущество.
Были вполне себе такие программы, но это не важно уже. Начиная с определенного момента, вовсю пошло использование дос-экстендеров, с которыми тоже таки не было проблем.
нормального 32-разрядного режима
Unreal mode, что ли? Это не более, чем неподдерживаемый хак.
В специализированной обработке изображений ничего не умерло.
Что может ммх, чего не может SSE? И кто использует ММХ/х87 в 64-битном коде? Линукс, например, даже контекст FPU не сохраняет.
Линукс, например, даже контекст FPU не сохраняет.
Сильное заявление. Всё он сохраняет, иначе бы существующий код тупо перестал работать.
Там другой момент: регистры FPU больше не сохраняются при переключении между ядром и пользовательским кодом. Если код в ядре таки хочет их использовать, то он должен вызывать kernel_fpu_begin() / kernel_fpu_end().
иначе бы существующий код тупо перестал работать
Что за существующий 64-битный код с x87/mmx/3dnow? В long mode FP — это, конечно, SSE2/AVX
Вообще-то, и MMX, и FPU в Long Mode доступны. Технически, никто не запрещает их использоваться.
Любой код, которому не хватает точности
А вот MMX/3DNow! — таки да, бессмысленны.
double. Такой существует.А вот MMX/3DNow! — таки да, бессмысленны.
Такой существует.
И, конечно, он жутко секретный?
Ага. Настолько жутко секретный, что про него аж статья в Wikipedia имеется.
Любая программа может быть скомпилирована под x86-64 с -mfpmath=387 и будет работать — можете легко в этом убедиться сами.
Да, цена — лишние перегонки между FPU и SSE, например, при вызове функций с параметрами и результатами float и double — но кому-то нужно, это поддерживается. При типе long double вообще будут применены функции, которые работают с FPU.
были же системы персональные и с большим RAM тот же силикон, крей (не персональный конечно) и.т.д
вот только они даже х86 не являлись…
Были, но они не x86. История серверов на x86, отдельная тема.
У меня сейчас есть 80286 с 8 и 16 метрами памяти simm.
Для того времени это не имело смысла для конечного пользователя, да же расширители памяти редко когда использовали такие объемы и обычно во всяких таблицах lotus.
netware же сделала шаг вперед с выпуском 80286 проца, но вечная пересборка ядра, при изменения конфигурации и перетыкивание дискет, это была боль. Да не очень часто, но когда надо, то считай сервер ушел в не работу дня так на два. Os/2 которая понимала плюшки и была по сути сделана для 80286 проца, была кривая, так как своего софта не было, а «эмуляция» DOS имела определенные проблемы. Хотя в итоге у IBM виртуальная машина дос в os/2 получилась лучше, чем в NT.
У меня сейчас есть 80286 с 8 и 16 метрами памяти simm.
Для того времени это не имело смысла для конечного пользователя, да же расширители памяти редко когда использовали такие объемы и обычно во всяких таблицах lotus.
netware же сделала шаг вперед с выпуском 80286 проца, но вечная пересборка ядра, при изменения конфигурации и перетыкивание дискет, это была боль. Да не очень часто, но когда надо, то считай сервер ушел в не работу дня так на два. Os/2 которая понимала плюшки и была по сути сделана для 80286 проца, была кривая, так как своего софта не было, а «эмуляция» DOS имела определенные проблемы. Хотя в итоге у IBM виртуальная машина дос в os/2 получилась лучше, чем в NT.
дос в ОС2 был на порядок лутче, ядро winnt v3 часто при подении выдовала ошибку OS/2 и номер…
MS забрала у IBM исходники OS/2 v 1.3 на основе её стала писать WinNT
MS забрала у IBM исходники OS/2 v 1.3 на основе её стала писать WinNT
Нетваре не выпускала процы… её система на много опередила сетивые ОС. А после выхода netware v 4.1, NWDC стал практически стандартом
нормальная ос/2 была с версии 3.1 там же был отдельно netware requester и отдельно IBM лан менеджер. на основе которого и была написана сeтевая подсистема WinNT.
а где это можно почитать, я про Lan manager и что его куски кода ушли в NT?
Почитать про это ничего не удастся, потому что в голове у baby11 всё смешалось. Microsoft никогда не видел кода OS/2 версий новее 1.x.
Сетевая подсистема WinNT действительно было написана на основе кода LAN Manager, но не IBM Lan Manager в OS/2 версии 3.1, а Microsoft LAN Manager в OS/2 1.3 (собственно MS OS/2 1.3 вообще очень редко продавалась отдельно, хотя вроде кому-то удалось увидеть коробку с ней, в большинстве случаев она шла в комлекте с Microsoft LAN Manager… причём чтобы всех окончательно запутать Microsoft выпустил три разных версии MS OS/2 1.3).
Кстати дисковая подсистема оттуда (а она, внезапно, в 16-битной MS OS/2 1.3 была 32-битной… а вот в IBM OS/2 1.3 она оставалась 16-битной, даже в OS/2 2.0 Limited Edition она всё ещё была 16-битной), после должной переработки перекочевала в Windows 95).
Сетевая подсистема WinNT действительно было написана на основе кода LAN Manager, но не IBM Lan Manager в OS/2 версии 3.1, а Microsoft LAN Manager в OS/2 1.3 (собственно MS OS/2 1.3 вообще очень редко продавалась отдельно, хотя вроде кому-то удалось увидеть коробку с ней, в большинстве случаев она шла в комлекте с Microsoft LAN Manager… причём чтобы всех окончательно запутать Microsoft выпустил три разных версии MS OS/2 1.3).
Кстати дисковая подсистема оттуда (а она, внезапно, в 16-битной MS OS/2 1.3 была 32-битной… а вот в IBM OS/2 1.3 она оставалась 16-битной, даже в OS/2 2.0 Limited Edition она всё ещё была 16-битной), после должной переработки перекочевала в Windows 95).
UFO just landed and posted this here
Заворачивание по A20 более не поддерживается, начиная с haswell (4-е поколение) intel core. Почти в каждом новом процессоре немного «портится» совместимость, так что о 100% обратной совместимостью можно забыть, даже старый добрый 80286 не был полностью обратно совместим с 8086.
Sign up to leave a comment.
Причуды обратной совместимости