Здравствуйте, rFLY, Вы писали:

FLY>Неужели дождались? Будет интересно посмотреть насколько это бустанет их процессоры. Правда еще вопрос когда они выйдут.

Вот уберут все это и как бы не оказались полсе этого компьютеры огорожены так же или даже хуже, чем сейчас ARM.

Здравствуйте, rFLY, Вы писали:

FLY>Неужели дождались?
Чего? Проблем с запуском уже имеющегося софта который, внезапно, ещё дофига где 32битный?

FLY>Будет интересно посмотреть насколько это бустанет их процессоры.
Думается что не особо будет заметно.

FLY>прекращение поддержки 16-разрядной адресации;
Это давно сдохло

FLY> запуск процессора сразу в 64-битном режиме;
Ээээ, может я путаю но вроде как это уже и так есть

FLY> работу исключительно с 64-разрядным UEFI;
Аналогично

FLY> ликвидацию первого и второго колец защиты, ненужных для современных ОС;
Не жалко, реально бесполезны

FLY>возможность запуска старых ОС исключительно через эмуляцию.
Да в общем то насрать. Уже давно ОС 64битные ибо 4 гига памяти не хватает ни на что.
Главное чтоб прикладной 32битный софт работал.

Здравствуйте, CRT, Вы писали:

CRT>Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай.
В том то и дело что "если..."

Здравствуйте, CRT, Вы писали:

FLY>> Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро
CRT>что значит "кажется"?
CRT>Что запустить какую то софтину виртуальную машину поднимать?

По моему не все осознают, что нынешние виртуальные машины работают так бодро,
потому что они исполняют родной набор команд на родном процессоре.
Виртуальность заключается лишь в двойном преобразовании адресов.
А когда придётся действительно эмулировать отсутствующие команды, то...
производительность просядет в 10 а может быть и в 100 раз.
На эмуляторы АРМ-ов посмотрите.

Неужели дождались? Будет интересно посмотреть насколько это бустанет их процессоры. Правда еще вопрос когда они выйдут.

Основные описанные в документе Intel нововведения в архитектуре x86S включают: прекращение поддержки 16-разрядной адресации; запуск процессора сразу в 64-битном режиме; работу исключительно с 64-разрядным UEFI; ликвидацию первого и второго колец защиты, ненужных для современных ОС; отключение доступа к портам ввода/вывода из третьего кольца защиты; отмену строковых операций с портами ввода/вывода; ликвидацию контроллера прерываний 8259; а также возможность запуска старых ОС исключительно через эмуляцию.

3Dnews

O>>Это ж тогда никакого яваскрипта не надо будет, всё и так будет еле ползать.
S>Яваскрипт на уровне ядра
Не поможет. Последние годы почти всё ПО, даже мельчайшие хелловорлды, разрабатывается через гигабайты паттернов и микросервисов. Ни новые ОС, ни прикладное ПО не избежит этой участи — 99% процессорного времени и памяти тратить на эту бесполезную хрень. Нужно что-то сначала сделать с засилием в управлении всяких саентологов, которые все эти сектантские ритуалы насаждают. Без этого ускорение аппаратной части будет наполнением дырявой бочки.

_>>Которую забудут реализовать. А отдел саботажа у них всё изобретательнее.
FLY>Что значит забудут реализовать? Оно еще со времен win7 существует.
32хбитные апликухе в вин7 работают не через эмуляцию а прямым исполнением 32хбитного кода на процессоре. Если поддержку 32хбитных инструкций выпилят, то придется делать софтовый транслятор инструкций, по типу розетты в макосе.

Здравствуйте, pagid_, Вы писали:

N>>iAPX432 — не RISC.
N>>IA64 — не RISC.
N>>PPro и наследники — RISC внутри, но не снаружи.
N>>Что остаётся? i960?

_>Если в "попытка перейти на другую архитектуру" "другую" заменить на RISC что-то принципиально изменится?

