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

> Отдайте оптимизатору следить за тем какие указатели можно укорачивать а какие нет.

Выстрелите себе в мозг и не засоряйте генофонд умствованием. Природе - не нужен интеллект.

PS: Какой профит от одного укороченного указателя на память?

Кармак каждый год нулевой феррари прикупает, а Вы?

Для профита их должны быть миллионы и они должны жить в кеше :)

«Память - не резиновая». И, несмотря на общий охерительный гигометраж на единицу... эээ... «линуксоидства», всёж замечу - е*ись конём такой расход памяти и PT, невзирая на оптиму приличных архитектур, навроде спарков и паверов.

PPS: По диагонали просмотрел ветку на LKML. Cоздалось впечатление что аффтар просто желает создать некий несовместимый ни с чем ABI для использования на мобильных атомных девайсах :)

А упоминание аффтара на bionic как бы намекает на платформу :)

Он лишь частично прав, да и то - на очень маленьком интервале.

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

Определённо новый завоз чуйки :))

А насколько я понимаю, и Энвин тоже занимается этим проектом

А не надо ничего понимать, надо сходить по ссылке «документация»,
и на титульном листе увидеть список тех, кто работает над этим
(Анвина там нет).

вот он пишет: «It is an open question at this stage and *we*'ll see

Он это пишет с точки зрения маинтейнера соответствующих наворотов в
ядре, и только то.

А, то есть хотите все реально сложные в реализации вещи переложить

на программера.

Да блин. Поинтеры используют соглашение по умолчанию то, которое
вы флажками компиляции задали. Это всегда так было. Вы хотите, чтобы
можно было поинтеру присваивать и адрес функции cdecl, и stdcall,
и x32call, fastcall, и тд, на выбор, ничего при этом не говоря
компилятору? Вы явно живёте в другом мире, возможно, в мире
гарвардских архитектур, где такое обычно осуществимо, к примеру, в
компиляторе sdcc такие вещи поддерживаются. Но речь не о том.
А здесь - такое делать нельзя, и не нужно. Так как прогу мы
предполагаем собирать _всю_ под x32, и все вызовы через поинтеры,
соответственно, будут подразумевать x32. Какие с этим проблемы?

O'RLY? Что же вы тогда путаетесь в показаниях и говорите, что ее

вызывают как x32?

Давайте придерживаться технических аспектов, я ни в чём не
путаюсь, и это уже переход на личности, в какой-то мере. :)
Ваша ia32 либа будет вызывать колбэк как ia32, но, так как он
совместим с x32, то и как x32 тоже, только после того, как CS
подменят. Что непонятного то? :) Как CS при колбэке подменять -
я уже сказал: дальний вызов в начале всех x32 функций ставить,
ну в конце дальний возврат, делов то. В этом случае, их можно
будет вызывать и из ia32 кода, и из x32 кода - главное, что не
придётся аргументы тасовать, как вы это предлагали, так как эти
ABI совместимы.

компиляторе sdcc такие вещи поддерживаются.

Собственно, имел ввиду _аналогичные_ вещи, не такие же.
К примеру, там можно обычному указателю присваивать адреса
из пространства code/data/xdata/etc, без явного указания, и
он это схавает, но размер поинтера при этом возрастёт на байт,
так что никогда так не делаю.

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

> Все остальные атомы — это недоразумение, конечно же. Например, N270. Особенно N270.
Чем он тебе не угодил? Процессор как процессор. Вопреки опасениям, даже достаточно производительный, чтоб показывать видео 720p без ускорения на видеокарте.

А греется он при этом как! Ну и 720p без ускорения, это даже с mplayer-mt, скажем мягко, преувеличение. Разве что имелось в виду видео с разрывами и заиканиями, иногда превращающееся в слайдшоу (я смотрел H.264/720p на N270/GMA950, знаю, о чем говорю).

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

А насколько я понимаю, и Энвин тоже занимается этим проектом

А не надо ничего понимать, надо сходить по ссылке «документация», и на титульном листе увидеть список тех, кто работает над этим (Анвина там нет).

А, ну понятно, если Энвин говорит, что «мы над этим работаем», а вы говорите, что он не работает, то верить я должен, естественно, вам, а не ему.

Ваша ia32 либа будет вызывать колбэк как ia32, но, так как он совместим с x32, то и как x32 тоже, только после того, как CS подменят.

