Обновить

Комментарии 72

С одной стороны, давно пора закопать стюардессу. С другой стороны, будет ли конкурентоспособен Интел без легаси?

Скорее всего и Винда и Линукс готовый к запуску 32 битных приложений через промежуточную виртуальную машину. Конечно, какой-то софт отвалится, но это будет минимом.

прекращение поддержки 32-разрядного режима в нулевом кольце защиты

32-битный юзерспейс остаётся, выпилят только поддержку 32-битных ядер.

удаление 16- и 32-разрядных защищённых режимов;

Так что, видимо, только симулятор.

Впрочем, на Маке через это трижды проходили, дважды только на моей памяти (выпиливание 32-битных приложений, потом переход на ARM) – и ничего, система жива. А для легаси есть Rosetta. Так что симулятор тут – не худший выход.

Нет, 32 битный приложения продолжат работать нативно. Им нужен не protected mode, а compatibility mode, который остаётся.

у маков достаточно неплохая система эмуляции + сборка сразу в несколько архитектур и единым бинарём. Были механизмы разделения под разные архитектуры, но я с ними уже несколько лет не работаю, подзабыл уже всё

При переходе с 32-битного интела на 64-битный однажды просто отключили поддержку 32-битных приложений. Совсем.

А в остальном да – и жирные бинарники под две архитектуры легко делаются (емнип под виндой формат PE EXE тоже так умеет, но никогда не видел, чтобы этим пользовались), и эмуляция при переходах PowerPC->Intel и x64->ARM сделали, чтобы не больно было.

жирные бинарники под две архитектуры легко делаются (емнип под виндой формат PE EXE тоже так умеет

PE не умеет. Если не считать DOS Stub + Win32 App.
32/64 в одном PE-файле нельзя.

Не так давно вышло расширение Arm64X PE, там можно смешивать x86_64 и AArch64 код в одном бинарнике, правда только в DLL.

Интересно, вот бы такой файл посмотреть. У меня в Visual Studio почему-то недоступен этот таргет.

DOOM2 в опасности?)

Давно уже нет. Можно же собрать из исходников под x64.

Так это то, что уже фактически нельзя поиспользовать. 64-битная винда не умеет запускать 16-битные программы, а из UEFI выпилили в CSM, поэтому в DOS и другие legacy OS не загрузиться.

из UEFI выпилили в CSM

CSM вполне себе жив. Другое дело, что на систему с современным процессором вы не поставите поддерживаемую версию Windows (если не говорить про серверные редакции), потому что, во-первых, единственной поддерживаемой 32-разрядной клиентской виндой осталась Windows 10, которой жить всего пару лет, во-вторых, 32-разрядных драйверов под актуальное железо уже нет.

Да какое там легаси 16 битное, причём то, что уже много лет как отвалилась вся остальная периферия все забывают. То легаси что зависит от выпиливаемых фич ни то что в виртуалках можно запускать, а в полном эмуляторе.

Я думаю тут было бы неплохо вынести всю legacy часть в отдельный сопроцессор и продавать желающим задорого, как часть расширенной поддержки. В него постепенно можно сливать все старые блоки, инструкции, даже зашить "безопасный" эмулятор любого древнего кода. Тогда можно будет вычистить и уменьшить основное ядро.

Слишком дорого будет делать взаимодействие между этими чипами.
Например, встретилась какая-то старая инструкция, которая не распознаётся новым конвейером, как её из середины конвейера вытащить в другой чип? Проще уж програмная эмуляция.

Ну, так пусть декодер знает все команды и раскидывает их куда надо. При обнаружении отсутствия сопроцессора - кидаем ошибку.

Нельзя "раскидать" команду на другой чип, если ресурсы для её выполнения — здесь.
Например, у нас была "устаревшая" команда
mov ax, ds:[bx+si+8]
Как её "раскидать", если все регистры, участвующие в операции — здесь.
И ведь нужно сделать не медленнее, чем сейчас есть, то есть встроить в конвейер. На момент декодирования команды значения регистров нам неизвестны, чтобы переслать их в сопроцессор (и забрать обратно). Да и пересылка займёт десятки тактов, слать между чипами — дело небыстрое, нужен протокол шины.