Да. Потому что RISC — это, начиная с конца 80-х, банально. А у Intel всегда были наполеоновские планы и такого же размаха поражения. Мы же про Intel говорим?
А если не циклиться на нём, то уже неважно, кто будет взамен — вон ARM и RISC-V живые и развиваются, своих пользователей имеют.

Сила и слабость Intel в IBM PC и наследниках, и Windows поверх них. За их пределами x86 нафиг никому не нужен, а без x86 не нужен и Intel (ну, его 90% — есть ещё сетевухи, есть видео, прочие мелкие вкусняшки).

Здравствуйте, rFLY, Вы писали:

FLY>Неужели дождались? Будет интересно посмотреть насколько это бустанет их процессоры. Правда еще вопрос когда они выйдут.

сключительно через эмуляцию

Которую забудут реализовать. А отдел саботажа у них всё изобретательнее.

Здравствуйте, rFLY, Вы писали:

FLY>Неужели дождались?

Нет. 32-битные инструкции никто не убирал.

FLY>Будет интересно посмотреть насколько это бустанет их процессоры.

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

Здравствуйте, rFLY, Вы писали:

FLY>Запуск приложения в режиме совместимости разве не включает эмуляцию х86?
Нет. Проц поддерживает 32битные команды напрямую. Совместимость там скорее на уровне PE loader и API

FLY> Интел подумывает об отказе от 16 и 32 бит поддержке

Опомнился тюлень, зачем ему в море нога! Это надо было делать лет 20 назад. Точнее, это было ОЧЕВИДНО уже 20 лет назад, но жлобьё продолжало доить x86, пока даже инженеры не взвыли "Не вывооооозим!".

Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC? Адаптировать архитектуру под современные потребности и вперёд. Главное — чтобы никаких шпионских IME.

На сегодня почему операционок так мало? Да потому что x86 — это свалка маразма в квадрате, ни один инженер не может в одиночку сделать полноценную систему. Так что самовыпил интела не интересен вообще, пусть уже со своей вонью сидят на обочине. Будущее — оно за адекватными системами.

Здравствуйте, rFLY, Вы писали:

FLY>3Dnews

То есть реально ссылки нет, есть агрегатор хлама, который ссылается на корень сайта вместо точного указания. (Нет, я нашёл через ключевые слова, но всё равно так нехорошо.)

FLY>Неужели дождались? Будет интересно посмотреть насколько это бустанет их процессоры.

Ни на сколько. Уменьшит блок декодирования, но за счёт частей, которые и так обычно отключены.

Основное преимущество будет в сопровождающих компонентах — всяким ME не придётся подлаживаться под существование старых режимов.

FLY>Основные описанные в документе Intel нововведения в архитектуре x86S включают: прекращение поддержки 16-разрядной адресации; запуск процессора сразу в 64-битном режиме;

То есть им нужна замена SMM. Хочу посмотреть, как они тут вывернутся.

FLY> отмену строковых операций с портами ввода/вывода;

Смешно. Кому-то они мешали (ну кроме занятых кодов, которые всё равно нельзя занимать по новой)?

В своём лучшем кретинском стиле Intel они опоздали с этим на 25 лет. Основную работу сделал AMD, по своему тогдашнему нищенству всё равно сделавший 1/3 от необходимого. Но остаток и сейчас Intel не сделает, вместо этого сделав только затычки.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, netch80, Вы писали:

N>>Основную работу сделал AMD, по своему тогдашнему нищенству всё равно сделавший 1/3 от необходимого.

C>А чего не хватает?

