LINUX.ORG.RU

Intel закрывает инициативу x86S

 , , x86s


0

2

В середине 2023го года, Интел заявил об инициативе x86S — упрощения x86. Инициатива заключалась в полном удалении real-mode, удалении 16-битных инструкций из protected/long mode и частичном удалении 32-битных инструкций (для пользовательского режима 32-битные инструкции оставлялись — удалялись лишь системные).

Помимо этого, под редукцию попадал и механизм VTx — расширения для виртуализации, в котором, до этого, старались сохранять всё необходимое для совместимости с «устаревшими» ОС. Расширение VTx лежит в основе подсистемы linux/KVM, предоставляющей средства для работы виртуальных машин, а значит, работа множества ОС под виртуальными машинами, была бы существенно замедлена.

В конце 2024-го года, инициатива x86S была, наконец, свёрнута. Вместо неё, компания Intel создала рабочую группу с участием AMD и Google, целью которой будет обсуждение дальнейших решений по модификации архитектуры x86. Таким образом, от попыток внесения изменений «явочным порядком» (многие из которых уже оканчивались неудачей, как, например, замена x86 на ia64), Интел впервые решила перейти к обсуждению будущего архитектуры x86 с другими участниками рынка.

>>> Подробности

★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 1)

Мини в основном потому, что новость уже не особо свежая — два месяца прошло как никак.

CrX ★★★★★
()
Ответ на: комментарий от CrX

То есть, над этой новостью уже вьётся небольшой такой рой трупных мух?) Ммм, няшка! Довольные нурглячьи звуки

Dorif ★★★
()
Последнее исправление: Dorif (всего исправлений: 1)

В конце 2024-го года, инициатива x86S была, наконец, свёрнута.

Ну и ладно. Либо китайцы сделают 32-bit only x86 (если уже не), либо intel потеряет ещё долю в embedded/industrial.

Интересно, что у Интеля был очень хороший старт в embedded/industrial с их i8048 и i8051 причём последний вообще стал общепризнанной классикой микроконтроллеров и до сих пор весьма популярен как минимум в качестве MCU core IP для кучи всяких микрух, а вот потом всё посыпалось и даже покупки всяких StrongARM у DEC и выпуск в общем-то годных XScale не привёл в итоге ни к чему хорошему. И вот последнее что могло бы взлететь на этом рынке из-за приличного наследия в виде 32-битного x86 кода и привычки - взяли и похерили.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Ты точно прочитал то, что надо? Инициатива, которую свернули, была о том, чтобы выкинуть (частично) поддержку 32-бит, а не наоборот.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от buddhist

Ну, вообще, выкинуть легаси возрастом в 40-50 лет идея таки хорошая, тем более 16-битными инструкциями сейчас и не пользуются особо, ибо на «голом» современном железе ДОС не загрузишь, он банально про (U)EFI не в курсе и может банально железо не увидеть, а для работы в эмуляторе они и не нужны так-то… Другое дело, что выкидывать часть инструкций для виртуализации - идея уже странная.

Dorif ★★★
()
Ответ на: комментарий от buddhist

Сразу им непонятно было, что это провальная затея?

Не только им. Сколько я тут пытался народу это растолковать? Не верили даже здесь…

anonmyous ★★
() автор топика
Ответ на: комментарий от Stanson

Intel Quark же вроде есть. 32 бита, по сути - х86 МК типа.

Dorif ★★★
()
Ответ на: комментарий от ivanich10

это типа наш ответ ARM?

Нет, ответ АРМу - это, например, риск-v. Хотя тоже тот ещё ответ, но там хоть что-то интересное.

anonmyous ★★
() автор топика
Ответ на: комментарий от Dorif

ибо на «голом» современном железе ДОС не загрузишь, он банально про (U)EFI не в курсе и может банально железо не увидеть

У меня на всех компьютерах был режим BIOS. А MS-DOS скорее всего (хотя я не разбираюсь в нем) использует BIOS для работы с дисками, графикой, поэтому ему не надо знать о железе, о нем знает BIOS.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от Stanson

Либо китайцы сделают 32-bit only x86 (если уже не),

А зачем им её делать? Интел до сих пор производит старые 32бит-онли процы для эмбедщины.

либо intel потеряет ещё долю в embedded/industrial.

Было бы чего терять.

а вот потом всё посыпалось

Да нет, вы путаетесь в датах. Посыпалось у них, может, только последние 7-10 лет. А в те периоды, что вы описываете, они процветали по многим фронтам.

и выпуск в общем-то годных XScale не привёл в итоге ни к чему хорошему.

А к чему он должен был привести? У них не было планов отхода от х86, и конкурировать с самим собой не хотелось.

И вот последнее что могло бы взлететь на этом рынке из-за приличного наследия в виде 32-битного x86 кода

Он бы не работал. Совместимость с 32битными операционками была похерена, а 32битный код в составе вин64 - ну на таком далеко не уедешь, то же мне, «конкурентное преимущество».

взяли и похерили.

Давно пора было.

anonmyous ★★
() автор топика
Ответ на: комментарий от buddhist

