Pull to refresh

Comments 34

Я так полагаю, что текущая х86-64 архитектура тащит за собой уйму устаревшего «кода» исключительно с целью поддержки совместимости. Поэтому вся эта инициатива увязла бы в невозможности пойти дальше, не отказавшись от костылей прошлого.

Всегда было интересно, почему нельзя «просто» поставить условный x86 сопроцессор (как то же графическое ядро), и переключиться на те же 64 бита, без обеспечения обратной совместимости с древнючим 8086 процессором.

При чем условный х86-сопроцессор можно вообще как отдельную pci плату делать (опыт есть, в виде зионов phi как карта расширения), кому прям нужна совместимость - вот оно.

Потому что в реальности 32-разрядный и 64-разрядный код перемешан между собой.

А более глубокая проблема в том, что кому вообще нужен будет процессор от Intel без поддержки старого кода, если тогда проще взять ARM?

Ну перемешан не совсем верное определение. Множества старых и новых команд пересекаются, да. Но тут речь идет скорее не о командах add и mov (выкинуть 1-4 байтовые версии и оставить только 8 байтовые?..) как таковых, а о более сложных и комплексных механизмах, таких как скедулинг процессов, менеджмент памяти, уровни исполнения кода и тд

Но судя по тому же м1-4 о аппле - можно даже совсем отказаться от совместимости и пользоваться эмуляцией.

А вот проиграть гонку из-за прицепа, тянущего назад… история покажет.

У Apple совсем другая модель экосистемы. Пользователи Apple готовы к тому, что приложения 10-летней давности не будут работать вообще никак, а всё остальное разработчики быстренько перекомпилируют. А Intel стоит на 30-летних вложениях в бинарники Windows. И все там наверняка помнят судьбу Itanium.

Прицеп хоть и тянет назад, но без него у Intel x86-64 вообще нет шансов, так как это сама по себе в своей основе старая архитектура, не очень-то адекватная сегодняшним реалиям. Переменная длина команд, небольшое количество регистров, двухадресный формат - одно тянет другое, а в фундаменте этот самый прицеп.

приложения 10-летней давности не будут работать вообще никак

99% пользователей виндовса это тоже не нужно

Оставшегося 1% тоже много. У кого-то старая любимая игрушка, у кого-то (как у меня) миди-редактор из 90-х - под него приходится виртуальную XP держать, древняя, но нужная программа запускающаяся под икс-сервером... и т.п...

Но ведь десятилетняя программа под WinXP как будто бы может быть дешевле эмулирована на чём угодно
Если есть достаточно точный эмулятор железа (не только проца, очев)

Но ведь десятилетняя программа под WinXP как будто бы может быть дешевле эмулирована на чём угодно

Это у вас получились танки Т34 рассекающие поля Первой Мировой. :-)

Программам под WinXP четвертак скоро.

Это все прекрасно и в режиме полной эмуляции работать будет. Но кто то из читателей видимо настолько не согласен что аж кушать не может.

Или программа для управления МРТ от какого-нибудь Сименса.

И вот таких промышленных очень много. И это огромный рынок

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

Собственно, DM&P с их Vortex86 так и делают.

во многих предприятиях ПО написано под win32, с середины 90х. если не использовали какие-либо забубённые com-Объекты или хаки совместного win16\win32 - вполне работоспособны и сейчас.

С появления 64 бит Mac OS X 10.6 Snow Leopard 2009 года уже 15 лет прошло. С Windows XP Professional x64 Edition (2005) прошло четверть века. Если с тех пор приложения не обновлялись, то их только в виртуалке с нужной версией операционки запускать...

Эппл столько раз меняла платформу, что там все привыкли. И опыт у эппла в этом тоже соответствующий.

На эппл нет промышленного/банковского и тд софта, работающего десятилетия

А более глубокая проблема в том, что кому вообще нужен будет процессор от Intel без поддержки старого кода, если тогда проще взять ARM?

Однопоточная производительность вроде бы совсем не та.

Половина Win11 до сих пор 32-битная, а кое-где и 16-битные COM-файлы лежат (не знаю, насколько они нужны)

Современные программы почти все 64-битные.

Есть немного 32-битных по причине «работают, не трогай».

Даже Windows ARM64 при чистой установке запускает x86 программы как 64 так и 32 бит.

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

То современные. Но Windows - в основном корпоративная ОС, а в компаниях может быть софт, написанный в далеком 2003 году под WindowsXP, который до сих пор работает и решает бизнес-задачи, и переписывать его сейчас только потому кто-то там придумал новую архитектуру или новые иконки - верх идиотизма и к тому же очень дорого (это не оперсорс, не перекомпилируешь, т.е. заказывай разработку с нуля + тестирование + ввод в эксплуатацию + обучение персонала + поддержка)

Конечно может быть такой софт.

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

Не бэкофисом единым... Производственные службы на десктопном софте сидят чуть менее, чем полностью.

Ну и с сайтами тоже всё не так просто. На днях буквально решал задачку, как запустить приложение на базе Java Web Start с минимальным использованием древнего софта...

А вот за это спасибо! Сам не нагуглил и завёл в итоге Palemoon (актуальную версию на актуальной убунте) с древней Java (8u261). Сейчас попробовал OpenWebStart - работает (только способ запуска неподписанных JAR пришлось загуглить).

Эта инициатива не запрещала запускать 32-битный код в принципе. Она делала невозможной запуск 32-битных ОС, запуск которых на современных десктопных процессорах действительно мало кому нужен (а для тех, кому таки нужен, существуют виртуальные машины).

скорее всего, поддержка этой обратной совместимости не настолько сложна. обновил прошивку с микрокодом - вот тебе и поддержка. это лет 30 назад всё в железе было непосредственно только.

была создана в начале этого года в октябре

У кого то знатно удались новогодние праздники ? )

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

"уровни функций архитектуры AMD64 и x86-64 — это «полностью сломанный мусор», который «должен умереть»."

- это вообще не относится к архитектуре x86, это реакция на предложение программиста вместо того, чтобы смотреть на биты CPUID по поводу того, что поддерживает процессор, ввести некие константы - типа x86 уровень 1 - значит один набор инструкций, уровень 2 - побольше, и писать код опираясь на эти константы, а не на реально поддерживаемые CPU функции.

+1

Собственно, эта новость как раз и является подтверждением слов Линуса. Хрякс, и вот новые процессоры сильно урезаны по сравнению со старыми. Какая тут монотонность фич?

Какой-то жёлтый заголовок и статья. По факту ничего не прекратилось, просто иювсё перешло в "опен сорс" (отраслевой), т.к. Интел щдраво рассудило, что в своём текущем положении ей в одиночку лямку не потащить. Нужен buy in от AMD.

Sign up to leave a comment.

Other news