LINUX.ORG.RU

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

 , , , , , , , x32-psabi,


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 ()
Последнее исправление: Dendy (всего исправлений: 4)

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

> По мне так лучше бы этих инженеров направили допиливать intel-video драйвер.

Вы реально думаете, что все инженеры взаимозаменяемы, и ядерные/либсишные девелоперы умеют писать видеодрайверы и наоборот?

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

> Это не серьезно.

Что, надо было смайлик явным образом поставить?

Ладно, подождем еще рекламы от Штеуд о драматических улучшениях.

Лично я не очень жду, как я уже говорил.

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

Во-первых, области тут относительно близкие. Во-вторых, у Intel много ядрёных разработчиков, наверняка можно было произвести замены, чтобы заменить прошаренных в видео на этих, если эти уже такие уникальные ядрозадро.

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

> Во-первых, области тут относительно близкие.

Области довольно далекие. GPU сильно отличаются от CPU. И я сомневаюсь, что Лю знает OpenGL, например.

Во-вторых, у Intel много ядрёных разработчиков, наверняка можно было произвести замены, чтобы заменить прошаренных в видео на этих, если эти уже такие уникальные ядрозадро.

Какие конкретно замены? Уволить Лю и на его зарплату взять графического девелопера? Или заставить Лю изучать GPU/OpenGL/etc и молиться, что он не пошлет таких менеджеров и не уволится?

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

> Что, надо было смайлик явным образом поставить

угу, я тоже не поставил, классика:

- Сумма?!
Триста!
- Это не серьезно! ..

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

> x86_64 УЖЕ ЕСТЬ и его не надо изобретать, а стенания про дорогую память

Хм, слушай, а мы тут все вообще не о том трем. Мы все не просто Ъ, а Ъ в кубе, если не больше.

Короче, Х. Й. Лю этот сообщил вчера (уже вчера как бы) в LKML, что в разработке процессоро-специфичного ABI для Linux на X32/LP64 почти достигла небывалых достижений, осталось только там-сям подпилить, доделать ядро и компилер, и решить, а ково хрена в спецификации time_t все еще 32 бита (это не архитектура, блин, а способ взаимодействия юзерспейса с ядром, а также заморочки типа как организовывать стек, как строить библиотеку, как передавать параметры в функцию и так далее, с учетом специфики процессоров).

Короче, это темная мохнатая штука (типа ARM-GNUEABI, вещи одного порядка), интересная только разработчикам компиляторов и линкеров, а общей публике не нужная. Я не могу взять в толк, в чем собственно новость, если даже в LKML охренели и тихонько спрашивают «аштоэта?».

Читаю драфт спецификации, так там вообще ни слова о том, что указатель прям-таки обязан быть 32-битным и все тут. Даже наоборот. О том, что «x86-64 c 32-битным указателем», написано только в шапке сайта, думаю, это Лю написал, но китаец такой китаец, что я сомневаюсь, что он именно это имел в виду.

-----------------------------------------

Вот выдержка из LKML (да и из рассылки GCC), вопросы задает Флориан ВАЙНЕР:

— Из этих ресурсов (сайта на Google Sites — shimon) сколь-нибудь полезную информацию вообще хрен разберешь.

Х. Й. ЛЮ: Да, правда. Поправки и замечания приветствуются.

— А off_t у вас 32-битный, что ли? Зачем использовать интерфейс совместимости с ia32 к ядру?

ЛЮ: Да. (лучший ответ на вопрос «почему». — shimon)

Х. Питер ЭНВИН: да потому что мы еще не настолько чокнулись, чтобы запиливать второй интерфейс совместимости в ядро (а это должен быть именно интерфейс совместимости, все-таки размеры указателей различны).

Мэтт ТОМАС: off_t вообще не часть psABI, так как зависит от ОС.

— Мне так кажется, людям, которые могут контролировать весь стек ПО от и до, как раз захочется избавиться от прокладок совместимости.

ЛЮ: А вот это как сказать. Есть мысль, что с точки зрения юзерспейса X32 (это когда процессор x86-64 работает с 32-битными операндами и указателями) ничем не отличается от ia32. А еще есть подводные камни типа размера time_t.

ТОМАС: вообще, любой метод осуществления системных вызовов зависит от ОС, и выходит за рамки psABI. Юзерспейсу должно быть все равно.

— Выравнивание стека на 16-байтную границу для X32 сколь-нибудь полезно?

