Понимание базовых указателей и указателей стека: в контексте с выводом gcc - PullRequest
Новая
       16

Понимание базовых указателей и указателей стека: в контексте с выводом gcc

11 голосов
/ 12 декабря 2011

У меня есть следующая программа на C: 

int main()
{
    int c[10] = {0, 0, 0, 0, 0, 0, 0, 0, 1, 2};
    return c[0];
}

и при компиляции с использованием директивы -S с gcc я получаю следующую сборку: 

    .file   "array.c"
    .text
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $0, -48(%rbp)
    movl    $0, -44(%rbp)
    movl    $0, -40(%rbp)
    movl    $0, -36(%rbp)
    movl    $0, -32(%rbp)
    movl    $0, -28(%rbp)
    movl    $0, -24(%rbp)
    movl    $0, -20(%rbp)
    movl    $1, -16(%rbp)
    movl    $2, -12(%rbp)
    movl    -48(%rbp), %eax
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (GNU) 4.4.5 20110214 (Red Hat 4.4.5-6)"
    .section        .note.GNU-stack,"",@progbits

Что я не понимаю, так этопочему более ранние элементы массива находятся дальше от bp?Кажется, что элементы массива располагаются в обратном порядке.

Кроме того, почему gcc не использует push вместо movl для помещения элементов массива в стек?

РАЗЛИЧНЫЙ ВИД

Перемещениемассив в глобальное пространство имен как статическая переменная для модуля, который я получаю: 

    .file   "array.c"
    .data
    .align 32
    .type   c, @object
    .size   c, 40
c:
    .long   0
    .long   0
    .long   0
    .long   0
    .long   0
    .long   0
    .long   0
    .long   0
    .long   1
    .long   2
    .text
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    c(%rip), %eax
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (GNU) 4.4.5 20110214 (Red Hat 4.4.5-6)"
    .section    .note.GNU-stack,"",@progbits

Используя следующую программу на C: 

static int c[10] = {0, 0, 0, 0, 0, 0, 0, 0, 1, 2};

int main() 
{
    return c[0];
}

Это не дает более глубокого понимания стека.Но интересно видеть разницу в сборке с использованием немного другой семантики.

Ответы [ 3 ]

9 голосов
/ 12 декабря 2011

Прежде всего, стек x86 растет вниз.По соглашению rbp сохраняет исходное значение rsp.Следовательно, аргументы функции находятся в положительных смещениях относительно rbp, а ее автоматические переменные находятся в отрицательных смещениях.Первый элемент автоматического массива имеет более низкий адрес, чем все остальные элементы, и, следовательно, является самым дальним от rbp.

Вот удобная диаграмма, которая появляется на этой странице :

stack layout

Я не вижу причин, по которым компилятор не может использовать серию push инструкций для инициализации вашего массива.Будет ли это хорошей идеей, я не уверен.

3 голосов
/ 12 декабря 2011

Кроме того, почему gcc не использует push вместо movl, чтобы поместить элементы массива в стек?

Очень редко иметь большой инициализированный массив в нужном месте в кадре стека, чтобы вы могли использовать последовательность нажатий, поэтому gcc не учили это делать. (Более подробно: инициализация массива обрабатывается как копия памяти блока, которая генерируется либо как последовательность инструкций перемещения, либо как вызов memcpy, в зависимости от того, насколько большим он будет. Код, который решает, что выдавать, не ' Я не знаю, куда в памяти уходит блок, поэтому он не знает, может ли он использовать push.

Кроме того, movl быстрее. В частности, push выполняет неявное чтение-изменение-запись %esp, и поэтому последовательность push должна выполняться по порядку. movl к независимым адресам, напротив, может выполняться параллельно. Таким образом, используя последовательность movl s, а не push es, gcc предлагает процессору больше параллелизма на уровне команд, чтобы использовать преимущества.

Обратите внимание, что если я скомпилирую ваш код с активированным уровнем оптимизации, массив полностью исчезнет! Вот -O1 (это результат запуска objdump -dr в объектном файле, а не -S, чтобы вы могли увидеть фактический машинный код) 

0000000000000000 <main>:
   0:   b8 00 00 00 00          mov    $0x0,%eax
   5:   c3                      retq

и -Os: 

0000000000000000 <main>:
   0:   31 c0                   xor    %eax,%eax
   2:   c3                      retq

Ничего не делать всегда быстрее, чем что-то делать. Очистка регистра с помощью xor составляет два байта вместо пяти, но имеет формальную зависимость данных от старого содержимого регистра и изменяет коды условий, поэтому может быть медленнее и поэтому выбирается только при оптимизации для размера.

2 голосов
/ 12 декабря 2011

Имейте в виду, что на x86 стек растет вниз. Нажатие на стек вычтет указатель стека. 

%rbp <-- Highest memory address
-12
-16
-20
-24
-28
-32
-36
-40
-44
-48  <-- Address of array
...