2012-12-27 25 views
5

Sapevo che le variabili di registro sono memorizzate nei registri della CPU.come sapere dove è memorizzata la variabile di registro?

E le stesse variabili vengono memorizzate nello stack se i registri della CPU sono occupati/pieni.

Come posso sapere se la variabile è memorizzata nello stack o nel registro CPU?

+1

Il l'unico modo per sapere con certezza è di esaminare l'output in linguaggio assembly dal tuo compilatore. –

+0

le ipotesi sono sbagliate e l'ultima domanda non può essere risolta poiché non hai controllo diretto in questo. – user1824407

+0

@GregHewgill non proprio, anche ci sono variabili come la quantità di cache dipendente dall'hardware e non è possibile prevedere la quantità di cache della CPU. puoi leggere la tua assemblea: qual è il punto? – user1824407

risposta

6

Io sono d'accordo con il signor Rilassatevi di answer, ma fino a un certo estendere questo modo può essere utile a voi:

nome del file x.c:

int main(){ 
    register int i=0; 
    i++; 
    printf("%d",i); 
} 

Assemblare codice:

~$ gcc x.c -S 

il nome del file di output è x.s.

Nel mio caso viene utilizzato il registro ebx, che può essere la differenza in diversi tempi di compilazione.

~$ cat x.s 
    .file "x.c" 
    .section .rodata 
.LC0: 
    .string "%d" 
    .text 
.globl main 
    .type main, @function 
main: 
    pushl %ebp 
    movl %esp, %ebp 
    andl $-16, %esp 
    pushl %ebx 
    subl $28, %esp 
    movl $0, %ebx 
    addl $1, %ebx    // because i++ 
    movl $.LC0, %eax 
    movl %ebx, 4(%esp) 
    movl %eax, (%esp) 
    call printf 
    addl $28, %esp 
    popl %ebx 
    movl %ebp, %esp 
    popl %ebp 
    ret  

È possibile anche smontare l'eseguibile utilizzando objdunp:

$ gcc x.c -o x 
$ objdump x -d 

uscita assemblaggio parziale utilizzando objdump comando:

080483c4 <main>: 
80483c4: 55      push %ebp 
80483c5: 89 e5     mov %esp,%ebp 
80483c7: 83 e4 f0    and $0xfffffff0,%esp 
80483ca: 53      push %ebx 
80483cb: 83 ec 1c    sub $0x1c,%esp 
80483ce: bb 00 00 00 00   mov $0x0,%ebx 
80483d3: 83 c3 01    add $0x1,%ebx   //due to i++ 
80483d6: b8 b0 84 04 08   mov $0x80484b0,%eax 
80483db: 89 5c 24 04    mov %ebx,0x4(%esp) 
80483df: 89 04 24    mov %eax,(%esp) 
80483e2: e8 0d ff ff ff   call 80482f4 <[email protected]> 
80483e7: 83 c4 1c    add $0x1c,%esp 
80483ea: 5b      pop %ebx 
80483eb: 89 ec     mov %ebp,%esp 
80483ed: 5d      pop %ebp 
80483ee: c3      ret  
80483ef: 90      nop 

%ebx registro riservato per le variabili registro.

6

No, non è possibile.

E 'deciso dal compilatore, e potrebbe cambiare tra le compilation, se, per esempio, il codice che circonda cambia il register pressure o se flag di compilazione sono cambiati.

+3

Solo per essere un po 'pedante la domanda dice come può saperlo, non come può controllarlo. Sono d'accordo con Greg Hewgill nel suo commento che puoi determinare dall'output dell'assembler. – PeterJ

3

Sono anche d'accordo con la risposta di UnWind, d'altra parte il disassemblaggio del codice in GDB può dare l'archiviazione delle variabili. Smontaggio di un codice vaga, che ho fornisce i locali di quel telaio come sotto,

(gdb) info locals 
i = 0 
ret = <value optimized out> 
k = 0 
ctx = (BN_CTX *) 0x632e1cc8 
A1 = (BIGNUM *) 0x632e1cd0 
A1_odd = (BIGNUM *) 0x632e1ce8 
check = <value optimized out> 
mont = (BN_MONT_CTX *) 0x632e2108 
A = (const BIGNUM *) 0x632e2028 

Ora, se provare a stampare l'indirizzo della gente del posto che mi dice la posizione di archiviazione come sotto,

(gdb) p &i 
$16 = (int *) 0x143fba40 
(gdb) p &k 
$17 = (int *) 0x143fba38 
(gdb) p &mont 
Address requested for identifier "mont" which is in register $s7 
(gdb) 

Qui oggetti i e k sono in pila e mont è nel registro $ s7.

1

Secondo il libro "L'Ansi C Programming Language - Seconda Edizione" di Brian W. Kernighan & Dennis M.Ritchie (I fondatori dei linguaggi C), non è possibile.

Capitolo 4, pagina 84,

" ...E non è possibile prendere l'indirizzo della variabile di registro, a prescindere se la variabile è in realtà posto in una register."

Speranza che aiuta! Buona fortuna per il futuro, Ron

Problemi correlati