ЛЮ: Выравнивание на 16 байтов используется даже в ia32. Так что мы это еще и утвердим официально, выпустив обновление к i386 psABI.

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

Ну декодирование команнды процессора тоже время идет + его бранчинг и тд

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

Omg, такой облом-с ))
А тут уже нарисовались фаны нового CPU.

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

> просто несколько другая вариация ABI, с устранением наверное наиболее часто упоминаемого недостатка amd64 - аппетитов к памяти, в среднем конечно оно 15-20% ,

Среднеяя температура по больнице? Источник плиз.

Если в среднем указатели указывают на чанки памяти, больше, чем 80 байт, то оверхед, внезапно, около 10%.

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

Более того, я как-то не могу распарсить, какие именно преимущества x86-64 доступны в режиме совместимости.

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

> Читаю драфт спецификации, так там вообще ни слова о том, что указатель прям-таки обязан быть 32-битным и все тут.

Фигасе. Вот же написано в табличке https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1 на странице 12: Pointer any-type * (X32) 4 байта.

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

> Более того, я как-то не могу распарсить, какие именно преимущества x86-64 доступны в режиме совместимости.

Дык все, кроме большого адресного пространства. Код-то все равно 64битный. Соответсвенно, много регистров, RIP-relative адресация для PIC etc.

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

Что-то я уже вообще перестал что-либо понимать. В двух словах, чего в Intel на самом деле сделали-то? Выдержка из рассылки LKML ясности не прибавила.

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

> Не не, тут все поймались ))

Ну, да, вам конечно оттуда виднее, поймался я или нед. :)

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

> Что-то я уже вообще перестал что-либо понимать. В двух словах, чего в Intel на самом деле сделали-то?

Сделали новый ABI/Personality под amd64 ядра, в котором в usermode указатели и long имеют длину 32бита, а не 64. Если хотите, это в некотором смысле похоже на small memory model под ms-dos.

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

> а спека программной поддержки 32-х битного режима для Amd64.

Это не 32битный режим под amd64, 32битный режим под amd64 давным-давно поддерживается. Это именно 64битный режим, но с 32битными указателями.

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

И часть инструкций доступна только в 64 битном режиме

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

Ну я грубо написал, да.
И да, это ж сколько лет ушло на такое открытие ?))

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

>Сделали новый ABI/Personality под amd64 ядра, в котором в usermode указатели и long имеют длину 32бита, а не 64.

Чьерт, тоесть уже не позлопыхаешь, что винда будет поддерживать новый процессор только лет через 5?

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

> Чьерт, тоесть уже не позлопыхаешь, что винда будет поддерживать новый процессор только лет через 5?

Увы. :)

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

> Дык все, кроме большого адресного пространства. Код-то все равно 64битный. Соответсвенно, много регистров, RIP-relative адресация для PIC etc.

Стоп-стоп. Чой-то я не понимаю. Либо у тебя код 64-битный и есть все плюшки, в том числе адресное пространство, либо код 32-битный, и нет тогда ни R8-R15, ни адресного пространства, то бишь нет плюшек.

Или ты хочешь сказать, что gcc -mx32, который этот Лю делает — это такое искусственное ограничение, когда код у тебя в 64-битном режиме, но ты усилием воли запрещаешь использовать 64-битные операнды, 64-битную адресацию и так далее? Или для доступа к R8D-R15D программа постоянно меняет режимы? Да это же неэффективно шопесец.

Вот http://www.intel.com/Assets/PDF/manual/253665.pdf документашка по архитектуре, скажи, на какой странице такое чудо описано.

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

> Что-то я уже вообще перестал что-либо понимать. В двух словах, чего в Intel на самом деле сделали-то? Выдержка из рассылки LKML ясности не прибавила.

Интел — нихрена.

Мое текущее понимание: для экономии памяти можно скомпилить программу так, чтобы она работала в 64-битном режиме, но не использовала 64-битных адресов памяти, возможно, не использовала даже верхних половин РОН (sizeof(int) == sizeof(long) == 4,  то самое для всех указателей). Из этого должны извлечься какие-то плюшки, какие именно, я сейчас пытаюсь уразуметь.

Downside этого в том, что для таких особо скомпиленных программ нужен особый ABI, причем на ядре с LP64 это должен быть ABI совместимости, потому что в программе указатели 32-битные, а у ядра — 64-битные. Я так понял, делается попытка скрестить ежа с ужом и притянуть за уши с незначительными изменениями ABI от IA-32, потому что оно уже есть, а делать второй слой совместимости Энвину западло.

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

