H.J. Lu анонсирует x32-abi

И в чем преимущества этой архитектуры?

derlafff> И в чем преимущества этой архитектуры?

Приложения будут кушать чуть меньше памяти.

«предлагает 32-битный размер указателей, и возможно будет востребованной для устройств и систем не обладающих большими объемами оперативной памяти»

Как бы в новости всё написано же.

Что-то сильно смахивает на утонченный маразм.

Ниасилил. А разве у 64х битной архитектуры есть какие-то еще преимущества кроме 64х битных указателей?

И нафиг оно нужно? Для встроенных решений актуальнее возможность адресовать флеш-память как оперативную

больше регистров ?

возможно, если бы этим занимался кто-то еще, но от H.J. Lu маразма ждать не приходится, он в мире Линукс человек номер 1 от Intel, автор libc5 (той самой что была до Glibc, многие наверное и не помнят) и один из ведущих разработчиков binutils и GCC

есть не только embedded решения, но и решения на рынке виртуализации например, там пока в тарифной сетке превалируют сравнительно дешевые решения до 2 Gb RAM, и в обозримом будущем пока будут.

угу, и linux как бесплатный полигон для очередной дури от Штеуд.))

>он в мире Линукс человек номер 1 от Intel

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

Всё правильно делают.

ну а на чем, точнее на ком еще тестировать? ) только на добровольных энтузиастах, они ж и сами рады будут еще )

Целочисленные операции над большими числами же. Разрядность процессора обычно обозначает в первую очередь разрядность регистров общего назначения.

Мастдай семерочка станет? =)

И урезаем виртуальную память. Я бы никогда не стал платить за vps на якобы x86_64 где нельзя за-mmap'ить пару терабайтов.

> «предлагает 32-битный размер указателей, и возможно будет востребованной для устройств и систем не обладающих большими объемами оперативной памяти»

Как бы в новости всё написано же.

В новости это написано, но зачем это и какой профит я всё же не понел.)

Или намечается дефицит оперативки?)

что-то сомнительно, это под каждый прикол от Штеуда теперь собирать дистры надо ?
Это сильно радует, да.

в рамках «вкусностей» AVX, вкусные они будут только на x86_64, на 32 битах будет только половина регистров, урезанных пополам,с другой стороны есть много слоупоков консервативно настроенных пользователей, не желающих переходить на x86_64 за счет повышенных аппетитов к памяти, а тут по сути аппетиты будут те же, но зато набор инструкций в приложениях будет полноценно 64-битный, вообщем интересно насколько этот вариант ABI будет способен прижиться среди x86 и amd64

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

>есть не только embedded решения

простите, непонятно, чем там плох обычный 32битный линукс?

vps на якобы x86_64 где нельзя за-mmap'ить пару терабайтов.

Но зачем?

Видел инфу еще месяц назад.
Жду, когда это появится в генте.

да вообщем-то неплох он там, и в ближайшее время останется,
никто ж на сервера не потащит эксперименты эти сразу )

>есть много слоупоков консервативно настроенных пользователей, не желающих переходить на x86_64 за счет повышенных аппетитов к памяти

все это замекчательно, только для перехода нужны причины. Я знаю только две. Есть софт 64бит-онли (и виртуализация x86_64 возможна только на X86_64) и есть много памяти. Если обе причины неактуальны, то зачем?

i80386SX is back, welcome, grand.

одно дело инфа, и abi draft, другое дело уже практически готовый тулчейн, правда пока с биоником... с Glibc будет интереснее все же, для не-embedded

хороший вопрос «зачем», можно задать его по-другому - «а если это возможно, то почему бы не попробовать?», мне вот интересно будет посмотреть на развитие и ту долю которую x32-psabi себе откусит )

Потому что в 32-х битном режиме это мало регистров, стек эвривере, уныние, CISC, безыдейность, а в 64-х битном режиме это ВНЕЗАПНО в 2 раза больше регистров (в том числе и в 2 раза больше SSE), стек почти не используется, радость, почти RISC и процветание.

> «а если это возможно, то почему бы не попробовать?»

Ну это заветная формула для создания бардака.

Похоже, что Штеуд уже уперся в стенку развития , теперь в репертуаре у них невинные сюрпризы.

> Как бы в новости всё написано же.

Каким-то извращением, всё равно, попахивает. Рыночная ниша кому это нужно какая-то странная.

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

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

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

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

Штеуд, бессмысленный и беспощадный...