А с чего это ia32 совместим с x32? Он совместим только по форматам данных, и все. А calling convention и машинный код несовместим.

Что непонятного то? :) Как CS при колбэке подменять - я уже сказал: дальний вызов в начале всех x32 функций ставить, ну в конце дальний возврат, делов то.

А не затруднит ли вас примерно набросать, как это будет выглядеть в реальности? Например, какой ассемблерный код компилятор выдаст вот на это:

void callback(void)
{
    printf("This is callback. %d\n", 42);
}

/*....*/
atexit(&callback);

Говорить общие слова легко, а когда дело доходит до деталей реализации, часто всплывают неожиданности.

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

В том то и дело, что ABI не совместимы, и аргументы из ia32 кода и из x32 кода передаются по-разному.

void callback(void)
{
    printf("This is callback. %d\n", 42);
}

/*....*/
atexit(&callback);

В случае чистого x32 с родными x32'шными библиотеками это будет выглядеть примерно так:

.section    .rodata
str:    .string "This is callback. %d\n"
.text
callback:
	pushq	%rbp
	movq	%rsp, %rbp
	movl	$str, %eax
	movl	$42, %esi
	movq	%rax, %rdi
	movl	$0, %eax
	call	printf
	leave
	ret
;------------------------
	movl	$callback, %edi
	call	atexit

Ваш ход.

А, ну понятно, если Энвин говорит, что «мы над этим работаем», а вы

говорите, что он не работает, то верить я должен, естественно, вам,

а не ему.

А при чём тут я? Вот в самой новости от Сильви что сказано:
---
Проектом занимаются инженеры Intel, SuSE и Codesourcery : H.J. Lu, Milind Girkar, Michael Matz, Jan Hubicka, Andreas Jaeger и Mark Mitchell.
---
Если Анвин где-то сказал «мы работаем», то, вероятнее всего, он
просто имел ввиду, что, как маинтаинер соответствующих частей ядра,
он будет просматривать патчи, обсуждать всё, и тд. При этом, он мог
точно так же, как и мы, продрать глаза с утра, и увидеть у себя в
почтовом ящике эту вот штуку. Я предлагаю вереть Лю, так как он-то
уж точно над этим работает, и, кроме того, его объяснение вопросов
не оставляет. С таким же успехом, вы мне предлагаете верить Анвину,
а не ему...

В том то и дело, что ABI не совместимы, и аргументы из ia32 кода

и из x32 кода передаются по-разному.

Если так, то чего мы вообще обсуждаем, но где пруф?
Я так понял со слов Лю, что всё планируется совместимым, но есть
какие-то нюансы, которые сейчас устаканиваются. У вас есть более
точные данные - тогда чего же вы молчали всё время? :)
Пруф в студию, и расходимся.

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

Ну, вам конечно виднее, чем ему, чем он там занят, но вот он прямо говорит о разработке x32: «We prototyped using the int $0x80 system call entry point. However, there are two disadvantages:» «Oh, and as to why not copy the i386 system call list straight off... we don't really want to add a new ABI with crap like sys_socketcall.» «The actual idea is to use the i386 compat ABI for memory layout, but with a 64-bit register convention. That means that system calls that don't make references to memory structures can simply use the 64-bit system calls, otherwise we're planning to reuse the i386 compat system calls, but invoke them via the syscall instruction (which requires a new system call table) and to pass 64-bit arguments in single registers.»

В том то и дело, что ABI не совместимы, и аргументы из ia32 кода и из x32 кода передаются по-разному.

Если так, то чего мы вообще обсуждаем, но где пруф? Я так понял со слов Лю, что всё планируется совместимым, но есть какие-то нюансы, которые сейчас устаканиваются. У вас есть более точные данные - тогда чего же вы молчали всё время? :)

Я молчал? Я с самого начала говорил про разные calling conventions: http://www.linux.org.ru/jump-message.jsp?msgid=5902714&cid=5907030

Пруф в студию, и расходимся.

Легко:

AMD64 ABI (включая x32): https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1 страница 17

IA-32 ABI: http://refspecs.freestandards.org/elf/abi386-4.pdf страница 3-9 / 35

> Я так понял со слов Лю, что всё планируется совместимым,

Совместимым с ia32 планируется оставить API, а не ABI. В том числе длины разных там size_t, off_t и так далее.

Ну, вам конечно виднее, чем ему, чем он там занят