А почему это должно было сразу быть понятным? Ну допустим про виртуализацию я нее знал, но вычистить легаси было хорошей идеей.

kirill_rrr ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Многие современные UEFI не имеют режима совместимости, ибо не особо надо так-то. Так что всё правильно, пора его закопать. Правда сейчас это выглядит как та часть анекдота, где стюардессу опять откапывают…

Dorif ★★★
()
Ответ на: комментарий от kirill_rrr

Хоть раз пробовал хоть из сколько-нибудь сложной системы вычистить легаси? А ведь люди про это ещё 2000 с лишним лет назад книжки писали.

buddhist ★★★★★
()
Ответ на: комментарий от CrX

Инициатива заключалась в полном удалении real-mode, удалении 16-битных инструкций из protected/long mode и частичном удалении 32-битных инструкций

Я расценил это как логичное избавление от никому не нужного говна мамонта для сильного упрощения процессора, которое имеет смысл только если хочется получить максимально простой и маложрущий i[345]86. Смысла удалять это всё для какого-нибудь iCore5-13XXX нет вообще, какого-либо заметного выигрыша по площади кристалла или потреблению это не даст.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Я расценил это как логичное избавление от никому не нужного говна мамонта для сильного упрощения процессора, которое имеет смысл только если хочется получить максимально простой и маложрущий i[345]86.

Нет, там сразу загрузка в 64-битном режиме имелась в виду.

Смысла удалять это всё для какого-нибудь iCore5-13XXX нет вообще, какого-либо заметного выигрыша по площади кристалла или потреблению это не даст.

Смысл мне видится в том, что упрощение архитектуры уменьшает площадь для атак и уязвимостей.

Но интел тоже в итоге достаточного смысла не углядели, раз свернули.

CrX ★★★★★
()
Ответ на: комментарий от anonmyous

Интел до сих пор производит старые 32бит-онли процы для эмбедщины.

Со всеми этими 16-тибитными ошмётками, которые вообще не нужны, но ощутимо усложняют эти процы.

Было бы чего терять.

x86 PC104 пока что вполне используются в промышленности, но из-за того что какой-нибудь i486 жрёт и занимает намного больше места чем ARM их доля снижается. Логично было бы сделать из i[345]86 что-то посовременнее с сохранением совместимости.

Да нет, вы путаетесь в датах. Посыпалось у них, может, только последние 7-10 лет. А в те периоды, что вы описываете, они процветали по многим фронтам.

Успеха i8051 они даже близко не достигали никогда. Хотя и x86 когда-то пытались в виде 386EX и 376 на этот рыночек пихнуть.

На рынке PC процветали, а embedded просирали.

А к чему он должен был привести? У них не было планов отхода от х86, и конкурировать с самим собой не хотелось.

К замене неудачного 386EX.

Он бы не работал.

С чего бы? Ну да, пришлось бы какой u-boot портировать вместо доисторического BIOS. А компиляторы уже не использовали 16-битные инструкции при сборке 32-битного кода ещё во времена 386.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Dorif

Учитывая все проблемы UEFI с которыми я столкнулся, у меня больше желания есть что бы закопали именно его. С BIOS всегда все было железно, либо MBR записался, либо нет.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от CrX

Нет, там сразу загрузка в 64-битном режиме имелась в виду.

Зачем тогда вообще что-то 32-битное оставлять?

Смысл мне видится в том, что упрощение архитектуры уменьшает площадь для атак и уязвимостей.

Разве что.

Stanson ★★★★★
()
Ответ на: комментарий от Dorif

ибо на «голом» современном железе ДОС не загрузишь

Загрузишь, конечно.

он банально про (U)EFI не в курсе и может банально железо не увидеть

И что? Он зато в курсе про int13 и int10, которые никуда не девались, по крайней мере если у тебя не бракованная материнка.

firkax ★★★★★
()
Ответ на: комментарий от MOPKOBKA

режим BIOS

🤦

BIOS - это не режим, это короткий синоним к длинному «прошивка x86-совместимой материнки». А то, про что ты говоришь - это традиционное IBM PC/XT/AT BIOS API.

firkax ★★★★★
()

Виртуализацию не трогали б. А всё остальное выкинули. Как и кучу инструкций. 32 бита не нужны.

thegoldone ★★
()
Последнее исправление: thegoldone (всего исправлений: 1)
Ответ на: комментарий от firkax

У меня в настройках UEFI есть два режима загрузки, UEFI где MBR сектор не читается, и второй это как раз BIOS режим.

Ты говоришь скорее всего про разделение real/protected/long, но это вообще про другое, я режимами назвал состояние этого переключателя.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Ответ на: комментарий от Stanson

Зачем тогда вообще что-то 32-битное оставлять?

Чтобы запускать 32-битный софт в 64-битных ОС, как и сейчас.

CrX ★★★★★
()

Инициатива заключалась в полном удалении real-mode, удалении 16-битных инструкций из protected/long mode и частичном удалении 32-битных инструкций (для пользовательского режима 32-битные инструкции оставлялись — удалялись лишь системные).

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

Enthusiast ★★★
()