> Нет, здесь речь идет о программной модели компилятора и увязки ее с ядром.

Ненене, я у Вадика хочу узнать, что это за режим X32 — искуственно кастрированный 64-битный, когда программе просто запрещено использовать конкретно саму 64-битность (то есть, компилятор не породит код с 64-битными абсолютными адресами или операндами для РОН ни под каким соусом), или недокументированные фичи режима совместимости?

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

> Стоп-стоп. Чой-то я не понимаю. Либо у тебя код 64-битный и есть все плюшки, в том числе адресное пространство, либо код 32-битный, и нет тогда ни R8-R15, ни адресного пространства, то бишь нет плюшек.

Или ты хочешь сказать, что gcc -mx32, который этот Лю делает — это такое искусственное ограничение, когда код у тебя в 64-битном режиме, но ты усилием воли запрещаешь использовать 64-битные операнды, 64-битную адресацию и так далее?

Примерно так, да. Только 64битные операции никто не запрещает, потому что они один из плюсов amd64. Просто int, long, и указатели устанавливаются длиной 32 бита. Соответственно, когда компилятор видит что-то вроде int a = b + c; он будет генерить не addq %rax, %rbx (к примеру) , а addl %eax, %ebx. А вот long long таки остается 64битным, и позволяет эффективно реализовать 64битную целую арифметику.

А что касается адресов, то формально процессу никто конечно не запретит залить в регистр 64битный адрес больше 0xffffffff, и обратиться по нему, но ядро естественно туда ничего мэпать в этом процессе не будет, и получится SIGSEGV. Ну, и все сисколлы предположительно будут или отрезать старшие биты адреса, или проверять на нулевость, (чтобы сказать точно, которое из двух, надо смотреть спеки, но мне лень :) «С точки зрения банальной интуиции»© подозреваю, что сделают также, как в эмуляции ia-32, но как там сделано я тоже не смотрел :) ).

Как-то так.

Или для доступа к R8D-R15D программа постоянно меняет режимы? Да это же неэффективно шопесец.

Я даже думаю, что это в принципе нереализуемо.

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

> Downside этого в том, что для таких особо скомпиленных программ нужен особый ABI,

Вот именно этот ABI они таки и пилят.

причем на ядре с LP64 это должен быть ABI совместимости, потому что в программе указатели 32-битные, а у ядра — 64-битные.

Именно. К их счастью, такой режим совместимости уже давным-давно сделан (CONFIG_IA32_EMULATION) для запуска старых 32битных i386 бинарников, надо только чуть-чуть подпилить, чтоб кроме одного ABI (IA-32) повесить на него еще и второй (x32).

Я так понял, делается попытка скрестить ежа с ужом и притянуть за уши с незначительными изменениями ABI от IA-32, потому что оно уже есть, а делать второй слой совместимости Энвину западло.

Да-да, именно так и я это все понимаю.

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

Смотри раздел 3.5.1 на 34 странице спецификации.
Да, это кастрированный 64-битный режим, а сам gcc.. кхм, не идеал еще, ну ты все понял))

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

> Ненене, я у Вадика хочу узнать, что это за режим X32 — искуственно кастрированный 64-битный, когда программе просто запрещено использовать конкретно саму 64-битность (то есть, компилятор не породит код с 64-битными абсолютными адресами или операндами для РОН ни под каким соусом), или недокументированные фичи режима совместимости?

Нет, режим, в котором вообще вся 64битность запрещена уже есть, а они хотят именно что разрешить почти всю 64битность, но оставить указатели короткими. Сорри за повторы, но я подумал, что лучше лишний раз ответить, чем не отвечать.

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

> Смотри раздел 3.5.1 на 34 странице спецификации.

