Здравствуйте, CRT, Вы писали:
FLY>> Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро CRT>что значит "кажется"? CRT>Что запустить какую то софтину виртуальную машину поднимать?
По моему не все осознают, что нынешние виртуальные машины работают так бодро,
потому что они исполняют родной набор команд на родном процессоре.
Виртуальность заключается лишь в двойном преобразовании адресов.
А когда придётся действительно эмулировать отсутствующие команды, то...
производительность просядет в 10 а может быть и в 100 раз.
На эмуляторы АРМ-ов посмотрите.
Течёт вода Кубань-реки куда велят большевики.
Re[5]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, alpha21264, Вы писали:
FLY>>> Мне кажется уже сейчас это всё в режиме эмуляции должны идти бодро CRT>>что значит "кажется"? CRT>>Что запустить какую то софтину виртуальную машину поднимать?
A>По моему не все осознают, что нынешние виртуальные машины работают так бодро, A>потому что они исполняют родной набор команд на родном процессоре.
И потому что им помогают в опознании всех проблемных мест.
Не редуцируясь до Попека-Голдберга (что слишком жёстко и только один из вариантов), но когда например SMSW не была привилегированной, всё было сильно сложнее.
A>Виртуальность заключается лишь в двойном преобразовании адресов. A>А когда придётся действительно эмулировать отсутствующие команды, то... A>производительность просядет в 10 а может быть и в 100 раз. A>На эмуляторы АРМ-ов посмотрите.
Вообще-то это давно неплохо решается — см. qemu.
Исходной странице кода эмулируемого процессора ставится результат трансляции в машинный код хозяйского процессора. Такой себе JIT из ассемблера в ассемблер. Замедление есть, конечно, но не 100 раз. Иногда даже меньше чем в 10.
The God is real, unless declared integer.
Re: Интел подумывает об отказе от 16 и 32 бит поддержке
FLY> Интел подумывает об отказе от 16 и 32 бит поддержке
Опомнился тюлень, зачем ему в море нога! Это надо было делать лет 20 назад. Точнее, это было ОЧЕВИДНО уже 20 лет назад, но жлобьё продолжало доить x86, пока даже инженеры не взвыли "Не вывооооозим!".
Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC? Адаптировать архитектуру под современные потребности и вперёд. Главное — чтобы никаких шпионских IME.
На сегодня почему операционок так мало? Да потому что x86 — это свалка маразма в квадрате, ни один инженер не может в одиночку сделать полноценную систему. Так что самовыпил интела не интересен вообще, пусть уже со своей вонью сидят на обочине. Будущее — оно за адекватными системами.
Re[2]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, Baiker, Вы писали:
B>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC?
И сколько уже попыток сделать это было у Интела?
Re[3]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, pagid_, Вы писали:
B>>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC? _>И сколько уже попыток сделать это было у Интела?
А сколько?
iAPX432 — не RISC.
IA64 — не RISC.
PPro и наследники — RISC внутри, но не снаружи.
Что остаётся? i960?
The God is real, unless declared integer.
Re[2]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, Baiker, Вы писали:
B>Впрочем, кастрат x86S не более полезен, чем кольца 0,1,2,3; Если уж горит сарай, то почему бы сразу не перейти на RISC? Адаптировать архитектуру под современные потребности и вперёд.
Ещё одна система команд, сколько десятилетий на неё будут переходить?
B>На сегодня почему операционок так мало? Да потому что x86 — это свалка маразма в квадрате, ни один инженер не может в одиночку сделать полноценную систему.
Просто сделать операционку на x86 даже проще, чем на остальных — потому что железо на каждом углу.
А вот сделать чтобы выполняло одновременно 100500 противоречивых требований — будет сложно с любой архитектурой.
Не согласны — ну-тко сделайте эффективный VM layer в Mach парадигме и под ним BIO.
Хотя нет, начните с эффективного namei lookup с защитой от кольцевых каталогов в FS.
А я посмотрю на реализацию и посмеюсь...
B> Так что самовыпил интела не интересен вообще, пусть уже со своей вонью сидят на обочине. Будущее — оно за адекватными системами.
The God is real, unless declared integer.
Re: Интел подумывает об отказе от 16 и 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% — есть ещё сетевухи, есть видео, прочие мелкие вкусняшки).
The God is real, unless declared integer.
Re[3]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, CreatorCray, Вы писали:
CRT>>Если 32-битные приложения будут продолжать работать, как сейчас в 64-битных ОС, то пускай. CC>В том то и дело что "если..."
Эппл вроде ж выкинула поддержку 32 бит приложений в макоси ещё перед переходом на arm. Или нет?
Линуховые дистры хотели выкинуть поддержку x86 32 по умолчанию, но началось бурление, и опционально ради игр под wine и стима, оставили.
Re[4]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, Артём, Вы писали:
Аё>Линуховые дистры хотели выкинуть поддержку x86 32 по умолчанию, но началось бурление, и опционально ради игр под wine и стима, оставили.
На М1 через wine прекрасно работают виндовые 32битные аппы, так что можно было и там выкинуть.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Intel передумала отказываться от поддержки 16 и 32 бит
Здравствуйте, rFLY, Вы писали:
FLY>Неужели дождались? Будет интересно посмотреть насколько это бустанет их процессоры. Правда еще вопрос когда они выйдут.
FLY>
FLY>Основные описанные в документе Intel нововведения в архитектуре x86S включают: прекращение поддержки 16-разрядной адресации; запуск процессора сразу в 64-битном режиме; работу исключительно с 64-разрядным UEFI; ликвидацию первого и второго колец защиты, ненужных для современных ОС; отключение доступа к портам ввода/вывода из третьего кольца защиты; отмену строковых операций с портами ввода/вывода; ликвидацию контроллера прерываний 8259; а также возможность запуска старых ОС исключительно через эмуляцию.
Intel официально подтвердила, что прекращает разработку x86S — упрощённой версии архитектуры x86, предназначенной для работы исключительно в 64-битном режиме.
Набор инструкций x86S был впервые представлен в мае 2023 года, когда Intel опубликовала его черновой вариант, а в сентябре этого года обновила до версии 1.2. Основная идея заключалась в «очистке» архитектуры x86 от устаревших элементов, которые практически не используются, но «тянутся» от 32-битных и даже более старых систем, и упрощении архитектуры для современных задач. Однако теперь проект официально завершён, сообщает Tom's Hardware.
Здравствуйте, wl., Вы писали:
wl.>а что смешного, в каком-то варианте ARM была нативная поддержка java-байткода (во времена j2me на телефонах). Не javascript конечно, но всё равно не взлетело почему-то
И сейчас в некоторых есть. Удобно для Android, но современные JIT-компиляторы, по-моему, свели всю затею на нет.
Re[2]: Intel передумала отказываться от поддержки 16 и 32 бит
Здравствуйте, 4058, Вы писали:
4>Свежие вести с полей:
Intel официально подтвердила, что прекращает разработку x86S — упрощённой версии архитектуры x86, предназначенной для работы исключительно в 64-битном режиме.
Не осилили. И всё будет как было.
Re[3]: Intel передумала отказываться от поддержки 16 и 32 бит
Здравствуйте, kov_serg, Вы писали:
k> Intel официально подтвердила, что прекращает разработку x86S — упрощённой версии архитектуры x86, предназначенной для работы исключительно в 64-битном режиме. k> Не осилили. И всё будет как было.
Здравствуйте, rFLY, Вы писали:
CC>>Это совсем не то. Проц 32битные команды то до сих пор поддерживает. Но если этот кусок выкинут из железа то будет ой. FLY>Так речи об выбросе 32-битных инструкций не идет.
Там нет каких-то особых 32-битных инструкций. Инструкции одни и те же, режим исполнения и семантика немного разные.
Re[6]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, Maniacal, Вы писали:
wl.>>а что смешного, в каком-то варианте ARM была нативная поддержка java-байткода (во времена j2me на телефонах). Не javascript конечно, но всё равно не взлетело почему-то M>И сейчас в некоторых есть. Удобно для Android, но современные JIT-компиляторы, по-моему, свели всю затею на нет.
ну нет, с андроидом точно никак не связано. По патентным соображениям, java/kotlin на андроиде компилируется в DEX, регистровый байт-код, в отличие от стэкового байткода Java
Re[2]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, CreatorCray, Вы писали:
CC>Да в общем то насрать. Уже давно ОС 64битные ибо 4 гига памяти не хватает ни на что. CC>Главное чтоб прикладной 32битный софт работал.
Разве его не сломали уже давно? — пионером как всегда, выступила Apple, потом линухи подтянулись, было бурление говен про игрули, и какие-то костыли всё же прикрутили т.е. под winehq 32bit оставили поддержку.
Re[4]: Интел подумывает об отказе от 16 и 32 бит поддержке
Здравствуйте, alpha21264, Вы писали:
A>Запуск своей операционки. Например, просто Линукса.
Похоже, что Snapdragon X полностью слился на линухе и про него забыли. А между AMD и Intel — Линух намного лучше работает с AMD Zen 5 из коробки, в сравнении с Lunar Lake.
The Xe2 graphics performance under Linux was disappointingly slow with it performing even worse than Meteor Lake while RDNA3.5 graphics led.
The performance of this 8-core Core Ultra 7 256V SoC is poor in real-world multi-threaded scenarios and the performance-per-Watt is only compelling in a subset of workloads. The AMD Ryzen AI 9 365 and AMD Ryzen AI 9 HX 370 Zen 5 SoCs tended to deliver the superior performance and power efficiency under Linux.
Это надо было делать лет 20 назад. Точнее, это было ОЧЕВИДНО уже 20 лет назад, но жлобьё продолжало доить x86, пока даже инженеры не взвыли "Не вывооооозим!".