Ну, с приложениями в юзерспейсе проблем нет – они могут просто работать на "сопроцессоре", и только системные вызовы надо пробрасывать.

Правда, нужно иметь очень вескую причину делать это на "сопроцессоре", а не в эмуляторе.

По сути, двухпроцессорная машина, с x86 и x64 процессорами.
Вспоминаются времена поздних 8/16 биток, где к старому Z80 лепили новый 68K, чтобы обеспечить совместимость.

Да, именно. Имеет смысл, только если производительности эмулятора не хватает.

Ну наконец-то. Давно пора закопать стюардессу.

легаси, это то, что сегодня держит всю эту историю на плаву и сдерживает напор со стороны ARM

Ну так 64 бита это тоже уже весьма дремучее легаси. А 16/32 писалось во времена, когда компьютеры были на порядки слабее современных телефонов, оно может спокойно в эмуляции работать, если кому-то надо.

Вы хотите сказать, что кто-то покупает новые процессоры, чтобы на них крутить 16- и 32-разрядные операционные системы?


Даже если и так, то постепенно всё больше производителей ОС (например, Microsoft, Red Hat и Canonical) отказываются от выпуска 32-разрядных систем.

АГА....местами системы на COBOL еще живы..... и на очень многих заводах КУЧА железа которое держит производственные процессы причем включая реально опасные (химия, нефтянка) где и ISA карты еще активно используются уникальные..... молчу про приложения которые написаны мало того что под умершие ОС (Win 3,11 и OS/2 наприемр) так еще и руками и иногда напрямую в Машинном коде конrретного процессора (привет Вам VIA).....

"химия, нефтянка" это промэлектроника и там до сих пор х8086 можно встретить. Это свой отдельный мир, крайне слабо связанный с бытовыми пк. И там эта новость изменит ровно ничего по крайней мере лет 10-20.

Скорее 30-40. Все в таких сферах накупят себе на склад запас на десятилетия.

Да и если припрет китайцы или еще кто подтянется. Делать небыстрые х86 процы они уже умеют. При наличии рынка добить до того чтобы промышленности подошло можно.

да вот не всё так радужно - если бы речь шла про то что строилось в 80-х или в начале 90-х - там да, всё именно так как вы говорите.

А вот поделия с середины 90-х и до середины 00-х очень и очень своеобразные - там всякое попадается особенно когда Экономили и использовали "Прямые" преобразования и измерения... там такие катафракты встречаются что аж жуть... про код и софт вобще молчу - зачастую написанный Студентами под Диплом или кандидатами под дисер. - вобще никак не документированный и с параметрами который нифига не линейны и не прозрачны.....

с середины 00-х там активный приход микроконтроллеров случился и стало все ГОРАЗДО проще и удобнее - треша и угара стало сильно меньше реально специализированного но открытого и модульного железа больше.....

Время и им закопать стюардесу.

Это далеко не всегда реально - очень часто параметры Техпроцессов намертво привязаны к конкретному оборудованию которое уникальное и под него создан конкретный и уникальный софт с конкретными параметрами... и так чаще всего и очень мало где удается сделать что-то универсальное - ибо дорого....

а еще бывает так что кто-то купил Завод с техпроцессом - но сам ТП не купил.... и вот тогда вобще весело производство нормально работает только пока Входное сырье укладывается в рамки - шаг вправо - шаг влево и всё стопается и Технологи пополам с Инженерами ломают голову, а как же обойти очередное сильно умное ограничение...

И какое им дело до процессоров Intel 2023+ года выпуска?

о никакого пока не встанет и не помрет очередная железка..... а с ней и код и техпроцесс..... опыт + грабли....

Достали свои старые, хорошо забытые "Итаниумы" и объявили это новой архитектурой.

полагаешь - выкопали стюардессу?

Не достали. Хорошо забытые Итаниумы не были х86-64-совместимыми, хотя и имели эмуляцию.