Вынос воздействия сегментных регистров на уровень снаружи от страничного каталога, а не внутри него. Это резко бы облегчило виртуализацию (показано опытом IBM).
Возможность работы ядра с выключенной страничной трансляцией, соответственно, лёгкое включение и выключение этой трансляции. Ядру она просто мешает. Можно было сделать в стиле System/Z, SPARC или MMIX Кнута — любой годился.
Достаточное количество регистров. У 64-битного процессора нормально >=25 регистров (32 чтобы круглое), а не 16 (с поправкой на специфику SP, BP... надо считать 13-14).
Хотя бы пригрозить опцией отказа от TSO, которая реально тормозит процессор — и сделать это при первой возможности битами Flags (доступны к управлению из любого режима).
Более качественная формализация SMM, внос в штатный набор режимов.
Очистки кодового пространства — кучу однобайтовых команд можно было сделать двухбайтовыми. Вообще перекодировка многих команд в более адекватные форматы. Декодер всё равно переделывается чуть менее чем полностью.
Выброс заведомо бессмысленных команд типа RCR со сдвигом более 1.

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

Здравствуйте, Osaka, Вы писали:

O>Это ж тогда никакого яваскрипта не надо будет, всё и так будет еле ползать.

Яваскрипт на уровне ядра

Здравствуйте, kov_serg, Вы писали:

_>Которую забудут реализовать. А отдел саботажа у них всё изобретательнее.
Что значит забудут реализовать? Оно еще со времен win7 существует.

Здравствуйте, rFLY, Вы писали:

FLY>Здравствуйте, kov_serg, Вы писали:

_>>Которую забудут реализовать. А отдел саботажа у них всё изобретательнее.
FLY>Что значит забудут реализовать? Оно еще со времен win7 существует.
Ну ну. После такого превращения в тыкву. ARM займет все ниши.

Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай.

Здравствуйте, rFLY, Вы писали:

FLY>Выполнение 32-битных приложений еще в Вин7 x64 было реализовано.
Это совсем не то. Проц 32битные команды то до сих пор поддерживает. Но если этот кусок выкинут из железа то будет ой.

Здравствуйте, rFLY, Вы писали:

FLY>Оно еще со времен win7 существует.
Ещё функционал в железе не отрезали а оно уже существует

Здравствуйте, vsb, Вы писали:

vsb>Видел предположения, что это ускорит включение, в частности выход из спящего режима.
На сколько наносекунд?

vsb> Но не уверен, что это действительно так. Предполагаю — просто убирают старый мусор, который уже никому не нужен. Скорей всего ничего это не бустанёт.
Да просто меньше микрокода в декодере команд станет. Станет ли от этого оно работать чуточку быстрее — хз. А вот то, что придётся гонять уже полноценный JIT для 32битного кода — это как раз будет тормозить.

FLY>>>Запуск приложения в режиме совместимости разве не включает эмуляцию х86?
CC>>Нет. Проц поддерживает 32битные команды напрямую. Совместимость там скорее на уровне PE loader и API
FLY>Мне казалось что этот режим был калькой с того, что МС сделала для Itanium.
Нет, для итаниума был бинарный транслятор, а x86-32 инструкции исполняются напрямую на x86-64 процессоре.

FLY>В любом случае это другая тема, об отказе от 32-битных приложений речи не идет.
Тема такая что если это будет сделано через трансляцию то оно будет тормозззззить.

Здравствуйте, rFLY, Вы писали:

CRT>>Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай.
FLY> Но даже откажись Интел полностью от поддержки старых приложений, то что за софт ты используешь, чтобы переживать на этот счет?
FLY>Что-то вроде винампа или игр?

ну если ты используешь компьютер только чтобы музыку слушать и играть то многие используют его для работы. Для решения рабочих задач. Есть куча специализированного софта. Много которого давно написано и до сих пор поддерживается и продается и он 32 битный

FLY> Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро
что значит "кажется"?
Чтобы запустить какую-нибудь софтину виртуальную машину поднимать?

Здравствуйте, netch80, Вы писали:

N>Вынос воздействия сегментных регистров на уровень снаружи от страничного каталога, а не внутри него. Это резко бы облегчило виртуализацию (показано опытом IBM).
N>Возможность работы ядра с выключенной страничной трансляцией, соответственно, лёгкое включение и выключение этой трансляции. Ядру она просто мешает. Можно было сделать в стиле System/Z, SPARC или MMIX Кнута — любой годился.
N>Достаточное количество регистров. У 64-битного процессора нормально >=25 регистров (32 чтобы круглое), а не 16 (с поправкой на специфику SP, BP... надо считать 13-14).
N>Хотя бы пригрозить опцией отказа от TSO, которая реально тормозит процессор — и сделать это при первой возможности битами Flags (доступны к управлению из любого режима).
N>Более качественная формализация SMM, внос в штатный набор режимов.
N>Очистки кодового пространства — кучу однобайтовых команд можно было сделать двухбайтовыми. Вообще перекодировка многих команд в более адекватные форматы. Декодер всё равно переделывается чуть менее чем полностью.
N>Выброс заведомо бессмысленных команд типа RCR со сдвигом более 1.
Проще говоря нафиг эту архитектуру, есть же ARM и гемороя меньше будет. И эмуляция 32битных интелов уже работает.

Здравствуйте, alpha21264, Вы писали:

FLY>>> Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро
CRT>>что значит "кажется"?
CRT>>Что запустить какую то софтину виртуальную машину поднимать?

A>По моему не все осознают, что нынешние виртуальные машины работают так бодро,
A>потому что они исполняют родной набор команд на родном процессоре.

И потому что им помогают в опознании всех проблемных мест.
Не редуцируясь до Попека-Голдберга (что слишком жёстко и только один из вариантов), но когда например SMSW не была привилегированной, всё было сильно сложнее.

A>Виртуальность заключается лишь в двойном преобразовании адресов.
A>А когда придётся действительно эмулировать отсутствующие команды, то...
A>производительность просядет в 10 а может быть и в 100 раз.
A>На эмуляторы АРМ-ов посмотрите.

Вообще-то это давно неплохо решается — см. qemu.
Исходной странице кода эмулируемого процессора ставится результат трансляции в машинный код хозяйского процессора. Такой себе JIT из ассемблера в ассемблер. Замедление есть, конечно, но не 100 раз. Иногда даже меньше чем в 10.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>у нас будут свои, Российские.

И только старый Попугай
Громко крикнул из ветвей:
......

Здравствуйте, CreatorCray, Вы писали:

FLY>>Будет интересно посмотреть насколько это бустанет их процессоры.
CC>Думается что не особо будет заметно.

+100

FLY>>прекращение поддержки 16-разрядной адресации;
CC>Это давно сдохло

Работает, можно применять и чистый реальный, и V86 (но в том что зовётся legacy mode.
В long mode включить их нельзя, AFAIK.)

FLY>> запуск процессора сразу в 64-битном режиме;
CC>Ээээ, может я путаю но вроде как это уже и так есть

Нет (если открыто). Входишь в реальный режим.
А вот дальше одно из первых действий любого BIOS — включение или защищённого, или "нереального" режима (где граница адресации — 4GB).

FLY>>возможность запуска старых ОС исключительно через эмуляцию.
CC>Да в общем то насрать. Уже давно ОС 64битные ибо 4 гига памяти не хватает ни на что.
CC>Главное чтоб прикладной 32битный софт работал.

Это вроде ещё собираются позволить.

Здравствуйте, rFLY, Вы писали:

А я что-то не понял в предполагаемом исходнике: страница 14:
если "paging is always enabled", кто заполняет начальные страничные каталоги всех уровней?
Эту задачу свалили на ME?

Здравствуйте, rFLY, Вы писали:

Здравствуйте, CreatorCray, Вы писали:

CC>Чего? Проблем с запуском уже имеющегося софта который, внезапно, ещё дофига где 32битный?
Выполнение 32-битных приложений еще в Вин7 x64 было реализовано. 32-битные операционки ты не сможешь запускать. Но у многих ли сейчас стоит винХР к примеру?

