Perché l'ABI Mac richiede l'allineamento dello stack di 16 byte per x86-32?
https://stackoverflow.com/questions/612443
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Posso capire questo requisito per i vecchi sistemi RISC PPC e anche per x86-64, ma per il vecchio provato x86 vero? In questo caso, lo stack deve essere allineato solo su limiti di 4 byte. Sì, alcune delle istruzioni MMX / SSE richiedono allineamenti a 16byte, ma se questo è un requisito della chiamata, allora dovrebbe assicurarsi che gli allineamenti siano corretti. Perché caricare ogni chiamante con questo requisito aggiuntivo? Ciò può effettivamente causare un calo delle prestazioni perché ogni sito di chiamata deve gestire questo requisito. Mi sto perdendo qualcosa?
Aggiornamento: dopo alcune ulteriori indagini su questo e alcune consultazioni con alcuni colleghi interni, ho alcune teorie al riguardo:
- Coerenza tra la versione PPC, x86 e x64 del sistema operativo
- Sembra che il codegen GCC ora esegua coerentemente un sub esp, xxx e quindi "sposta" i dati nello stack piuttosto che semplicemente facendo un "push". istruzioni. Questo potrebbe effettivamente essere più veloce su alcuni componenti hardware.
- Anche se questo complica un po 'i siti di chiamata, ci sono pochissime spese generali extra quando si utilizza il predefinito "quotecl" convenzione in cui il chiamante pulisce lo stack.
Il problema che ho con l'ultimo articolo, è che per chiamare le convenzioni che si basano sul fatto che il pullee pulisce lo stack, i requisiti di cui sopra davvero " uglifies " il codegen. Ad esempio, cosa ha deciso un compilatore di implementare uno stile di chiamata basato su registro più veloce per il proprio uso interno (ovvero qualsiasi codice che non è destinato a essere chiamato da altre lingue o fonti)? Questa cosa di allineamento dello stack potrebbe annullare alcuni dei miglioramenti delle prestazioni ottenuti passando alcuni parametri nei registri.
Aggiornamento: Finora le uniche risposte reali sono state la coerenza, ma per me è un po 'troppo facile una risposta. Ho oltre 20 anni di esperienza con l'architettura x86 e se la coerenza, non le prestazioni o qualcos'altro di concreto, è davvero il motivo, allora suggerisco rispettosamente che è un po 'ingenuo per gli sviluppatori di richiederlo. Stanno ignorando quasi tre decenni di strumenti e supporto. Soprattutto se si aspettano che i venditori di strumenti adattino rapidamente e facilmente i loro strumenti per la loro piattaforma (forse non ... è è Apple ...) senza dover saltare attraverso diversi cerchi apparentemente non necessari.
Daremo questo argomento circa un altro giorno e poi lo chiuderò ...
correlati
Soluzione
Da " Manuale di riferimento per l'ottimizzazione delle architetture Intel & # 174; 64 e IA-32 " ;, sezione 4.4.2:
" Per prestazioni ottimali, le estensioni SIMD di streaming e le estensioni SIMD di streaming 2 richiedono che i loro operandi di memoria siano allineati ai limiti di 16 byte. I dati non allineati possono causare penali di rendimento significative rispetto ai dati allineati. & Quot;
Dall'appendice D:
" È importante assicurarsi che il frame dello stack sia allineato a un limite di 16 byte al momento dell'inserimento della funzione per mantenere allineati i dati __m128 locali, i parametri e le posizioni di fuoriuscita del registro XMM durante l'invocazione di una funzione. "
Altri suggerimenti
Non sono sicuro perché non ho una prova diretta, ma credo che il motivo sia SSE. SSE è molto più veloce se i tuoi buffer sono già allineati su un limite di 16 byte (movps vs movups) e qualsiasi x86 ha almeno sse2 per mac os x. Può essere curato dall'utente dell'applicazione, ma il costo è piuttosto significativo. Se il costo complessivo per renderlo obbligatorio nell'ABI non è troppo significativo, può valerne la pena. SSE è usato abbastanza pervasivamente in mac os X: accelerare il framework, ecc ...
Credo che sia per tenerlo in linea con l'ABI x86-64.
Innanzitutto, notare che l'allineamento di 16 byte è un'eccezione introdotta da Apple all'ABI System V IA-32.
L'allineamento dello stack è necessario solo quando si chiamano le funzioni di sistema, poiché molte librerie di sistema utilizzano estensioni SSE o Altivec che richiedono l'allineamento di 16 byte. Ho trovato un riferimento esplicito nella libgmalloc Pagina MAN .
Puoi gestire perfettamente il frame dello stack nel modo desiderato, ma se provi a chiamare una funzione di sistema con uno stack non allineato, finirai con un messaggio misaligned_stack_error .
Modifica Per la cronaca, puoi eliminare i problemi di allineamento durante la compilazione con GCC utilizzando opzione mstack-realign .
Questo è un problema di efficienza.
Assicurarsi che lo stack sia allineato a 16 byte in ogni funzione che utilizza le nuove istruzioni SSE aggiunge un sacco di sovraccarico per l'utilizzo di tali istruzioni, riducendo efficacemente le prestazioni.
D'altra parte, mantenendo lo stack di 16 byte sempre allineato, è possibile utilizzare liberamente le istruzioni SSE senza penalizzare le prestazioni. Non vi è alcun costo per questo (costo misurato almeno nelle istruzioni). Implica solo la modifica di una costante nel prologo della funzione.
Lo spreco di spazio nello stack è economico, è probabilmente la parte più calda della cache.
La mia ipotesi è che Apple creda che tutti usino semplicemente XCode (gcc) che allinea lo stack per te. Quindi è necessario allineare lo stack in modo che il kernel non debba essere solo una micro-ottimizzazione.
Anche se non posso davvero rispondere alla tua domanda su PERCHÉ, potresti trovare utili i manuali sul seguente sito:
http://www.agner.org/optimize/
Per quanto riguarda l'ABI, dai un'occhiata in particolare a:
http://www.agner.org/optimize/calling_conventions.pdf
Spero sia utile.
Hmm, OS X ABI non ha fatto anche divertenti RISC come cose come passare piccole strutture nei registri?
Quindi questo indica la coerenza con la teoria delle altre piattaforme.
Vieni a pensarci bene, l'api syscall di FreeBSD allinea anche i valori a 64 bit. (come ad esempio lseek e mmap)
Al fine di mantenere la coerenza nel kernel. Ciò consente di avviare lo stesso kernel su più architetture senza modifiche.
Non sai perché nessuno ha preso in considerazione la possibilità di una facile portabilità dalla piattaforma legacy basata su PowerPC?
Leggi questo:
E poi ingrandito " Convenzioni di chiamata della funzione PowerPC a 32 bit " e infine questo:
" Queste sono le modalità di allineamento dell'incorporamento disponibili a 32 bit Ambiente PowerPC:
La modalità di allineamento di potenza è derivata dalle regole di allineamento utilizzate da Compilatore IBM XLC per il sistema operativo AIX. È l'impostazione predefinita modalità di allineamento per la versione in architettura PowerPC di GCC utilizzata su AIX e Mac OS X. Perché questa modalità è molto probabilmente compatibile tra compilatori con architettura PowerPC di diversi fornitori, lo è tipicamente utilizzato con strutture dati condivise tra differenti . Programmi "
Alla luce del precedente background di OSX basato su PowerPC, la portabilità è una considerazione importante: detta la convenzione fino al compilatore XLC di AIX. Quando pensi in termini della necessità di assicurarti che tutti gli strumenti e le applicazioni funzionino insieme con rilavorazioni minime, penso che sia importante attenersi il più possibile alla stessa ABI legacy.
Questo dà la filosofia e leggere ulteriormente è la regola esplicitamente menzionata ("Prolog ed Epilog"):
La funzione chiamata è responsabile dell'allocazione il proprio stack frame, assicurandosi di preservare l'allineamento di 16 byte nel file pila. Questa operazione viene eseguita da una sezione di codice chiamata prologo, che il compilatore posiziona davanti al corpo della subroutine. Dopo il corpo della subroutine, il compilatore posiziona un epilogo a ripristinare il processore allo stato precedente alla subroutine chiamare.