Itanium это VLIW архитектура

Уже раз 5, наверно, вижу сравнение с Итаниумом. А в чём сходство? Там была новая архитектура, а тут просто старое легаси убрали.

интересно - сколько площади это занимало?

Тут больше интерес упростить логическую сложность декодера инструкций.

ожидаете существенный рост производительности за счёт экономии?

Не похоже. Будь там что-то заметно выше погрешности давно сделали бы.

Кмк должно как минимум тепловыделение уменьшиться.
Ну и да, возможно и производительность подрастет. Не прямо "существенно", но измеримо.

Мне вот тоже интересно, каков реальный профит будет от этого в чём?

Может они достигли предела сложности, когда добавление одной новой инструкции ломает 5 старых, и приходится несколько месяцев устранять ошибки и регрессии. А тут одним нажатием DEL чистится 50% кода, и можно продолжать пристраивать новые подпорки.

Да дело даже не в пределе сложности, в конце-концов, они с этим легаси жили десятилетия, наверняка уже взаимодейстивие с ним отполировано по самое нехочу. Просто это место на кристалле, это тепловыделение, это наверняка влияние на быстродействие. А выкинуть это — ещё и камень станет дешевле в производстве, т.к. ядро уменьшится, кристаллов с пластины выйдет больше.

Думаю, нет. Потому что место на кристалле жрёт не сложная логика, вытачиваемая вручную, а то, что штампуется автоматом: память/кеши, арифметика для длинных-длинных регистров (512 бит) и т.п.

Команда архитекторов получила оргазм (как я их понимю!) и теперь может работать в 4 раза быстрее.

То есть отвалится куча старого софта, которое 32 бит.

Может это и не так плохо, верно?

Но ведь есть куча старых добрых игр, которые навсегда остались 32 бит, в лучшем случае.

Как быть здесь?

Если при этом АМД, которые собственно и придумали текущую архитектуру 64 бита, скажут что они продолжат поддержку 32 бит несмотря на решение Интел, что может последовать?

Ждёт ли нас призрак Итаника?

Обратная совместимость, это то чего люди ждали от Интел.

Если этого не станет, то что станет с самим Интел?

Эмуляторов с головой хватит для старых игр. Уже производительности js и прочего браузерного хватает для такого.

То есть отвалится куча старого софта, которое 32 бит.

Нет. Поддержка запуска 32-разрядных приложений в 64-разрядных системах останется.
Отвалится запуск 32-разрядных операционных систем, которые на современных системах всё равно слабо востребованы.


Если же это такая игра, которая требует запуска именно в 32-разрядной системе, то гораздо проще загнать её в виртуальную машину, чем пытаться поставить старую ОС на актуальное железо.


Вот любители позапускать всякое говно мамонта типа Windows XP на современном железе — отвалятся. Но, во-первых, у них уже сейчас этот процесс выглядит как извращенный секс стоя в гамаке (патчить системные файлы, заменять встроенные драйверы на сторонние самописные), а во-вторых — да и чёрт бы с ними.

Описали меня.
Я играю в WoW LK на пиратских серверах на макбуке. Клиент игры только 32 бит, а макос уже не умеет запускать 32 битные приложения.
Приходится играть через вайн на виндоус версии игры.

А Parallels пробовали?

Нет, не пробовал. А в чём смысл? В параллельс тоже виндоус запускать? Или старую версию макос, где ещё есть 32 битная поддержка?

Да хоть Виндовс нескольких версий сразу (у меня например даже XP есть), хоть Линукс какой угодно, хоть всякую другую экзотику. И они все одновременно распрекрасно работают, какие в окошках, а какие – как например XP – прямо в маковскую оболочку встраиваются.

Не прямо всё под ними взлетает – всякие экзотические фуллскрин-видеорежимы в окошках бывает глючат – но в целом старый софт и распространённые игры ок.

На современном железе кста под макосью ВинХР в вирт машине стартует за 2 секунды буквально, это включая совмещение окружения (общий клипборд, диски хост и гест машины взаимно видимы, сеть правильная и всё такое).