CC>"Не особо будет заметно", "давно сдохло", "не жалко", "насрать"?
Вот и Интел посчитала, что все это можно выбросить. А на освободившееся место можно будет добавить что-то более актуальное.

Здравствуйте, Michael7, Вы писали:

M>Вот уберут все это и как бы не оказались полсе этого компьютеры огорожены так же или даже хуже, чем сейчас ARM.
А что из "всего этого" тебе нужно?

Здравствуйте, sambl74, Вы писали:

S>Яваскрипт на уровне ядра

Здравствуйте, rFLY, Вы писали:

M>>Вот уберут все это и как бы не оказались полсе этого компьютеры огорожены так же или даже хуже, чем сейчас ARM.
FLY>А что из "всего этого" тебе нужно?

Запуск своей операционки. Например, просто Линукса.
А уж что для этого нужно — это нужно системных программистов спрашивать.

Здравствуйте, netch80, Вы писали:

N>Основную работу сделал AMD, по своему тогдашнему нищенству всё равно сделавший 1/3 от необходимого.

А чего не хватает?

Здравствуйте, RonWilson, Вы писали:

S>>Яваскрипт на уровне ядра
RW>

а что смешного, в каком-то варианте ARM была нативная поддержка java-байткода (во времена j2me на телефонах). Не javascript конечно, но всё равно не взлетело почему-то

Здравствуйте, ononim, Вы писали:

O>32хбитные апликухе в вин7 работают не через эмуляцию а прямым исполнением 32хбитного кода на процессоре. Если поддержку 32хбитных инструкций выпилят, то придется делать софтовый транслятор инструкций, по типу розетты в макосе.
Запуск приложения в режиме совместимости разве не включает эмуляцию х86?

Здравствуйте, CRT, Вы писали:

CRT>Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай.
Об отказе от 32-битных инструкций речи не идет, не сможешь нативно запускать 32-битную ОС. Но даже откажись Интел полностью от поддержки старых приложений, то что за софт ты используешь, чтобы переживать на этот счет? Что-то вроде винампа или игр? Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро. А когда и если такие процы выпустят, допустим (хотя наврядли так скоро) лет через 5, и подавно. Это же не Apple, диктовать свои правила не получится.

Здравствуйте, wl., Вы писали:

wl.>в каком-то варианте ARM была нативная поддержка java-байткода (во времена j2me на телефонах). Не javascript конечно
Это ж капец какие разные сЦущности!

wl.> но всё равно не взлетело почему-то
Почему то

Здравствуйте, netch80, Вы писали:

N>То есть реально ссылки нет, есть агрегатор хлама, который ссылается на корень сайта вместо точного указания. (Нет, я нашёл через ключевые слова, но всё равно так нехорошо.)
Они почему-то всегда дают ссылку на сайт, а не на статью/новость (может политика сайта такая, я хз). Но я не понимаю твоих претензий, тебя же это заинтересовало.

N>Ни на сколько. Уменьшит блок декодирования, но за счёт частей, которые и так обычно отключены.
Один блок уменьшится, значит другой, более востребованный, можно будет увеличить.

N>Смешно. Кому-то они мешали (ну кроме занятых кодов, которые всё равно нельзя занимать по новой)?
Это как лыжи на балконе из которых ты вырос, вроде и не мешают, только лучше вместо них хранить то, чем пользуешься.

N>В своём лучшем кретинском стиле Intel они опоздали с этим на 25 лет. Основную работу сделал AMD, по своему тогдашнему нищенству всё равно сделавший 1/3 от необходимого.
Согласен, но думается у них нет такой возможности, как у компаний, которые разрабатывают процессоры только для себя.

N>Но остаток и сейчас Intel не сделает, вместо этого сделав только затычки.
Посмотрим. Им сейчас надо не только с AMD, но и с ARM конкурировать. Так что любое улучшение будет на счету.

Здравствуйте, CreatorCray, Вы писали:

