Dotaz: vyznam aligned v C

[honza]

Zdravim, Cital som o atribute aligned v C a chcem sa uistit ze to chapem spravne, pretoze moje pokusy to nenaznacuju. Tento atribut by mal zarovnavat hodnoty struktur alebo jednotlivych premennych na zadany pocet bytov. Pr: int i __attribute__((aligned(128))); printf("%d", sizeof(i)); prikaz printf by mal vypisat velkost 128, ale vypise 4!

---

---

Odpovědi

[Jirka P]

Alignment určuje zarovnání, ne velikost (toho, co se zarovnává), Prakticky bys to ověřil takto:

int i __attribute__((aligned(128)));
assert((intptr_t)&i % 128 == 0);

Je samozřejmě možné, že použití aligned "něco" zvětší (strukturu obsahující daný prvek, nebo spotřebu zásobníku), ale není to nezbytně nutné.

[kulik]

To by jeste schazelo, aby mel najednou integer 128 bajtu Podivej se treba na wikipedii, tam je to dobre vysvetlene.

[honza]

Tak ze, ak tomu spravne chapem, tak pouziva sa to za zarovnanie adries na ktorych lezia v pamati hodnoy aby boli delitelne cislom ktorym zarovnavam bezozvysku.

tak ze toto:

int main(void)
{
    static float a[4] __attribute__((aligned(128))) = {1.0, 2.0, 3.0, 4.0};
    printf("%8u %8u %8u %8u\n", &a[0], &a[1], &a[2], &a[3]);
    return 0;
}

vypise takyto vysledok: 268509056 268509060 268509064 268509068 Prva adresa je dlitelna 128 bezozvysku, ale druha, tretia a stvrta adresa uz nie. Cize prva adresa aj u viacrozmernych poli bude delitelna bezozvysku cislom ktorym zarovnavam. Ale preco tato struktura ma velkost 32:

struct {
    char a;
    int c __attribute__ ((aligned (16)));
    char b;
}

[mato]

caf,

zarovnava celu strukturu na najmensi spolocny nasobok .. ak to spravne teda pomenuvavam ..

ked to rozoberes:

char a;   // 2B
int c;    // 16B
char b;   // 2B , dokopy 18B  

zarovnavam na nasobky 16, tj 32 je najblizsi nasobok 16, kde (2+16+2) < 32 .. neviem ci sa to da chapat, co pisem .. :)

[Jirka P]

static float a[4] __attribute__((aligned(128)));

Prva adresa je dlitelna 128 bezozvysku, ale druha, tretia a stvrta adresa uz nie.

To není překvapení, ten atribut se týká celého pole. Tzn. adresa pole je zarovnaná, pole jsou v C vždy "packed" (tedy je-li T* p, platí (char*)(p+1)-(char*)p==sizeof(T)).

Ale preco tato struktura ma velkost 32:

Představ si, že chceš udělat pole tvých struktur. Potom (intptr_t)&array[0].c % 16 == 0, stejně tak (intptr_t)&array[1].c % 16 == 0. To znamená, že i ((char*)&array[1].c-(char*)&array[0].c) % 16 == 0 == sizeof(struct...) % 16, z toho vyplývá, že velikost té struktury je dělitelná 16. No a 16 to být nemůže, protože c musí být v paměti za a (a z implementačních důvodů nelze mít celou strukturu zarovnanou např. na adresy -1 mod 16, takže a bude taky zarovnané aspoň na 16).

Prakticky ta struktura vypadá takto:

1 byte   a
15 byte  - nic
4 byte   c
1 byte   b
11 byte  - nic

[honza]

Ok tomu rozumiem, a bude lezat na nasobku 16-ky za nim c tiez na nasobku 16-ky, potom b, ale nechapem tych 11 byte ak ta struktura nebude v poli. nemal by to kompilator rozozna pri preklade a malo by stacit na nu 21 byte?

[Petr Šobáň]

Mělo by mu stačit 21, vše záleží zda další proměnnou zarovná na nějaký násobek, nebo nezarovná a bude hned za tou zarovnanou.

Já bych se tímto nezabýval, zarovnání má hlavně vliv kvůli CPU které třeba v jednom taktu může tu proměnnou přečíst, když nebude zarovnaná spotřebuje CPU taktů víc.

O správné zarovnání se stará sám překladač podle nastavených optimalizací a netřeba do toho zasahovat pokud nepotřebuješ k datům přistupovat přímo.

Vaše zarovnání:

    .file    "pokus.c"
    .section    .rodata
.LC0:
    .string    "%8u %8u %8u %8u\n"
    .text
.globl main
    .type    main, @function
main:
.LFB0:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    movq    %rsp, %rbp
    .cfi_offset 6, -16
    .cfi_def_cfa_register 6
    movl    $.LC0, %eax
    movl    $a.2051+12, %r8d
    movl    $a.2051+8, %ecx
    movl    $a.2051+4, %edx
    movl    $a.2051, %esi
    movq    %rax, %rdi
    movl    $0, %eax
    call    printf
    movl    $0, %eax
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size    main, .-main
    .data
    .align 128
    .type    a.2051, @object
    .size    a.2051, 16
a.2051:
    .long    1065353216
    .long    1073741824
    .long    1077936128
    .long    1082130432
    .ident    "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
    .section    .note.GNU-stack,"",@progbits

a když to necháte na překladači:

    .file    "pokus.c"
    .section    .rodata
.LC0:
    .string    "%8u %8u %8u %8u\n"
    .text
.globl main
    .type    main, @function
main:
.LFB0:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    movq    %rsp, %rbp
    .cfi_offset 6, -16
    .cfi_def_cfa_register 6
    movl    $.LC0, %eax
    movl    $a.2051+12, %r8d
    movl    $a.2051+8, %ecx
    movl    $a.2051+4, %edx
    movl    $a.2051, %esi
    movq    %rax, %rdi
    movl    $0, %eax
    call    printf
    movl    $0, %eax
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size    main, .-main
    .data
    .align 16
    .type    a.2051, @object
    .size    a.2051, 16
a.2051:
    .long    1065353216
    .long    1073741824
    .long    1077936128
    .long    1082130432
    .ident    "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
    .section    .note.GNU-stack,"",@progbits

[Jirka P]

Ne, to by bylo prakticky nemožné. Každý typ, který může mít nějaká proměnná, může být typem prvku pole. A kompilátor by musel projít celý kód (=všechny zdrojáky, které se linkují do výsledné binárky, včetně dynamických knihoven), aby mohl zjistit, že daná struktura opravdu prvkem pole není (což v sobě obsahuje např. i použití pointrové aritmetiky na jejím typu).

Spíš uvidíš optimalizaci typu "kašlem na strukturu, na zásobník (nebo do registrů) to nějak naboucháme", kterou kompilátor může udělat, pokud daná instance té struktury neprosákne někam ven z funkce (přes pointer). Pak ta struktura na zásobníku zabere méně než 32 bytů, ale sizeof bude pořád 32.

[honza]

Ale ked mam jednoduchy program, kde zadefinujem strukturu, tak by to prekladac mohol vediet, ze som nezadefinoval ziadne pole konkretnych sruktur.

[Vojtěch Horký]

To by mohl předpokládat tehdy, pokud se tam neobjeví ukazatel na tuhle strukturu. A jelikož to je v Céčkových programech poměrně řídký jev (že nějaký datový typ není vůbec použit jako ukazatel), IMHO se to nebude nikomu chtít implementovat.

[timi]

Dakujem Vsetkym za zapojenie sa do diskusie a odpovede.