Удаление 16-битного всего из процессоров - это логично. На 64-битной Windows невозможно запускать 16-битные приложения, а в Linux/UNIX 16-битных приложений никогда не существтвала - поэтому только DOSBox и VirtualBox. Вырезать актуальный и полезный VTx - это фигня.

ConLenov ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Нет, я говорю именно про прошивку материнки. Эта прошивка на x86 материнках называется биосом. Всегда. Биосы бывают разные - есть традиционные IBM PC/XT/AT-совместимые, те которые начались в 80-х годах, если UEFI-биосы с другим апи. Но обычно современные биосы поддерживают оба варианта, причём традиционный режим обычно называется CSM, а вовсе не «биос». Если он где-то называется биосом - значит его делали неграмотные люди. Биос - это вся прошивка целиком, а не какие-то её режимы.

firkax ★★★★★
()
Ответ на: комментарий от DumLemming

Смешно будет, когда какому нибудь абалдую 64 бит окажется маловато

Так уже. AVX-512 подразумевает 512 битные регистры и операции над ними. Но, да, адресную шину не расширяли.

DarkAmateur ★★★★
()
Ответ на: комментарий от firkax

есть UEFI-биосы с другим апи

Так как пишу я, разделяя BIOS и UEFI, и подразумевая под BIOS реализации со старым интерфейсом на прерываниях, пишут и на википедии, и на сайте uefi.org. Язык меняется, поправлять такое использование кажется странным, когда оно так распространено.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от CrX

Чтобы запускать 32-битный софт в 64-битных ОС, как и сейчас.

Ну тогда и 16-бит придётся оставлять по такой логике.

Stanson ★★★★★
()
Ответ на: комментарий от firkax

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

Хотя с появлением s2idle уже не так актуально, но всё же.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Stanson

Чтобы запускать 32-битный софт в 64-битных ОС, как и сейчас.

Ну тогда и 16-бит придётся оставлять по такой логике.

В 64-битном режиме 16-битный софт разве работает?

hateyoufeel ★★★★★
()
Ответ на: комментарий от MOPKOBKA

А вот не надо так делать. Старый интерфейс - традиционный биос, на крайний случай - легаси биос (хотя я не согласен что он легаси), но биос без уточнений - это любая прошивка.

на сайте uefi.org

Нашёл кому верить, там агигаторы сидят примерно того же характера как те что раст в ядро пропихивают.

пишут и на википедии, и

А вот там можно и исправить.

firkax ★★★★★
()
Ответ на: комментарий от hateyoufeel

Нет, это никаким боком не причина. Весь переход из 16 в 64-битный режим занимает, скорее всего, меньше миллисекунды. А с учётом того, что при выходе из спящего режима все таблицы в памяти уже есть, и кроме перестановки нескольких битов в процовом регистре и чтения части таблиц в процовые кеши делать ничего не надо - может быть вообще порядка нескольких микросекунд. В целом время примерно того же порядка как разовое переключение задач при уже работающей ОС.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от buddhist

Да, строители частенько этим занимаются.

Только они ведь могли спроектировать свой х86S с нуля или около того. Работа подобная разработке Атома.

kirill_rrr ★★★★★
()
Ответ на: комментарий от hateyoufeel

В 64-битном режиме 16-битный софт разве работает?

А что ему может помешать? Исполнение инструкций 8086 вроде не запрещено, mov ax,bx прекрасно работает.

Stanson ★★★★★
()
Ответ на: комментарий от kirill_rrr

Только они ведь могли спроектировать свой х86S с нуля или около того.

Получилось бы как с IA-64

CrX ★★★★★
()

Хрена ты баян откопал.

Еще говорят Итаники перестанут выпускать.

vasya_pupkin ★★★★★
()
Последнее исправление: vasya_pupkin (всего исправлений: 1)
Ответ на: комментарий от CrX

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

cobold ★★★★★
()
Ответ на: комментарий от ConLenov

а в Linux/UNIX 16-битных приложений никогда не существтвала

Вообще-то есть живой форк самого Linux на 16 бит - ELKS и порт V7 - Venix

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от Stanson

В 64-битном режиме 16-битный софт разве работает?

А что ему может помешать?

Плоская модель памяти вместо сегментной, как минимум.

hateyoufeel ★★★★★
()
Ответ на: комментарий от ConLenov

а в Linux/UNIX 16-битных приложений никогда не существтвала

Во-первых, Xenix работал на вполне 16-битном i286. А во-вторых, UNIX тащемта на 16-битных процах и была написана. PDP-11 был 16-битным.

Другой вопрос, что кто будет запускать-то это всё говно на реальном железе? Никто.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)

Процессоры пусть лучше делают, уныло что-то совсем для десктопа стало

One ★★★★★
()

Жаль. Действительно, загрузка 32-разрядных ОС на современном железе мало кому нужна (редкие случаи, когда есть какая-то железка, к которой драйверы проприетарные и строго 32-разрядные). Можно было бы и избавиться хотя бы от этого кусочка легаси.

MozillaFirefox ★★★★★
()
Последнее исправление: MozillaFirefox (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.