深入装配

Question

c中的函数：

PHPAPI char *php_pcre_replace(char *regex,   int regex_len,
                              char *subject, int subject_len,
                              zval *replace_val, int is_callable_replace,
                              int *result_len, int limit, int *replace_count TSRMLS_DC)
{
    pcre_cache_entry    *pce;               /* Compiled regular expression */

    /* Compile regex or get it from cache. */
    if ((pce = pcre_get_compiled_regex_cache(regex, regex_len TSRMLS_CC)) == NULL) {
        return NULL;
    }

    ....
}

其汇编：

php5ts!php_pcre_replace:
1015db70 8b442408        mov     eax,dword ptr [esp+8]
1015db74 8b4c2404        mov     ecx,dword ptr [esp+4]
1015db78 56              push    esi
1015db79 8b74242c        mov     esi,dword ptr [esp+2Ch]
1015db7d 56              push    esi
1015db7e 50              push    eax
1015db7f 51              push    ecx
1015db80 e8cbeaffff      call    php5ts!pcre_get_compiled_regex_cache (1015c650)
1015db85 83c40c          add     esp,0Ch
1015db88 85c0            test    eax,eax
1015db8a 7502            jne     php5ts!php_pcre_replace+0x1e (1015db8e)

php5ts!php_pcre_replace+0x1c:
1015db8c 5e              pop     esi
1015db8d c3              ret

c函数调用pcre_get_compiled_regex_cache(regex, regex_len TSRMLS_CC)对应于1015db7d~1015db80，它将3个参数推送到堆栈并调用它。

但我的疑问是，在这么多寄存器中，编译器如何决定使用eax，ecx和esi（这个很特殊，因为它是使用前恢复，为什么？）作为中间进栈？

c 中一定有一些隐藏的指示告诉编译器这样做，对吧？

Answer 1

不，没有隐藏的指示。

这是生成 80x86 指令的典型策略，许多编译器实现（C 等）都使用该策略。例如，20 世纪 80 年代的 Intel Fortran-77 编译器在打开优化时会执行相同的操作。

也就是说，优先使用 eax 和 ecx 可能是避免使用 esi 和 edi 的产物，因为这些寄存器不能直接用于加载字节操作数。

为什么不是 ebx 和 edx？嗯，许多代码生成器首选这些来在评估复杂结构评估时保存中间指针，也就是说，根本没有太多理由。编译器只是查找两个可用的寄存器来使用并覆盖它们以缓冲值。

为什么不像这样重用eax？：

   push    esi
   mov     eax,dword ptr [esp+2Ch]
   push    eax
   mov     eax,dword ptr [esp+8]
   push    eax
   mov     eax,dword ptr [esp+4]
   push    eax

因为这会导致管道停顿，等待eax完成之前的内存周期，自80586以来的80x86秒（可能是80486 - 时间太久远了）一定要离开我的头顶）。

x86 架构是一头奇怪的野兽。每个寄存器虽然被英特尔宣传为“通用”，但都有其怪癖（例如，cx/ecx 与 loop 指令相关联，并且 eax:edx 与乘法指令相关）。再加上优化执行以避免缓存未命中和管道停顿的特殊方法，通常会导致代码生成器生成难以理解的代码，而代码生成器将所有这些因素都考虑在内。