LINUX.ORG.RU

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

 , , , , , , , ,


1

0

Сегодня один из ведущих инженеров Intel, занимающихся разработкой для Linux, H.J. Lu, сообщил о прогрессе в разработке ответвления архитектуры x86_64 — x32-abi (x32-psABI). Данная архитектура, являясь 64-битной и использующей практически все преимущества x86_64, тем не менее, предлагает 32-битный размер указателей, и, возможно, будет востребованной для устройств и систем не обладающих большими объёмами оперативной памяти.

В настоящее время ведутся работы над:

  • портом ядра (Linux) на новую архитектуру (практически готово);
  • binutils, добавлена поддержка в версию 2.21.51.0.6;
  • GCC (стабилизация);
  • Bionic libc.

Следующим этапом должно стать создание порта Glibc.

Проектом занимаются инженеры Intel, SuSE и Codesourcery : H.J. Lu, Milind Girkar, Michael Matz, Jan Hubicka, Andreas Jaeger и Mark Mitchell.

Доступна техническая документация.

Проекту требуется помощь в тестировании и разработке.

>>> Сайт проекта

★★★★★

Проверено: hibou ()

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

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

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

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

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

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

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

anonymous ()

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

elipse ★★★ ()

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

Reset ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Sylvia

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Sylvia

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

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

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

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

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

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

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

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

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

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

Но зачем?

o ()

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Sylvia

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

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

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


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

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

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

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

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

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

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

anonymous_incognito ★★★★★ ()

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

pekmop1024 ★★★★★ ()

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

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

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

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

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

devl547 ★★★★★ ()

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

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

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

AoD314 ()

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

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

Deleted ()

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от devl547

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от elipse

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

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

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

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

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

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

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

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

ssvb ()

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

encoded_reality ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.