[opennet][intel]Представлены патчи, реализующие «принципиально новую архитектуру» x32

Это круто, но политика продаж своей продукции от компании Intel как бы намекает, что это не нужно, т.к. процессоров под 32-бита уже не выпускают. А то, что выпускается скоро уйдет в лету.

Это для amd64 вообще-то.

Это как это не выпускают?! А как же 32битные винды на Core i7/i5/i3 запускаются? О_о

Вот это годно :)

А как же 32битные винды на Core i7/i5/i3 запускаются?

Стоп-стоп. Хардварная симуляция инструкций не в счет. Вот покажите мне чистокровный Core i7 с 32-бит архитектурой.

Разве это не баян?

Кстати, не нужно.

Нет такой вещи как 32-бит архитектура. Есть архитектура x86. Данная новость к ней отношения не имеет.

Кстати я не понял, а как адресовать больше 4 гигабайт? Или там как-то можно использовать и 64-битные указатели?

Looks like костыль.

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

X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти.

Кажется, кто-то кого-то изнасиловал.

Atom ? :)

Это почему?!

Хардварная симуляция...

Вы укурились, он нативно их поддерживает и ничего не (си)эмулирует.

Это означает, что софт может по выбору использовать 64- или 32-битные указатели, или после патчей будет только 32-битная адресация? Если второе, то пусть себе этот костыль засунут.

Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков Linux-ядра в компании Intel и создатель таких проектов как syslinux, klibc и LANANA, опубликовал в списке рассылки разработчиков ядра Linux серию патчей, реализованных в рамках проекта X16, нацеленного на создание гибридного x86 ABI с 16-ти битной адресацией памяти.

X16 представляет собой прослойку поверх стандартного x86 ABI ядра, эмулирующую на 32-разрядных системах 16-ти битную модель адресации памяти. Как следствие, приложения могут использовать все преимущества архитектуры x86, такие как дополнительные регистры, более быстрые инструкции, PIC ABI, но в то же время смогут работать с 16-ти битными указателями памяти, что положительно скажется на потреблении памяти, кэша и общей скорости исполнения кода.

Замеры производительности, сделанные разработчиками, показали, что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32% в сравнении с классическим x86 ABI, хотя не исключены ситуации, в которых наблюдается небольшое падение производительности на 0.5-6%. Также ограничением служат запросы приложения к размеру используемой оперативной памяти, которые теперь ограничиваются 64 Кб.

Для реализации X16 ABI разработчикам потребовалось добавить около OVER 9000 строк кода в ядро Linux, а также интегрировать поддержку новой «архитектуры» в пакеты binutils, libc и GCC. Патчи, а также инструкции по сборке и установки можно получить на официальной странице проекта.

А для тупых?

Все ради скорости, при ограничении памяти в 4GB?
Это имеет смысл?

Если второе, то пусть себе этот костыль засунут.

Почему? Есть же много применений, когда больше 4Га и не нужно на процесс.

Ой, у тебя все звезды потухли!

при ограничении памяти в 4GB

Ограничение только для процесса, как я понял. Система может использовать и больше, если не ошибаюсь.

Нет такой вещи как 32-бит архитектура. Есть архитектура x86. Данная новость к ней отношения не имеет.

Рекомендую вспомнить про IA-32 и IA-64, а также разобраться в том, что такое x86 и x86-64. Увы, симулировать 16 доп. проводков на плате никак невозможно (считаем, что неполноценный x86-64 все таки ближе к 64-разрядной адресации, нежели к 32-х).

после патчей будет только 32-битная адресация
пусть себе этот костыль засунут

Почему? Есть же много применений, когда больше 4Га и не нужно на процесс.

Потому что выбор отнимут. Неужели не ясно.

только как замена для i386, а также amd64-систем с малым объёмом памяти. в остальных случаях, как обычно, amd64.

Потому что выбор отнимут

Не, не ясно, откуда вывод.

Ограничение только для процесса, как я понял.

Эти патчи имели смысл несколько лет назад. Теперь много серверных приложиний хочет >4GB. Да и клиентские подтянутся через пару лет. Непонятно.

Проиграл maxcom'у в карты.

Тогда понял, спасибо!.

Не, не ясно, откуда вывод.

Читать научись. И о булевой логике хотя бы вспомни. и/или

Почему? Есть же много применений, когда больше 4Га и не нужно на процесс.

Есть, но пусть они лучше свои процессоры пофиксят, чтобы у них в Long Mode производительность с 64-битными указателями на 32% не проседала, вместо того, чтобы костыли нам в ядро городить.

Для реализации X32 ABI разработчикам потребовалось добавить около 1000 строк кода в ядро Linux, а также интегрировать поддержку новой «архитектуры» в пакеты binutils, libc и GCC

А сколько еще потребуется пакетов переделать. Я так понимаю, что ПО, поддерживающее x86 и не поддерживающее amd64 на этом тоже не запустится.

Почитайте про Long/Legacy Mode для начала. А также задумайтесь над тем какого фига на вашем линуксе имеются либы для запуска 32-бит приложений.

Почитайте про Long/Legacy Mode для начала. А также задумайтесь над тем какого фига на вашем линуксе имеются либы для запуска 32-бит приложений.

Ну это просто фееричный 3.14-здец (именно). Особенно про библиотеки (P.S. не у всех они стоят).

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

Сходи на википедию для начала, просветись, а? Ну так лениво копипастить.

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

Спасибо, только что оттуда вернулся. Я вообще сначала к ней обращаюсь, а потом пишу :) Вобщем, может я не так выразился, это случается, но смысл был в другом, поддержка 32-бит приложений не нужна, когда кругом 64-разрядные процессоры, в которые запихнули возможность работать в режиме 32-разрядов. Проку от этого ну никакого. Разве что, сэкономить на ЗП и чутка времени на переписание + перекомпиляцию прог написанных для 32-битных либ. Сейчас или послезавтра перекомпилировать просто заставят. Рынок просит 64-разрядные процы, память с размером в 16Гб в одной планке и это уже не остановить. А насчет того, что будто 64-разряда это чисто тру 32-разряда это не так. Основы радиоэлектроники вам в помощь. Да, это банальные микросхемы, которым сказать, что вместо 64 проводков на входе тебе не надо юзать половину, увы не так просто. То, что сделали в Intel'е не чудо, а просто переходный период и точка.

Ты альтернативно умный что-ли?

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

Что тебе осталось непонятным? Что ты докопался? O_o

Хм. А какой юз-кейс всего этого дела? Только для проектов, авторы которых не осилили/забили на портирование на x86-64? Много такого софта?

Докопался тут ты. Я спросил, чего не так, если применение этому есть.

Вобщем, может я не так выразился...

Именно, к остальному не имею претензий :)

Тогда вендекапец будет. Под винду х86_64 софт существует в виде исключения.

Это для девайсов, где мало памяти, но хочется использовать amd64.

А multilib эта штука умеет?

И да, что-то не совсем понятно, как это работает. Судя по тому, что есть дополнительные регистры, процессор в Long mode, и процессы выполняются не в compatibility mode, а в настоящем 64-битном. Разве при этом выполняемый код может быть в 32-битном сегменте? (указатели-то 32-битные)

А, понял. Это нетбуки всякие, x86-планшеты (если есть такие). Тогда действительно имеет смысл.

Разве это не баян?

Дайте мне скорей баян
Я оптимизирую его к **ям!

IIRC, x32 - предназначен для работы на реальной железной архитектуре (урезанной нетбучной). То, что он умеет работать поверх amd64 - малозначащая деталь.

То что оно работает поверх amd64 и есть самая значащая деталь.