Qual è lo scopo del registro del puntatore del frame EBP?

Sono un principiante nel linguaggio assembly e ho notato che il codice x86 emesso dai compilatori di solito mantiene il puntatore del frame anche in modalità di rilascio / ottimizzato quando potrebbe usare il EBPregistro per qualcos'altro.

Capisco perché il puntatore al frame potrebbe semplificare il debug del codice e potrebbe essere necessario se alloca()viene chiamato all'interno di una funzione. Tuttavia, x86 ha pochissimi registri e usarne due per contenere la posizione dello stack frame quando uno sarebbe sufficiente non ha senso per me. Perché omettere il frame pointer è considerata una cattiva idea anche nelle build ottimizzate / di rilascio?

Il puntatore al frame è un puntatore di riferimento che consente a un debugger di sapere dove si trova una variabile locale o un argomento con un singolo offset costante. Sebbene il valore di ESP cambi nel corso dell'esecuzione, EBP rimane lo stesso, consentendo di raggiungere la stessa variabile con lo stesso offset (come il primo parametro sarà sempre EBP + 8 mentre gli offset ESP possono cambiare in modo significativo poiché si spinge / schioccare cose)

Perché i compilatori non buttano via il frame pointer? Perché con il puntatore al frame, il debugger può capire dove le variabili e gli argomenti locali stanno usando la tabella dei simboli poiché è garantito che siano a un offset costante rispetto a EBP. Altrimenti non c'è un modo semplice per capire dove si trova una variabile locale in qualsiasi punto del codice.

Come menzionato da Greg, aiuta anche a svolgere lo stack per un debugger poiché EBP fornisce un elenco collegato inverso di stack frame, consentendo quindi al debugger di calcolare la dimensione dello stack frame (variabili locali + argomenti) della funzione.

La maggior parte dei compilatori fornisce un'opzione per omettere i puntatori ai frame sebbene renda il debug molto difficile. Questa opzione non dovrebbe mai essere utilizzata globalmente, nemmeno nel codice di rilascio. Non sai quando dovrai eseguire il debug del crash di un utente.

Aggiungo solo i miei due centesimi a risposte già buone.

Fa parte di una buona architettura del linguaggio avere una catena di stack frame. Il BP punta al frame corrente, dove sono memorizzate le variabili locali della subroutine. (Le persone locali hanno offset negativi e gli argomenti sono offset positivi.)

L'idea che impedisca l'utilizzo di un registro perfettamente valido nell'ottimizzazione solleva la domanda: quando e dove l'ottimizzazione è effettivamente utile?

L'ottimizzazione è utile solo in cicli ristretti che 1) non chiamano funzioni, 2) dove il contatore del programma trascorre una frazione significativa del suo tempo e 3) nel codice che il compilatore effettivamente vedrà mai (cioè funzioni non di libreria). Questa è solitamente una frazione molto piccola del codice complessivo, specialmente nei sistemi di grandi dimensioni.

Altro codice può essere distorto e compresso per sbarazzarsi dei cicli, e semplicemente non avrà importanza, perché il contatore del programma non è praticamente mai lì.

So che non l'hai chiesto, ma nella mia esperienza, il 99% dei problemi di prestazioni non ha nulla a che fare con l'ottimizzazione del compilatore. Hanno tutto a che fare con l'over-design.

Dipende dal compilatore, certamente. Ho visto codice ottimizzato emesso da compilatori x86 che utilizza liberamente il registro EBP come registro per scopi generali. (Non ricordo con quale compilatore l'ho notato, però.)

I compilatori possono anche scegliere di mantenere il registro EBP per facilitare lo svolgimento dello stack durante la gestione delle eccezioni, ma ancora una volta questo dipende dalla precisa implementazione del compilatore.

Tuttavia, x86 ha pochissimi registri

Questo è vero solo nel senso che gli opcode possono indirizzare solo 8 registri. Il processore stesso avrà in realtà molti più registri di quello e utilizzerà la ridenominazione dei registri, il pipelining, l'esecuzione speculativa e altre parole d'ordine del processore per aggirare quel limite. Wikipedia ha un buon paragrafo introduttivo su cosa può fare un processore x86 per superare il limite di registrazione: http://en.wikipedia.org/wiki/X86#Current_implementations .

L'uso di stack frame è diventato incredibilmente economico in qualsiasi hardware, anche remotamente moderno. Se hai stack frame economici, salvare un paio di registri non è così importante. Sono sicuro che gli stack frame veloci rispetto a più registri sono stati un compromesso ingegneristico e gli stack frame veloci hanno vinto.

Quanto risparmi andando puro registro? Ne vale la pena?