CC>Это совсем не то. Проц 32битные команды то до сих пор поддерживает. Но если этот кусок выкинут из железа то будет ой.
Так речи об выбросе 32-битных инструкций не идет.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, rFLY, Вы писали:

FLY>>Запуск приложения в режиме совместимости разве не включает эмуляцию х86?
CC>Нет. Проц поддерживает 32битные команды напрямую. Совместимость там скорее на уровне PE loader и API
Мне казалось что этот режим был калькой с того, что МС сделала для Itanium. В любом случае это другая тема, об отказе от 32-битных приложений речи не идет.

Здравствуйте, CreatorCray, Вы писали:

CC>Ещё функционал в железе не отрезали а оно уже существует
Не понял, о чем ты? Разве запуск 32-битных приложений в Win64 на тот момент требовал каких-то изменений в железе?

Здравствуйте, rFLY, Вы писали:

CC>>Это совсем не то. Проц 32битные команды то до сих пор поддерживает. Но если этот кусок выкинут из железа то будет ой.
FLY>Так речи об выбросе 32-битных инструкций не идет.

А что тогда понимается под "отказ от 32 бит"?
Или там Рабинович, как водится, шепелявил когда пел?

Здравствуйте, kov_serg, Вы писали:

_>Проще говоря нафиг эту архитектуру, есть же ARM и гемороя меньше будет. И эмуляция 32битных интелов уже работает.

Ну если будут продаваться десктопы на ARM с количественными характеристиками и свободой сходной с текущим x86 (даже с учётом современного огораживания типа ME) — то да.

Если нет — надо смотреть, кто эту свободу ещё сохраняет. AMD вроде пока не вводит те же огораживания как этот x86S?

Здравствуйте, Baiker, Вы писали:

B>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC?
И сколько уже попыток сделать это было у Интела?

Здравствуйте, pagid_, Вы писали:

B>>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC?
_>И сколько уже попыток сделать это было у Интела?

А сколько?
iAPX432 — не RISC.
IA64 — не RISC.
PPro и наследники — RISC внутри, но не снаружи.
Что остаётся? i960?

Здравствуйте, Baiker, Вы писали:

B>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC? Адаптировать архитектуру под современные потребности и вперёд.

Ещё одна система команд, сколько десятилетий на неё будут переходить?

B>На сегодня почему операционок так мало? Да потому что x86 — это свалка маразма в квадрате, ни один инженер не может в одиночку сделать полноценную систему.

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

Не согласны — ну-тко сделайте эффективный VM layer в Mach парадигме и под ним BIO.
Хотя нет, начните с эффективного namei lookup с защитой от кольцевых каталогов в FS.
А я посмотрю на реализацию и посмеюсь...

B> Так что самовыпил интела не интересен вообще, пусть уже со своей вонью сидят на обочине. Будущее — оно за адекватными системами.

FLY>Неужели дождались?

Это не должно волновать, всё равно в России таких процессоров не будет,
у нас будут свои, Российские.

Здравствуйте, netch80, Вы писали:

N>iAPX432 — не RISC.
N>IA64 — не RISC.
N>PPro и наследники — RISC внутри, но не снаружи.
N>Что остаётся? i960?

Если в "попытка перейти на другую архитектуру" "другую" заменить на RISC что-то принципиально изменится?

Здравствуйте, CreatorCray, Вы писали:

CRT>>Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай.
CC>В том то и дело что "если..."

Эппл вроде ж выкинула поддержку 32 бит приложений в макоси ещё перед переходом на arm. Или нет?
Линуховые дистры хотели выкинуть поддержку x86 32 по умолчанию, но началось бурление, и опционально ради игр под wine и стима, оставили.

Здравствуйте, Артём, Вы писали:

Аё>Линуховые дистры хотели выкинуть поддержку x86 32 по умолчанию, но началось бурление, и опционально ради игр под wine и стима, оставили.
На М1 через wine прекрасно работают виндовые 32битные аппы, так что можно было и там выкинуть.