Да при чём тут я опять, уже на 2 источника вам указал. :)

но вот он прямо говорит о разработке x32:

Это относится, опять-таки, только к ядру. Ну помогает он им в
ядре реализацию сделать, и что из этого?

Легко:

Конкретнее, пожалуйста.
В первом, указанном вами документе, на стр 12 есть таблица типов.
Во втором - она на стр 3-2.
Расхождений не заметил.
Для пруфа, укажите конкретно тип, который различается, и страницы
в обоих документах, где это различие явно видно. При этом, тип
желательно не «экзотический», так как с экзотикой они ещё не всё
утрясли.

>> Ну, вам конечно виднее, чем ему, чем он там занят

Да при чём тут я опять, уже на 2 источника вам указал. :)

А я вам 5.

но вот он прямо говорит о разработке x32:

Это относится, опять-таки, только к ядру. Ну помогает он им в ядре реализацию сделать, и что из этого?

Какая разница, к чему относится? Он помогает сделать реализацию, и тем самым участвует в разработке.

Легко:

Конкретнее, пожалуйста. В первом, указанном вами документе, на стр 12 есть таблица типов.

При чем тут страница 12? Я ясно написал: начиная со страницы 17, раздел 3.2.3 Parameter Passing. Там написано, что в большинстве случаев параметры передаются в регистрах.

Во втором - она на стр 3-2.

Во втором начиная со страницы 3-9 раздел Function Calling Sequence, все параметры передаются только через стек.

Расхождений не заметил. Для пруфа, укажите конкретно тип,

При чем тут типы? Я говорю про calling convention, про то, как передаются параметры функций при вызове.

И вот конкретный пример:

#include <sys/types.h>
#include <sys/stat.h>

int foo (const char *, const struct stat *, int);

void bar()
{
	struct stat st;
	foo("baz", &st, 42);
}

вот оно скомпиленное в ia32:

	.file	"lor3.c"
	.section	.rodata
.LC0:
	.string	"baz"
	.text
.globl bar
	.type	bar, @function
bar:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$120, %esp
	movl	$42, 8(%esp)
	leal	-96(%ebp), %eax
	movl	%eax, 4(%esp)
	movl	$.LC0, (%esp)
	call	foo
	leave
	ret
	.size	bar, .-bar
	.ident	"GCC: (Debian 4.4.5-10) 4.4.5"
	.section	.note.GNU-stack,"",@progbits

А вот оно скомпилено в amd64:

	.file	"lor3.c"
	.section	.rodata
.LC0:
	.string	"baz"
	.text
.globl bar
	.type	bar, @function
bar:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	movq	%rsp, %rbp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	subq	$144, %rsp
	leaq	-144(%rbp), %rax
	movl	$42, %edx
	movq	%rax, %rsi
	movl	$.LC0, %edi
	call	foo
	leave
	ret
	.cfi_endproc
.LFE0:
	.size	bar, .-bar
	.ident	"GCC: (Debian 4.4.5-10) 4.4.5"
	.section	.note.GNU-stack,"",@progbits

Понятна разница?

А я вам 5.

Но авторитетность у них... :))
Я-то на доку приводил ссылку, и на слова Лю.

Какая разница, к чему относится? Он помогает сделать реализацию,

и тем самым участвует в разработке.

То, что он подрядился им помочь в ядре, не говорит ещё о том, что
он точно знает, какие задачи они решают. Он так и сказал: посмотрим,
как получится, будет ли оно того стоить, и тд. А Лю прямо говорит:
это - модернизация ia32. И чему предлагается доверять?

При чем тут типы? Я говорю про calling convention

Так это разве проблема? Я только за типы и беспокоился, а если они
решили по умолчанию fastcall использовать, то и коллбэки вам никто
не мешает объявить как fastcall. Или вы хотите те же самые коллбэки
ещё и из своего собственного кода вызывать, помимо atexit()?
Но так, во первых, никто не делает, а во вторых, тогда вам _придётся_
помечать указатели соотв атрибутом, иначе компилятор должен варнинг
выдать (надеюсь, он так и сделает).
Короче, проблемы всё ещё не вижу.

Я только за типы и беспокоился

Интересно, чего я за них беспокоился, если с ними та же логика
прокатывает... Коллбэки можно помечать так, как надо, вот и всё.

то и коллбэки вам никто не мешает объявить как fastcall