>и использующей практически все преимущества x86_64

Хм.Тут как бы я вижу только один плюс - это математические фишки + вдвое большее количество регистров(хотя и так и так их больше чем доступно в разы)
А вот минусы вытекают из размера кода операций
Вопрос - какой в этом тогда смысл?
Поясните.

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

На десктопах?

Вообще не понятно зачем они это делают ???

Если мало 32бит, переходи на 64 и будет счастье, а нет, тогда сиди на 32. Чё изобретать то ???

Лучше бы делом занялись - в gcc 4.6 багов полно (см багзиллу).

> А разве у 64х битной архитектуры есть какие-то еще преимущества кроме 64х битных указателей?

Внезапно: http://en.wikipedia.org/wiki/X86-64#Architectural_features

> и возможно будет востребованной для устройств и систем не обладающих большими объемами оперативной памяти.

Нормальный такой ход от интел, может будет востребована, а может и не будет.. отбросил инженер ромашку с оторванными лепестками и подумал.. Чёта скучна, сбацаем новую архитектуру! )

Память нынче стоит как грязь по осени. А эта балалайка ещё и монстра родит в стиле x32-ps + PAE, чтобы был доступ поверх четырёх гигов. :D

> А вот минусы вытекают из размера кода операций

Чаво-чаво? Откуда минусы потекли?

>не настолько уж и больше 32-битных отъедают 64-битные приложения. В «среднем по больнице», где-то процентов на 20.
вот так взял...и поделил на ноль
молодец чо :3

хороший вопрос «зачем», можно задать его по-другому - «а если это возможно, то почему бы не попробовать?»

Миграция на x86_64 нетривиальна, нужно всё переставлять и возможно терять ряд контента завязанного в по на разрядность камня.

> На десктопах?

В том числе. Всякие там фотошопы с адобе-премьерами, например. Но их больше, просто в Linux у меня и так сейчас почти всё 64-битное, а про винды я не очень в курсе, потому что не пользуюсь 64-битной виндой. Вроде бы играм ещё каким-то понравилось много памяти.

> ряд контента завязанного в по на разрядность камня

Пример контента можно?

а кто, собственно, гарантирует совместимость на все 100 ? x32-psabi тоже другая архитектура и тоже надо все переставлять и т д , и т п...

просто несколько другая вариация ABI, с устранением наверное наиболее часто упоминаемого недостатка amd64 - аппетитов к памяти, в среднем конечно оно 15-20% , но кое где может и за 100% переваливать, лично видела как java-приложение использующее 512Мб памяти в 32 битном режиме стало кушать 1.4Гб при смене явы на 64-битную

Потому что в 32-х битном режиме это мало регистров, стек эвривере, уныние, CISC, безыдейность, а в 64-х битном режиме это ВНЕЗАПНО в 2 раза больше регистров (в том числе и в 2 раза больше SSE), стек почти не используется, радость, почти RISC и процветание.

Что же используется вместо стека, прямой доступ к Христу за пазуху?

Взлетит еще ведь небось.

Больше регистров, например.

> Что-то сильно смахивает на утонченный маразм.

Ну почему. Вот в далекой-далекой гойлактике много лет назад пользовались так называемым Big Real Mode. Это когда процессор не заморачивался защитой памяти, Ring0-Ring3 всякими и т. д. (эти штучки для 80386 и 80486 были ощутимо дороже по времени выполнения), но указатели памяти были 32-битными и можно было адресовать хоть и 4 Гб ОЗУ.

Возможно, здесь подобный трюк: набор инструкций меняется на 64-битный, а адресация памяти остается 32-битной.

> Вообще не понятно зачем они это делают ???

Если мало 32бит, переходи на 64 и будет счастье, а нет, тогда сиди на 32. Чё изобретать то ???

Вот например, у меня имеется нетбук с процессором Intel Atom и 1GiB RAM. Установлена 64-битная система, потому как в среднем она работает быстрее 32-битной. Но счастье не полное, поскольку на такой системе 64-битные указатели явно лишние и все-таки просаживают скорость на софте, который активно обходит разные структуры вроде списков и деревьев.

Так что пусть пилят, может что хорошее и получится. Только боюсь что к тому моменту, когда оно будет реально готово к использованию, уже будет сложно найти систему с менее, чем 4GiB памяти (разве что какие-небудь low end смартфоны) ;)

Похожий трюк уже используется в 64-битной HotSpot JVM, кстати, если включен флаг UseCompressedOops.