Так у меня под вайном клиент игры норм работает.

Описали меня.

Нет, тут, вроде, другой случай. Вы ведь не запускаете 32-разрядную операционную систему.


Ключевое условие, которое выдвигает Intel — чтобы хостовая ОС была 64-разрядная. А уже в ней можно запускать и 32-разрядные приложения (это вам запретила Apple, но тут претензия не к Intel), и Wine, и виртуалку с 32-разрядной операционной системой.

Стоп, как? Wine ж не умеет эмулировать проц/система, т.е. вы ограничены i64 и arm (или только i64, если бук старый).

Или под винду есть 64-битная версия, а под мак нету?

Так это макос выкинула поддержку 32 битных приложений. Под вайном нет проблем запускать 32/64 бита

Столкнулся в своё время с проблемой – Worms Armageddon не запустить. Потому что для запуска 32-битного виндозного бинаря нужен 32-битный wine. А запускается только 64-битный.

Очень интересно. Я даже погуглил.

Тут чекнули экзешик вова и он 32 бита.
https://i.imgur.com/4D725H2.png

На рутрекере в требованиях к вову стоит:
Процессор:
• Минимально: Intel Pentium 4 1.3 GHz или AMD Athlon XP 1500+
• Рекомендуемо: Двухъядерный процессор - Intel Pentium D или AMD Athlon 64 X2

Пентиум 4 и атлон икси никак не 64 битные процессоры. Да и в 2008 году не было ещё популярности на 64 битные системы. В 2007 только вышла виста, т.е. большинство сидело на икспи. А икспи 32 битная система, а икси 64 бита была жуткая экзотика.

Ну вот тогда не зашло, сейчас погуглил – мол, надо crossover или parallels (там и там есть слой эмуляции проца).
Не посмотрите, какая у вас конфигурация wine для запуска 32-битных игр?

Я похоже круто обманул тут всех. А ты прав.
У меня стоит не оригинальный wine, а Wineskin Winery. Это какой-то форк форка Wine.
И там действительно отдельно указывается, что 32 бита поддерживается на 64 битных системах.


Вот мой сетап - https://imgur.com/a/74FWCio
Но я там везде жал далее далее и всё заработало, поэтому даже не заморачивался.

Отлично, спасибо!
Самое смешное – во времена, когда я играл в червей, именно Wineskin Winery и использовал. И после отрезания Эпплом 32-битных приложений – он отвалился.
Посмотрел по вашей ссылке – используется движок wine-crossover. Видимо, пока его пилили – я забросил червей)

Есть же 64-битная win XP. Она должна же , по-идеи, должна также нормально работать, не считая драйверов.

П.С.

Сам любитель запустить Windows 7 на новом железе и использовать для повседневной жизни (для работы - Arch)

Она должна же , по-идеи, должна также нормально работать, не считая драйверов.

А как она будет нормально работать без драйверов? Без драйверов будет облом уже на этапе установки - она накопитель не увидит.

Поэтому для запуска XP и занимаются подсовыванием сторонних драйверов (UniATA), подсовыванием пропатченных драйверов из дистрибутива Windows 7 и прочими извращениями.

НЛО прилетело и опубликовало эту надпись здесь

собственно давно назрело и даже перезрело давно - но в процессе Столько всего вылезет нового, веселого и неприятного - что ИМХО браться за расчиcтку сих "авгиевых конюшен" одной только Интел без поддержки кого-то масштаба Google или M$ по моему не стоит.... Не поймут.....

правда что M$ что Google всё больше в сторону ARM смотрят причем активно.....

Windows RT (ранее известная как Windows 8 ARM)[2] — редакция операционной системы Windows 8 компании Microsoft для планшетных и других компьютеров на базе ARM-процессоров.

https://ru.wikipedia.org/wiki/Windows_RT

смотреть они могут много куда...

Давно пора, а легаси это в большей степени маркетинговая сказка, если не говорить про особо узкие решения. Мне другое интересно модель защиты проца упростили, получается, что не осилили программеры работу с четырьмя кольцами-)))

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости