как помогает выравнивание в си для языка ассемблера?

i-rinat. Я читал где-то но не помню где и про что.

Ты не только программировать, ты даже внятно изъясняться на русском не можешь...

Неужели человек с вашим складом ума не может меня понять?

int main ()
{
        char af[100] __attribute__ ((aligned(32)));

        af[1] = 32;
}

Вот дизассемблер

   0x00000000004004a6 <+0>:	lea    0x8(%rsp),%r10
   0x00000000004004ab <+5>:	and    $0xffffffffffffffe0,%rsp
   0x00000000004004af <+9>:	pushq  -0x8(%r10)
   0x00000000004004b3 <+13>:	push   %rbp
   0x00000000004004b4 <+14>:	mov    %rsp,%rbp
=> 0x00000000004004b7 <+17>:	push   %r10
   0x00000000004004b9 <+19>:	sub    $0x10,%rsp
   0x00000000004004bd <+23>:	movb   $0x20,-0x8f(%rbp)
   0x00000000004004c4 <+30>:	mov    $0x0,%eax
   0x00000000004004c9 <+35>:	add    $0x10,%rsp
   0x00000000004004cd <+39>:	pop    %r10
   0x00000000004004cf <+41>:	pop    %rbp
   0x00000000004004d0 <+42>:	lea    -0x8(%r10),%rsp
   0x00000000004004d4 <+46>:	retq 

Вот другой пример.

int main ()
{
        char af[100];

        af[1] = 32;
}

   0x00000000004004a6 <+0>:	push   %rbp
   0x00000000004004a7 <+1>:	mov    %rsp,%rbp
=> 0x00000000004004aa <+4>:	movb   $0x20,-0x6f(%rbp)
   0x00000000004004ae <+8>:	mov    $0x0,%eax
   0x00000000004004b3 <+13>:	pop    %rbp
   0x00000000004004b4 <+14>:	retq 

i-rinat а выравнивание на 4 действительно никакого эффекта не даёт.

int main ()
{
        char af[100];

А оно сработает)?

как помогает выравнивание в си для языка ассемблера?

Никак.

Я дам тебе ⅔ ответа на исходный вопрос, намеренно опустив некоторые случаи вроде передачи данных по сети. Ключевая фраза «машинное слово». Перестань уже читать умные книжки, тебе это лишь вредит

Что-то начинаю вспоминать, или это я представляю что вспоминаю.

Ключевая фраза «машинное слово».

Это для простых книжек. А вот для инструкций mmx, sse, sse2 - там другое «машинное слово»

Ждём новую версию просмотрщика RFC, с оптимизацией на SSE2. Теперь ещё на 100 нс быстрее.

Ну да, сначала некоторые делают программу простым кодом, а потом улучшают быстродействие.

Ждём новую версию просмотрщика RFC, с оптимизацией на SSE2.

Зря иронизируете, уже никто не гарантирует, что компилятор вас не спросит и вставит. Главное, чтобы ТС ему не мешал, а то он может, да.

учи русский язык. Если сложности в формулировке своих мыслей - читай книги.

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

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

Что значит не гарантирует? GCC на x86-64 для вычислений с плавающей точкой использует SSE/SSE2. Чтобы не использовал, его нужно отдельно попросить. Можно считать, что уже гарантируется, что SSE2 будет использоваться.

для вычислений с плавающей точкой

Что, без этого никак просмотрщик RFC не написать?

я представляю что вспоминаю

inception

Это уже к ТС вопрос.

Чувак, напиши морду к sane на Gtk3

Для просмоторщика в си коде вычислений с плавающей точкой не нужно.

Совсем поехавший? Нафига ты в стеке-то выравнивание просишь?

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

а, нет, адреса разные.

Тебя спросили «Зачем ты это делаешь» а не «как оно работает». Чего ты хочешь добиться в конце, повысить производительность? Думаю что этим флагом только хуже сделаешь.

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

Не уверен что правильно понял вопрос, но никак не помогает. Данный атрибут помогает компилятору оптимизировать код. Зачем его применять к int'у вообще ума не приложу. Почитать про выравнивание можно здесь

Доступ к выровненным данным осуществляется быстрее.
Почему так - особенности архитектуры. При обращении по невыровненным адресам может потребоваться больше шинных циклов, чем для выровненных адресов. Хотя это может уже не так для современных процессоров.
Но хуже всего, если твой int попадет на 2 разные страницы памяти,тогда обращение к нему чревато двумя pagefault'ами. Поэтому если уж выравнивать - то по-взрослому, на 4Кб.

При обращении по невыровненным адресам может потребоваться больше шинных циклов

А на каком-нибудь arm или powerpc можно поймать bus error.