То есть cdecl, чтобы из старого кода вызывать...

>> При чем тут типы? Я говорю про calling convention

Так это разве проблема? Я только за типы и беспокоился, а если они решили по умолчанию fastcall использовать, то и коллбэки вам никто не мешает объявить как fastcall.

Во-первых, все наоборот: ia32 библиотека будет вызывать коллбэк передавая все параметры в стеке, а amd64 ABI такой calling convention не предусматривает в принципе. То есть вам придется менять стандарт, и добавлять в компилятор новый атрибут и соответствующую calling convention.

Во-вторых, это не fastcall. В fastcall первый аргумент передается в %ecx, второй в %edx, остальные в стеке. В amd64 (в том числи и в x32) первые 6 целочисленных аргументо передаются в %rdi, %rsi, %rdx, %rcx, %r8, %r9, а аргументы с плавающей точкой в %xmm0-%xmm7. Чувствуете разницу?

Во-первых, все наоборот:

Я уже поправился выше.

То есть вам придется менять стандарт, и добавлять в компилятор

новый атрибут и соответствующую calling convention.

Чем вас не устраивает атрибут cdecl? Он что, не будет работать при
компиляции под x32? Откуда такая инфа?

то и коллбэки вам никто не мешает объявить как fastcall

То есть cdecl, чтобы из старого кода вызывать...

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

#include <sys/types.h>
#include <sys/stat.h>

int __attribute__((cdecl)) foo (const char *, const struct stat *, int);

void bar()
{
	struct stat st;
	foo("baz", &st, 42);
}

$ gcc -S -o lor3_64-2.s lor3.c 
lor3.c:4: warning: ‘cdecl’ attribute ignored

	.file	"lor3.c"
	.section	.rodata
.LC0:
	.string	"baz"
	.text
.globl bar
	.type	bar, @function
bar:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	movq	%rsp, %rbp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	subq	$144, %rsp
	leaq	-144(%rbp), %rax
	movl	$42, %edx
	movq	%rax, %rsi
	movl	$.LC0, %edi
	call	foo
	leave
	ret
	.cfi_endproc
.LFE0:
	.size	bar, .-bar
	.ident	"GCC: (Debian 4.4.5-10) 4.4.5"
	.section	.note.GNU-stack,"",@progbits

Все то же самое, аргументы в регистрах.

cdecl – это другое. Во-первых, cdecl говорит о том, кто подчищает

стек, вызывающий, или вызываемый, а не о передаче параметров.

Правда?
http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD...
---
cdecl

Основной способ вызова для Си (отсюда название, сокращение от «c-declaration»). Аргументы передаются через стек, справа налево.
---

Во-вторых, в amd64 cdecl нет вообще. Вот смотрите:

А речь про x32.

>Ну и 720p без ускорения, это даже с mplayer-mt, скажем мягко, преувеличение.

Более древний, одноядренный, celeron-M 900MHz вполне справляется с 720р

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

Зачем на нетбуках/неттопах что-то собирать?

> Зачем на нетбуках/неттопах что-то собирать?

«Стройная коллекция портов»

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

Правда?

Правда.

http://ru.wikipedia.org/wiki/Соглашен...

Википидоры могут говорить все, что угодно, но в доках gcc написано:

