c++ - VC++和ASM中的优化代码

Question

晚上好。抱歉，我使用了google tradutor。
我在x86上的VC++中使用NASM，并且正在学习如何在x64上使用MASM。

是否有任何方法可以指定每个参数的位置以及汇编函数的返回方式，以使编译器设法以最快的方式将数据保留在那里？我们也可以指定将使用哪些寄存器，以便编译器知道仍保存哪些数据以最佳利用它？

例如，由于没有内在函数完全适用IDIV r / m64(汇编语言的64位带符号整数除法)，因此我们可能需要实现它。 IDIV要求在任何寄存器或存储器区域中，红利/分子的低幅度部分在RAX中，在RDX中高，并且除数/分母在其中。最后，商以EAX表示，余数以EDX表示。因此，我们可能想开发功能，以便(我以实用程序为例):

void DivLongLongInt( long long NumLow , long long NumHigh , long long Den , long long *Quo , long long *Rem ){
    __asm(
        // Specify used register: [rax], specify pre location: NumLow --> [rax]
        reg(rax)=NumLow ,
        // Specify used register: [rdx], specify  pre location: NumHigh --> [rdx]
        reg(rdx)=NumHigh ,
        // Specify required memory: memory64bits [den], specify pre location: Den --> [den]
        mem[64](den)=Den ,
        // Specify used register: [st0], specify pre location: Const(12.5) --> [st0]
        reg(st0)=25*0.5 ,
        // Specify used register: [bh]
        reg(bh) ,
        // Specify required memory: memory64bits [nothing]
        mem[64](nothing) ,
        // Specify used register: [st1]
        reg(st1)
    ){
        // Specify code
        IDIV [den]
    }(
        // Specify pos location: [rax] --> *Quo
        *Quo=reg(rax) ,
        // Specify pos location: [rdx] --> *Rem
        *Rem=reg(rdx)
    ) ;
}

是否有可能至少做些与之接近的事情？
感谢您的所有帮助。

如果没有办法做到这一点，那就太可惜了，因为这肯定是实现具有汇编级功能的高级功能的好方法。我认为这是C++与ASM之间的简单接口(interface)，应该已经存在，并且可以将汇编代码嵌入到嵌入式系统中并以较高的级别嵌入，实际上就像简单的C++代码一样。

Answer 1

As others have mentioned，针对x86-64时，MSVC不支持任何形式的内联汇编。

内联汇编仅在x86-32构建中受支持，即使在那里，它的功能也相当有限。特别是，您不能指定输入和输出，因此内联汇编的使用必然会在寄存器和内存之间来回交换大量值，这与编写高性能代码时恰恰相反。除非有导致无法手动发出机器代码的方法，否则您不能采取任何其他方法，否则应避免使用内联汇编器。它的最初目的是在过时的8位和16位编程环境中执行诸如生成OUT指令和调用ROM BIOS中断之类的操作。出于兼容性目的，它被放入了32位编译器中，但是该团队采用了64位。

内在函数现在是推荐的解决方案，因为它们在优化器中的作用要好得多。实际上，您需要编译器生成的任何SIMD代码都可以使用内在函数来完成，就像大多数其他针对x86的其他编译器一样，因此不仅获得了更好的代码，而且获得了更多可移植的代码。

即使在支持extended asm blocks的Gnu风格编译器上，它也会为您提供所需的输入/输出操作数幂类型，仍然有lots of good reasons to avoid the use of inline asm。内部函数仍然是一种更好的解决方案，因为找到了一种方法来表示您要用C表示的内容，并说服编译器生成希望其发出的汇编代码。

唯一的异常(exception)是没有内部函数可用的情况。不幸的是，IDIV指令是其中一种情况。 (有一些可用于128位乘法的内在函数。它们具有不同的名称:Windows-specific或compiler-specific。)

在支持128位整数类型作为64位目标扩展的Gnu编译器上，您可以让编译器为您生成代码:

__int128_t dividend = 1234;
int64_t    divisor  = 64;
int64_t    quotient = (dividend / divisor);

现在，通常将其编译为对其执行128位除法的库函数的调用，而不是将其返回64位商的内联 IDIV指令。大概是因为需要处理溢出 as David mentioned。实际上，这比那更糟。没有C或C++实现可以使用 DIV / IDIV指令，因为它们不符合要求。这些指令将导致溢出异常，而标准指出结果应被截断。 (通过乘法，您确实获得了内联 IMUL / MUL指令，因为它们没有溢出问题，因为它们返回128位结果。)

这实际上并没有您想像的那么大。您似乎以为64位 IDIV指令确实非常快。不是。尽管实际数字取决于被除数绝对值中有效位数的数量，但是如果您实际上需要128位整数的范围，则您的值可能会很大。查看 Agner Fog's instruction tables将使您对可以在各种体系结构上期望的性能有所了解。在更新的体系结构上(尤其是在更新的AMD处理器上；它在Intel上仍然很缓慢)，它的运行速度越来越快，但是它仍然具有相当大的延迟。仅仅因为它是一条指令并不意味着它在一个周期内运行或类似的运行。当您针对大小进行优化并且担心调用库函数以从缓存中逐出其他指令时，单个指令可能会有利于代码密度，但是除法运算的速度足够慢，因此通常无关紧要。实际上，除法是如此之慢，以至于编译器会竭尽全力不使用它，只要有可能，它们就会通过倒数相乘，这将大大加快速度。而且，如果您真的需要快速进行乘法运算，则应考虑使用SIMD指令将它们并行化，而SIMD指令都具有可用的内在函数。

回到MSVC(尽管我在上一段中所说的所有内容仍然适用)，但没有128位整数类型，因此，如果需要实现这种除法，则需要在外部程序集中编写代码模块并链接到其中。代码非常简单，并且Visual Studio具有出色的内置支持，可将代码与MASM组装在一起并将其直接链接到您的项目中:

; Windows 64-bit calling convention passes parameters as follows:
; RCX == first  64-bit integer parameter (low bits of dividend)
; RDX == second 64-bit integer parameter (high bits of dividend)
; R8  == third  64-bit integer parameter (divisor)
; R9  == fourth 64-bit integer parameter (pointer to remainder)
Div128x64 PROC
    mov  rax, rcx
    idiv r8          ; 128-bit divide (RDX:RAX / R8)
    mov  [r9], rdx   ; store remainder
    ret              ; return, with quotient in RDX:RAX
Div128x64 ENDP

然后，您只需在C++代码中将其原型(prototype)化为:

extern int64_t Div128x64(int64_t  loDividend,
                         int64_t  hiDividend,
                         int64_t  divisor,
                         int64_t* pRemainder);

到此为止。根据需要调用它。

可以使用 DIV指令为无符号除法编写等效项。

不，您不会获得智能的寄存器分配，但这与前端中的寄存器重命名(通常可以完全消除寄存器-寄存器移动)(换句话说， MOV成为零延迟操作)的关系并不大。此外， IDIV指令无论如何对其操作数都具有严格的限制，因为它们被硬编码为 RAX和 RDX，因此调度程序几乎不可能将这些值保留在那些寄存器中，至少对于任何不重要的部分代码。

请注意，一旦编写了必要的代码以检查是否存在溢出或更糟的代码(用于处理异常的代码)，最终很可能会与执行正确的128位除法的库函数执行相同或更坏的结果，因此可以说，您应该只是编写并使用它(直到Microsoft认为合适的时间提供为止)。可以是 written in C(另请参见Gnu编译器的 __divti3库函数的实现)，这使其成为内联的候选对象，否则可以与优化程序一起使用。