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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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.

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

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

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

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

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

> (это не архитектура, блин, а способ взаимодействия юзерспейса с ядром)

2*arcsin(1)сдетс, какое открытие! Именно об этом я несколько часов уже говорю: http://www.linux.org.ru/news/linux-general/5902714/page1#comment-5903184

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

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

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

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

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

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

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

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

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

Короче, это не новый CPU и не новые команды,
а спека программной поддержки 32-х битного режима для Amd64.

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

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

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

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

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

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

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

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

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

Увы. :)

> Дык все, кроме большого адресного пространства. Код-то все равно 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 документашка по архитектуре, скажи, на какой странице такое чудо описано.

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

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

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

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

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

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

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

> Стоп-стоп. Чой-то я не понимаю. Либо у тебя код 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 программа постоянно меняет режимы? Да это же неэффективно шопесец.

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

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

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

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

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

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

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

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

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

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

> Смотри раздел 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 бинарников.

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

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

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

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

Не, там описаны все модели памяти , а в главе 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

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

Тред не читаем @ сразу отвечаем

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

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

Сочувствую.

ну и главное:
10.3 Coding Examples
Although X32 binaries run in the 64bit mode, not all 64bit instructions are supported.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

i80386SX is back, welcome, grand.

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

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