gpt4 book ai didi

assembly - 如何知道汇编代码正在使用 RAM?

转载 作者:行者123 更新时间:2023-12-03 06:31:45 25 4
gpt4 key购买 nike

我对汇编非常陌生,这是一个基本问题。

我刚刚听说过使用 zero bytes of RAM 的概念.

我通过

编译了 C++ 代码
g++ -O3 main.cpp -S -o main3.s

main.cpp (source)

#include <iostream>
using namespace std;

int main()
{
int low=10, high=100, i, flag;

cout << "Prime numbers between " << low << " and " << high << " are: ";

while (low < high)
{
flag = 0;

for(i = 2; i <= low/2; ++i)
{
if(low % i == 0)
{
flag = 1;
break;
}
}

if (flag == 0)
cout << low << " ";

++low;
}

return 0;
}

结果如下:

main3.s

    .file   "main.cpp"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Prime numbers between "
.LC1:
.string " and "
.LC2:
.string " are: "
.LC3:
.string " "
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB1561:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl $22, %edx
movl $.LC0, %esi
movl $_ZSt4cout, %edi
call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
movl $10, %esi
movl $_ZSt4cout, %edi
call _ZNSolsEi
movl $5, %edx
movq %rax, %rbx
movl $.LC1, %esi
movq %rax, %rdi
call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
movq %rbx, %rdi
movl $100, %esi
movl $10, %ebx
call _ZNSolsEi
movl $.LC2, %esi
movq %rax, %rdi
call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
.p2align 4,,10
.p2align 3
.L6:
movl %ebx, %esi
sarl %esi
testb $1, %bl
je .L2
movl $2, %ecx
jmp .L3
.p2align 4,,10
.p2align 3
.L14:
movl %ebx, %eax
cltd
idivl %ecx
testl %edx, %edx
je .L2
.L3:
addl $1, %ecx
cmpl %esi, %ecx
jle .L14
movl %ebx, %esi
movl $_ZSt4cout, %edi
call _ZNSolsEi
movl $1, %edx
movl $.LC3, %esi
movq %rax, %rdi
call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
.L2:
addl $1, %ebx
cmpl $100, %ebx
jne .L6
xorl %eax, %eax
popq %rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1561:
.size main, .-main
.p2align 4,,15
.type _GLOBAL__sub_I_main, @function
_GLOBAL__sub_I_main:
.LFB2045:
.cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
movl $_ZStL8__ioinit, %edi
call _ZNSt8ios_base4InitC1Ev
movl $__dso_handle, %edx
movl $_ZStL8__ioinit, %esi
movl $_ZNSt8ios_base4InitD1Ev, %edi
addq $8, %rsp
.cfi_def_cfa_offset 8
jmp __cxa_atexit
.cfi_endproc
.LFE2045:
.size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main
.section .init_array,"aw"
.align 8
.quad _GLOBAL__sub_I_main
.local _ZStL8__ioinit
.comm _ZStL8__ioinit,1,1
.hidden __dso_handle
.ident "GCC: (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0"
.section .note.GNU-stack,"",@progbits

这是一个基本程序,可以将所有变量存储到CPU寄存器中。因此,我猜它不使用RAM。我想知道检查汇编代码是否使用 RAM 的标准是什么?

最佳答案

在您链接的剪辑中,Jason Turner 只是说 C 局部变量都适合寄存器,因此编译器不必花费额外的指令 spilling/reloading them .

它使用 RAM 来存储代码和数据,只是不使用任何堆栈内存来存储局部变量。即局部变量的 RAM 为零,当然总共不是零字节。他甚至说游戏编译为 1005 字节(代码 + 数据)。

<小时/>

在读取 asm 时,您可以通过注意到堆栈中缺少加载/存储来检测到这一点,例如在 x86-64 上使用 RSP(或 RBP,如果用作帧指针)的寻址模式。

对于不太大的函数来说,这是完全正常的。否则,内联函数调用是实现这一目标的关键,因为在调用非内联函数时,编译器通常必须使内存“同步”(反射(reflect) C 抽象机的正确值)。

int foo(int num) {
int tmp = num * num;
return tmp;
}

在寄存器中获取num,并将tmp保存在那里。 Jason 的演讲使用的是 Godbolt,因此这里有一个链接 the same function on Godbolt ,由 gcc7.3 编译,经过优化和未经优化:

 foo:   # with optimization: all operands are registers
imul edi, edi
mov eax, edi
ret

foo: # without optimization:
push rbp
mov rbp, rsp # make a stack frame with RBP
mov DWORD PTR [rbp-20], edi # spill num to the stack
# start of code for first C statement
mov eax, DWORD PTR [rbp-20] # reload it
imul eax, DWORD PTR [rbp-20] # and use it from memory again
mov DWORD PTR [rbp-4], eax # spill tmp to the stack
# end of first C statement

mov eax, DWORD PTR [rbp-4] # load tmp into the return value register, eax)
pop rbp
ret

这不需要使用 sub rsp, 24保留任何堆栈空间,因为它使用 RSP 下面的红色区域来处理溢出/重新加载的局部变量。

显然,启用优化后,即使编译器在大型复杂函数中耗尽了寄存器并且必须溢出某些内容,您也不会得到如此糟糕的代码。 -O0 是一种反优化模式,其中每个 C 语句都会获得一个单独的 asm block ,因此您可以设置断点并修改变量,并使代码仍然有效。或者甚至跳转到 gdb 中的不同源代码行!

<小时/>

回复:x86 有多少个寄存器,如演讲中所述:

i386 有 8 个架构整数寄存器。它有一些段寄存器,您可以滥用它来保留额外的值,如果它有 FPU,则有 8 个 x87 80 位 FP 堆栈寄存器。 Jason 对 16 的猜测听起来很假,但他可能将 AL/AH、BL/BH 作为单独的 8 位寄存器进行计数,因为您可以独立使用它们。但不能与 EAX 同时使用,因为窄寄存器是完整寄存器的子集。

(并注意 partial-register penalties on various modern microarchitectures 。在 AMD 上,AL 和 AH 根本不独立;使用其中之一会错误地依赖于另一个,即整个 EAX/RAX。 在 Pentium P5MMX 及以上版本的 CPU 上,根本不存在部分寄存器惩罚,因为没有乱序执行或寄存器重命名。)

他声称现代 x86-64 有数百个寄存器也绝对是假的,除非你计算所有控制寄存器和特定于模型的寄存器。但堆栈内存比这些寄存器快得多,并且无论如何您都不能在其中放入任意值。由于只有 16 个架构整数寄存器(其中之一是堆栈指针,因此您实际上可以在一个大函数中使用 15 个寄存器),当您一次需要更多变量“实时”时,您仍然需要额外的指令来溢出或至少重新加载内容比那。

将寄存器重命名到大量物理寄存器上非常棒,并且 essential along with a large ReOrder Buffer for a large out-of-order execution window找到指令级并行性。但是您只能通过为不同的值重复使用相同的整数寄存器来利用这些寄存器。 (即 register renaming avoids write-after-read and write-after-write hazards ,使同一寄存器的两次使用实际上是独立的。)

Haswell 有一个用于整数/GP 寄存器的 168 项物理寄存器文件,还有一个用于重命名 FP/矢量寄存器的 168 项向量/FP 寄存器文件。 https://www.realworldtech.com/haswell-cpu/3/ 。但从架构上来说,在 x86-64 模式下运行时,它只有 16 GP/16 YMM,在 ia-32 模式下只有 8/8。

关于assembly - 如何知道汇编代码正在使用 RAM?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49807965/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com