`cdecl'
     On the Intel 386, the `cdecl' attribute causes the compiler to
     assume that the calling function will pop off the stack space used
     to pass arguments.  This is useful to override the effects of the
     `-mrtd' switch.

Во-вторых, в amd64 cdecl нет вообще. Вот смотрите:

А речь про x32.

А x32 и есть разновидность amd64. Прочитайте заголовок https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1: «System V Application Binary Interface AMD64 Architecture Processor Supplement (With LP64 and X32 Programming Models)»

Википидоры могут говорить все, что угодно

Ну-ну-ну, это уже флейм.
Хорошо, вот другая статья, попробуйте и её авторитет оспорить:
http://msdn.microsoft.com/en-us/library/zkwh89ks%28VS.71%29.aspx

А x32 и есть разновидность amd64.

Я не вижу причины, по которой это должно убить атрибут cdecl.
Поскольку здесь мы ничего друг другу не докажем, довайте определяться,
есть ли проблемы кроме этой. :) Если других проблем нет, и дело только
за атрибутом, то предлагаю на том и порешить.

>> Википидоры могут говорить все, что угодно

Ну-ну-ну, это уже флейм. Хорошо, вот другая статья, попробуйте и её авторитет оспорить: http://msdn.microsoft.com/en-us/library/zkwh89ks%28VS.71%29.aspx

Знаете, интуиция мне подсказывает, что информацию о поведении gcc (мы же говорим о gcc, а не visual studio, или как там оно называется, да?) все-таки логичнее искать в gcc'шном мануале, а не на MSDN. Как вы считаете?

Да, может вы считаете, что cdecl – это часть ISO C? Тогда вы ошибаетесь, это расширение, которое каждый производитель компилятора может понимать по-своему.

А x32 и есть разновидность amd64.

Я не вижу причины, по которой это должно убить атрибут cdecl. Поскольку здесь мы ничего друг другу не докажем, довайте определяться, есть ли проблемы кроме этой. :) Если других проблем нет, и дело только за атрибутом, то предлагаю на том и порешить.

Проблема в том, что разработчики gcc почему-то такую причину увидели, и таки убили cdecl на amd64.

> http://msdn.microsoft.com/en-us/library/zkwh89ks%28VS.71%29.aspx

И, да, там прямо так и написано: «Microsoft Specific», т.е. к gcc эта статья никакого отношения не имеет. Что и не удивительно.

Вот уже по стопам Лю предлагают чуть иной велосипед для MIPS:
-----------
RFC: A new MIPS64 ABI
from: David Daney <ddaney at caviumnetworks.com>
to: linux-mips , GCC, binutils
14 февраля 2011 в 23:29

Background:

Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values are always sign extended.

Because there are not already enough MIPS ABIs, I present the ...

Proposal: A new ABI to support 4GB of address space with 32-bit
pointers.

The proposed new ABI would only be available on MIPS64 platforms. It
would be identical to the current MIPS n32 ABI *except* that pointers
would be zero-extended rather than sign-extended when resident in
registers. In the remainder of this document I will call it
'n32-big'. As a result, applications would have access to a full 4GB
of virtual address space. The operating environment would be
configured such that the entire lower 4GB of the virtual address space
was available to the program.


At a low level here is how it would work:

1) Load a pointer to a register from memory:

n32:
LW $reg, offset($reg)

n32-big:
LWU $reg, offset($reg)

2) Load an address constant into a register:

n32:
LUI $reg, high_part
ORI $reg, low_part

n32-big:
ORI $reg, high_part
DSLL $reg, $reg, 16
ORI $reg, low_part


Q: What would have to change to make this work?

o A new ELF header flag to denote the ABI.

o Linker support to use proper library search paths, and linker scrips
to set the INTERP program header, etc.

o GCC has to emit code for the new ABI.

o Could all existing n32 relocation types be used? I think so.

o Runtime libraries would have to be placed in a new location
(/lib32big, /usr/lib32big ...)

o The C library's ld.so would have to use a distinct LD_LIBRARY_PATH
for n32-big code.

o What would the Linux system call interface be? I would propose
using the existing Linux n32 system call interface. Most system
calls would just work. Some, that pass pointers in in-memory
structures, might require kernel modifications (sigaction() for
example).

И, да, там прямо так и написано: «Microsoft Specific»

Ну я уж и не знаю, что с вами делать. :)
Вот, чтоли, ещё статья:
http://publib.boulder.ibm.com/infocenter/wdzinfo/v7r0/index.jsp?topic=/com.ib...

Знаете, интуиция мне подсказывает, что информацию о поведении gcc

gcc мануал не обязан описывать всё то, что описано в других местах.
В частности, грамматику языка С вы там тоже вряд ли найдёте.
Что, по вашему, раз в мануале про порядок аргументов не написано,
то gcc может их в любом порядке помещать? Моё утверждение в том, что
cdecl заставляет его действовать именно так, как написано в этих
статьях. И это не противоречит его мануалу, а лишь дополняет его.

Проблема в том, что разработчики gcc почему-то такую причину увидели,

и таки убили cdecl на amd64.

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

Кстати, предлагаю вам к последнему посту Сильви присмотреться,
в частности:
---
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
---
говорит о том, что именно ограничения 32битного АБИ снимают, а не
64битное урезают (это к спору о Анвин vs Лю)

это для MIPS , не x86(_64)

Because there are not already enough MIPS ABIs, I present the .

ну и сама мотивация достаточно забавная

Я понял, и чел другой разрабатывает, но суть всё-таки та же:
хочет снять ограничения 32битного АБИ в рамках 64битной среды.

> Вот, чтоли, ещё статья:

Это опять информация по поведению конкретного компилятора, на этот раз от IBM, причем под виндой.

Знаете, интуиция мне подсказывает, что информацию о поведении gcc

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

Естественно, грамматику я буду искать не в gcc'шном мануале, а в ISO/IEC 9899:1999. :)

Что, по вашему, раз в мануале про порядок аргументов не написано, то gcc может их в любом порядке помещать?

Нет, конечно. *Стандартный* порядок аргументов указан в спецификациях ABI, на которые я уже давал сцылки. Для атрибутов вроде fastcall информация о том, как именно их поведение отклоняется от стандарта, прописана именно в документации gcc, потому что это *расширения gcc*, а не часть какого-то стандарта, и *авторитетным* источником по ним может быть *только* *сам* *gcc*, в виде исходников или документации.

Моё утверждение в том, что cdecl заставляет его действовать именно так, как написано в этих статьях.

Вы уж извините, но я полагаю мнение аффтаров gcc и стандартов (таких, как ABI), более авторитетным, чем ваше.

И это не противоречит его мануалу, а лишь дополняет его.

В мануале написано, что cdecl, из всех платформ, на которые gcc портирован, есть только на Intel 386. И с чего бы ему внезапно появится на x32, который является одной из разновидностей amd64? Он там никому не нужен, кроме вас. Возможность передавать параметры через регистры, а не через стек – это одно из достоинств amd64, и никто от него отказываться не собирается. Еще раз: мануал на gcc естественно не описывает все на свете, потому что разного рода стандарты, которым gcc старается соответствовать, описывают большую часть его поведения. И непосредственно в мануале прописано только то, чем он отличается от этих стандартов.

Моё утверждение в том, что cdecl заставляет его действовать именно

так, как написано в этих статьях.

Вы уж извините, но я полагаю мнение аффтаров gcc и стандартов (таких,

как ABI), более авторитетным, чем ваше.

Так я не понял, вы узрели тут противоречие? Приведённый фрагмент
мануала статьям не противоречит. Вы утверждаете, что в gcc cdecl
ведёт себя по-другому? Тогда пруф. В чём именно отличие.

Он там никому не нужен, кроме вас.

Я лишь говорил про _возможность_ микса. Она не ограничивается этим
атрибутом: если не будет поддержки в ld.so, то тоже это не будет
работать. Просто требуется не так много, вот, собственно, что я
пытался сказать. А уж нужно или нет - это не мне решать. Если кому
нужно, то и сделают. На мой взгляд, было бы полезно. А я сам с
проприетарными 32битными либами не работаю, к счастью. :)

> Я лишь говорил про _возможность_ микса.

Можно и штаны через голову одевать.

Просто требуется не так много, вот, собственно, что я пытался сказать.

Просто отошлите патчик :)

На мой взгляд, было бы полезно. А я сам с проприетарными 32битными либами не работаю, к счастью. :)

Кому полезно? Назовите поимённо.

>> Я лишь говорил про _возможность_ микса.

Можно и штаны через голову одевать.

Что касается «надевателей штанов», то такие реально существуют (NSpluginwrapper): http://www.linux.com/archive/feed/55380

Уважаемый anonymous, сходите и расскажите им про ld.so и cdecl. А то они мутят какой-то там RPC для использования 32-битного flash плагина в 64-битном браузере :)

Какая разница, к чему относится? Он помогает сделать реализацию,

и тем самым участвует в разработке.

Кстати, я что-то в словах Анвина не нашёл, что performance gain,
про который он говорит - относительно 64битного ABI. Он точно так
же имел ввиду ia32, почти наверняка. И тогда противоречий в их
словах нет.

Просто отошлите патчик :)

Эта фича пока в разработке - может и сами сделают.
Если нет - значит, пользы им от этого не много.

Кому полезно? Назовите поимённо.

Тем, кто пользует 32битные закрытые либы.
Сейчас им приходится компилироваться под 32 бита, а так - можно
и под 64 в кастрированном варианте. :)

Уважаемый anonymous, сходите и расскажите им про ld.so и cdecl.

Вообще-то, у нас речь про x32 шла - новую фишку от Интела, к
которой NSpluginwrapper отношения не имеет. Я не говорил про
скрещивание 64битного ABI с 32битным, и уж точно не буду это
авторам NSpluginwrapper предлагать, так как это совсем другого порядка
проблема. А вот делателям x32, микс ia32 и x32 бы довольно дёшево
обошёлся, но, опять же, это не то же самое, что микс 64битного ABI
и 32битного.

Капча: pull rialings, типа, отодвинем в сторону реальность, как раз
про нашу дискуссию. :)

>> Кому полезно? Назовите поимённо.

Тем, кто пользует 32битные закрытые либы. Сейчас им приходится компилироваться под 32 бита, а так - можно и под 64 в кастрированном варианте. :)

Я спрашивал не про тех, кому нужно использование 32-битных библиотек, а про тех, кому нужна конкретно ваша нежизнеспособная лажа ;)

Вообще-то, у нас речь про x32 шла - новую фишку от Интела, к которой NSpluginwrapper отношения не имеет.

К x32 NSpluginwrapper имеет самое прямое отношение. Как только вы забутстрапите x32 систему и попытаетесь начать её использовать, возможно вам захочется по какой-то причине иметь работающий flash в браузере. Вы можете либо ждать, пока Adobe соизволит собрать плагин под x32 abi, либо применить NSpluginwrapper.

Я спрашивал не про тех, кому нужно использование 32-битных библиотек,

а про тех, кому нужна конкретно ваша нежизнеспособная лажа ;)

Вопрос из серии «а кому вообще этот х32 нужен» - уже проходили. :)
И то, не все ещё согласны (хотя, думаю, слова Анвина несогласные
попросту под себя переврали)

Вы можете либо ждать, пока Adobe соизволит собрать плагин под

x32 abi, либо применить NSpluginwrapper.

У вас есть инфа о портировании NSpluginwrapper под x32?
Вот если да, то можете им про ld.so и cdecl рассказать, правда,
думаю, у вас такой инфы нет.

ну вот и Glibc до hello_world-ного состояния довели

Hello world from x32 glibc
От кого   H.J. Lu <hjl.tools at gmail.com>

[hjl@gnu-6 gcc]$ cat x.c
#include <stdio.h>

int
main ()
{
printf («hello world\n»);
return 0;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -mx32 -O x.c
[hjl@gnu-6 gcc]$ ./a.out
hello world
[hjl@gnu-6 gcc]$ readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4002b0
Start of program headers: 52 (bytes into file)
Start of section headers: 3684 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 36
Section header string table index: 33
[hjl@gnu-6 gcc]$ /lib32/ld-linux-x32.so.2 --list ./a.out
linux-gate.so.1 => (0x0012e000)
libc.so.6 => /lib32/libc.so.6 (0xf7c74000)
/lib32/ld-linux-x32.so.2 (0x00110000)
[hjl@gnu-6 gcc]$

H.J.

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

> Как у вас всё замечательно автоматизировано, а при выходе новых либ старый софт почему-то ведёт себя неадекватно, устраните пожалуйста енту мелочь хотя бы за десять секунд.

Несмотря на общий жырчик, отвечу - пересборка библиотек в пределах одного поколения занимает весьма незначительное время, даже на LFS, не говоря уже о генте - которая в полной нестабильности ведёт себя крайне адекватно.

Что ты куришь и кого ты троллишь, сынок?

> Определённо новый завоз чуйки :))

Заметь, дядя, программинг и политика - смежные, но очень разные вещи.

// Gharik

> А греется он при этом как! Ну и 720p без ускорения, это даже с mplayer-mt, скажем мягко, преувеличение.

Поставь нормальные дрова и coreavc - или что ещё с поддержкой ION2-железа. Я в перелётах пробовал смотреть кинца, и таки - летает даже 1080p, лишь бы носитель выдавал объём и скорость. Кейс с жирными SD - выход, в принипе.

// Gharik

Штеудовцам мастурбировать - не привыкать. В целом, если вдуматься, состоит вся их история.

Давайте, не будем им мешать на протяжении 10 лет, э?

> Вот уже по стопам Лю предлагают чуть иной велосипед для MIPS:

Сильва, нешто и на MIPS разучились програмить?

// Gharik

> Какая разница, к чему относится? Он помогает сделать реализацию, и тем самым участвует в разработке.

Если по жизни - дрочить на железо и скилл а п.р.о.у., то отцом стать - а принципе нереальная задача.

// Gharik.