[C]n Cache alignement

[Unrue]

Ciao a tutti,

sto riguardando il cache alignment su un libro, in cui ad un certo punto fa un esempio con del codice:

size_t bytes = 128;
size_t m=16; // ( cache line in bytes)
char* base = (char*)malloc(m+bytes);

// Round pointer up to next line
char* result = (char)*((UIntPtr)(base+m)& -m);

// Record where block actually starts
((char**)result)[-1] = base;

Non ho capito cosa fanno le ultime due istruzioni. Qualcuno può chiarirmi? Grazie.

[marco.r]

Originariamente inviato da Unrue

Ciao a tutti,

sto riguardando il cache alignment su un libro, in cui ad un certo punto fa un esempio con del codice:



Non ho capito cosa fanno le ultime due istruzioni. Qualcuno può chiarirmi? Grazie.

malloc ti ritorna un puntantore non necessariamente allineato ai 16 bytes come vuoi tu (ad esempio 20).
quindi nella penultima linea salvi in result il primo indirizzo in base allineato a 16 (e.g. 32).
quindi con l'ultima riga salvi nei quattro byte precedenti a result il puntatore all'indirizzo originale, presumibilmente per poterne fare la free successivamente.

Questo almeno in teoria, in quella penultima linea ci sono diverse cose che non tornano (e sicuramente non compila), tra cui il fatto che quel (char)* probabilmente e' un (char*), e quell' & in mezzo non e' chiaro a cosa serva. Senza contare che se quell'UIntPtr e' un puntatore a unsigned int, allora sfori l'array che e' un piacere :P
Francamente userei qualcosa di piu' semplice rispetto a quella linea, tipo

char* result = base + m - (base%m);

Il codice (il mio, ma a naso forse anche quello originale) funziona nell'ipotesi che la memoria ritornata sia cmq allineata almeno a sizeof(void*), altrimenti potresti non avere spazio sufficiente per salvare
il puntatore nell'ultima riga.

Detto questo, se sei in ambiente unix prova a dare una occhiata a posix_memalign.

[Unrue]

Originariamente inviato da marco.r

Questo almeno in teoria, in quella penultima linea ci sono diverse cose che non tornano (e sicuramente non compila), tra cui il fatto che quel (char)* probabilmente e' un (char*),

Si, ho sbagliato a trascrivere

Originariamente inviato da marco.r

e quell' & in mezzo non e' chiaro a cosa serva.

Questo invece l'ho trascritto correttamente, non capisco proprio cosa cosa faccia quella istruzione a livello di sintassi C, al di là dell'allineamento

Originariamente inviato da marco.r

Senza contare che se quell'UIntPtr e' un puntatore a unsigned int, allora sfori l'array che e' un piacere :P

Già..

Originariamente inviato da marco.r

Francamente userei qualcosa di piu' semplice rispetto a quella linea, tipo

char* result = base + m - (base%m);

Concordo.

Originariamente inviato da marco.r

Il codice (il mio, ma a naso forse anche quello originale) funziona nell'ipotesi che la memoria ritornata sia cmq allineata almeno a sizeof(void*), altrimenti potresti non avere spazio sufficiente per salvare
il puntatore nell'ultima riga.

Mm, puoi spiegarmi meglio?

Originariamente inviato da marco.r

Detto questo, se sei in ambiente unix prova a dare una occhiata a posix_memalign.

Thanks!!

[cdimauro]

L' & -m serve ad azzerare i bit meno significati (i primi 4, visto che m è pari a 16) del puntatore, così da farlo diventare allineato a 128 bit.

Non è un'istruzione strana. E' molto comune e usata per questa particolare operazione (classico "and masking"; alcuni microprocessori hanno addirittura istruzioni dedicate).

[marco.r]

Originariamente inviato da cdimauro

L' & -m serve ad azzerare i bit meno significati (i primi 4, visto che m è pari a 16) del puntatore, così da farlo diventare allineato a 128 bit.

Non è un'istruzione strana. E' molto comune e usata per questa particolare operazione (classico "and masking"; alcuni microprocessori hanno addirittura istruzioni dedicate).

L'istruzione non e' strana, ma in mezzo a quei cast e refusi l'avevo scambiata per un &prefisso (prendi l'indirizzo di) e non l'omonimo operatore binario
Allora ora e' tutto chiaro, direi che funziona come inteso.

[cdimauro]

L'offuscamento del codice è una delle "feature" del C.