Если вы про small code model/kernel code model/etc, то это несколько про другое. Это просто разные варианты организации адресного пространства нормального amd64 ABI. И этот раздел в на первый взгляд неизменном виде существует и в более старых версиях спецификации, в которых еще нет никаких упоминаний об x32 (например http://www.x86-64.org/documentation/abi.pdf). И да, x32 бинарники естественно будут организованы в small model, потому что они гарантированно должны влезать в 32 бита (и это явно написано на странице 36), но small model вполне может использоваться и для lp64 бинарников.

vadic
()

Это какой-то хитрый ход для поддержки аппетитов Windows?

Закопать этого франкенштейна!

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

> Это какой-то хитрый ход для поддержки аппетитов Windows?

Эээ... А можно более развернуто? Что-то я не прослеживаю вашу логику.

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

Не, там описаны все модели памяти , а в главе 10
X32 programming model
______________________
10.1 Address Space
AMD64 X32 binaries reside in the lower 32bits of the 64bit virtual address space
and all addresses are 32bits in size. They should conform to small code model or
small position independent code model (PIC) described in Section 3.5.1.
_____________________
они уже ссылаются на раздел 3.5.1

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

Логику как раз я и пытаюсь проследить. В линуксе никаких проблем нет с 64 битами нормальными. Зачем нужен очередной монстр? Сэкономить пару мегабайт взамен получения кучи геморроя всего этого добра… а нужно ли?

А если на самом деле получается что-то в духе «ядро видит всю память, приложения — 4 гига», то это как раз для любителей костылей. Как раз там с настоящим 64-битным софтом всё ещё проблемы.

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

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

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

Ну да, там и в конце раздела 3.5.1 тоже написано, что «Only small code model and small position independent code model (PIC) are used in X32 binaries.» Я говорил немного о другом. Я сначала подумал, что вы имели в виду, что этот small code model был придуман *специально* для x32. А это не так.

vadic
()
Ответ на: комментарий от Deleted

> Зачем нужен очередной монстр?

Лично у меня пока нет определенного мнения нужен ли он.

Сэкономить пару мегабайт взамен получения кучи геморроя всего этого добра… а нужно ли?

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

А, следовательно, во-вторых, если они считают что им это зачем-то нужно, пусть делают, почему нет? Может и мне или вам пригодится, если внезапно окажется, что это дает какой-то выигрыш.

А если на самом деле получается что-то в духе «ядро видит всю память, приложения — 4 гига», то это как раз для любителей костылей. Как раз там с настоящим 64-битным софтом всё ещё проблемы.

Вы, возможно, упускаете из виду, что это не новая архитектура ядра. Это просто еще один ABI для нормального amd64 ядра. И x32 бинарники вполне могут исполнятся параллельно и с нормальными 64битными бинарниками и со старыми i386 полностью 32битными бинарниками.

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

> Although X32 binaries run in the 64bit mode, not all 64bit instructions are supported.

А вот это уже интересно. Надо будет посмотреть, что это подробно значит. Но потом, сейчас спать хочется.

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

>я сомневаюсь, что это доставит какой-либо геморрой тем, кто это не будет использовать.

Я о тех, кто будет. // К.О.

И x32 бинарники вполне могут исполнятся параллельно и с нормальными 64битными бинарниками и со старыми i386 полностью 32битными бинарниками.


Это и сейчас можно.

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

> Although X32 binaries run in the 64bit mode, not all 64bit instructions are supported.

А, ну понятно. Они строго говоря не not supported, их не надо использовать потому что все будет хреново. То есть запрещено (не в смысле «процессор не позволит», а в смысле «не надо») использовать инструкции перехода, берущие адрес перехода из памяти. Потому что ISA в 64битном режиме не предусматривает вариант этих инструкций, загружающих 32битный адрес.

vadic
()
Ответ на: комментарий от Deleted

> Я о тех, кто будет.

Ну, если они хотят себе геморроя, кто я такой, чтоб им запрещать?

И x32 бинарники вполне могут исполнятся параллельно и с нормальными 64битными бинарниками и со старыми i386 полностью 32битными бинарниками.

Это и сейчас можно.

Нет. Сейчас вообще еще нет поддержки x32 бинарников (не путать с i386 бинарниками). Ну кроме H.J.Lu'шных экспериментальных ядер.

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

>Они строго говоря не not supported, их не надо использовать потому что все будет хреново. То есть запрещено (не в смысле «процессор не позволит», а в смысле «не надо») использовать инструкции перехода, берущие адрес перехода из памяти.

не, немного не так ))
в вашем высказывании :
----------
И x32 бинарники вполне могут исполнятся параллельно и с нормальными 64битными бинарниками и со старыми i386 полностью 32битными бинарниками.
----------
фрагмент о нормальных 64битных бинарниках, строго говоря, надо бы удалить.

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

i80386SX is back, welcome, grand.

я тоже понял,
Интел готовит плацдарм для выпуска нового процессора

anonymous2 ★★★★★
()

это для говноатома костыль?

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