什么做 - 或做了什么 - “volatile void function（...）”做？ [英] What does—or did—"volatile void function( ... )" do?

问题描述

我见过多少次使用不稳定关键字在C ++函数中，从语法角度来看，关于函数中volatile关键字的使用，但是关于该问题的Case 1没有明确的解释。只有一位受访者表示它似乎毫无意义/无用。然而，我不能完全接受这种说法，因为用于GNUC的AES软件实现已经被直接用于年，并且他们有许多这样的函数：

$ $ $ $ $ $ $ $ $ $ $ $ $ $ INLINE volatile void functionname（/ * ... * /）{
/ * ... * /
asm（/ * ... * /）//嵌入汇编语句
/ * ... * /
}

这种用法一定是有原因的。任何人都可以：

A 。告诉我原来的原因是什么;和

B 。如何实现预期的效果？

我使用的是Ubuntu和GCC 4.6.3。

注意：最接近的一个解释是，在GCC 2.5之前，你可以通过以下方式来欺骗在2.5中实现的'noreturn'属性：

  void fatal（/ * ... * /）{/ * ... * / exit（1）; } 
 
 typedef void voidfn（）; 
 
 volatile voidfn致命; 
  

这可以让编译器识别'致命'不会返回。

但是这种情况似乎并不适用于AES代码。我已经有很长时间没有组装任何东西了，但是我认为我会认识到一个跳跃或类似的东西。

解决方案

参考文献

• https://github.com/nmoinvaz/minizip/blob/master/aes/aes_via_ace.h 参见第323到333行和第399到492行。的其他地方找到这个代码，这只是我绊倒了第一个。




• http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_113.html a> Thanks @ouah！




• http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-old/binutils-2.18.50/gas /testsuite/gas/i386/padlock.d 打开搜索f3 0f a7，并将操作码标识为专门的加密操作。





证据







• volatile void function（...）不严格符合C99。 （感谢@Adam和@ouah。@Adam深入挖掘C99规范，@ouah指向我上面列出的灾难恢复列表。）




• 已添加GCC <版本2.5中的 __属性__（（noreturn））代替 volatile void ，但继续接受 volatile void 迟至4.6.3版本，以支持代码与2.5版之前的编译器兼容。 （GCC文档）。
  

• 上面引用的代码确实将控制权返回到了被调用的地方，因为这些指令看起来并不是在操纵地址寄存器（ s），也不执行跳转命令。相反，它们将各种值加载到32位寄存器中。 （代码检查）。
  

• 第323行至第333行的命令实现特殊操作码以支持加密操作。 （代码检查加上'挂锁'代码。）




• 使用汇编函数的代码显然期望它们返回。 （代码检查）

noreturn 属性告诉编译器函数不返回，所以编译器可以基于此进行优化。 （GCC文档。）


• 从GCC文档：不要以为在调用noreturn函数之前，调用函数保存的寄存器被恢复。







解决方案





这是一次与同事的讨论，最终为我提供线索in。当函数声明它不会返回时，编译器必须做一些不同的事情。审查GCC文件证实了这一点。



A。原因





您需要问自己以下问题。



问题： AES代码专门将值加载到32位寄存器中，并对其执行操作。 strong> GCC优化意味着调用函数的寄存器不会被保存，否则这些寄存器会在返回时覆盖这些值。汇编语言函数的计算结果保留在寄存器中供后续代码使用。



B。现在达到预期效果：





几乎不管它。你可能做的唯一的事情就是用 void 替换 volatile void 返回类型，并添加 noreturn 属性。理论上，这应该具有完全相同的效果。在实践中，它并没有坏掉，也没有修复它。





DESIRABILITY





广泛使用这个技术是绝对不鼓励的。首先，它取决于每个编译器的定制。其次，这取决于那些不改变他们如何处理不回报案件的编制者。第三，后续维护者可能会感到困惑。





唯一的情况是，如果您利用高度专用的机器代码来实现否则速度不可能提高。即使这样，它也应该与权衡取得平衡。



在这个例子中，支持两个编译器，并且只有当机器具有特定的硬件支持时优势。否则，它都是通过标准C代码处理的。这是很多努力。确保在你做之前它会得到回报。




I've seen How many usage does "volatile" keyword have in C++ function, from grammar perspective? about use of the volatile keyword on functions, but there was no clear explanation of what Case 1 from that question did. Only a statement by one of the respondents that it seemed pointless/useless.

Yet I cannot quite accept that statement, since the AES software implementations for GNUC have been used for literally years, and they have a number of functions like this:

INLINE volatile void functionname( /* ... */ ) {
    /* ... */
    asm( /* ... */ ) // embedded assembly statements
    /* ... */
}

There has to have been a reason for that usage. Can anyone:

A. tell me what the original reason was; and

B. how to achieve the desired effect now?

I'm using Ubuntu, and GCC 4.6.3.

---

Note: The closest I've come to an explanation is that prior to GCC 2.5, you could spoof the 'noreturn' attribute that was implemented in 2.5 via the following:

void fatal( /* ... */ ) { /* ... */ exit(1); }

typedef void voidfn ();

volatile voidfn fatal;

This would allow the compiler to recognize that 'fatal' was not going to return.

But that scenario doesn't appear to apply to the AES code. It's been a long time since I did anything in assembly, but I think I'd recognize a jump or something like that.

解决方案

REFERENCES

• https://github.com/nmoinvaz/minizip/blob/master/aes/aes_via_ace.h See lines 323 through 333, and lines 399 through 492. There are plenty of other places to find this code, this was just the first one I tripped over.

• http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_113.html Thanks @ouah!

• http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-old/binutils-2.18.50/gas/testsuite/gas/i386/padlock.d Turned up on a search for "f3 0f a7", and identifies the opcodes as specialized encryption operations.

• GCC's "info" documentation.

EVIDENCE

• volatile void function(...) is not strictly conforming to C99. (Thanks @Adam and @ouah. @Adam for digging into the C99 spec, and @ouah for pointing me at the DR listed above.)

• GCC added __attribute__((noreturn)) in version 2.5 as a replacement for volatile void, but has continued to accept volatile void as late as version 4.6.3 to support code compatibility with compilers prior to version 2.5. (GCC documentation.)

• The code referenced above does indeed return control to where it was called from, as the instructions do not appear to manipulate the address register(s), nor do they execute a jump command. Instead they load various values into the 32-bit registers. (Code examination.)

• The commands in lines 323 through 333 implement special opcodes in support of encryption operations. (Code examination plus the 'padlock' code.)

• The code using the assembly functions obviously expects them to return. (Code examination.)

• The noreturn attribute tells the compiler that the function does not return, so the compiler can make optimizations based on that. (GCC documentation.)

• From the GCC documentation: Do not assume that registers saved by the calling function are restored before calling the noreturn function.

SOLUTION

It was a discussion with a coworker that finally clued me in. The compiler must do something different when a function declares that it isn't going to return. Examination of the GCC documentation confirmed this.

A. The original reason

You need to ask yourself the following question.

Question: The AES code specifically loads values into the 32-bit registers, and performs operations on them. How does it get the answers back to the rest of the code?

Answer: The GCC optimizations mean that the calling function's registers, which otherwise would have overwritten the values upon return, are not saved. The results of the calculations in the assembly language functions remain in the registers for subsequent code to use.

B. Achieving the desired effect now:

Pretty much leave it alone. The only thing you might do is replace the volatile void return type with simply void, and add the noreturn attribute to the functions. Theoretically, that should have the exact same effect. In practice, it ain't broke, don't fix it.

DESIRABILITY

Extensive use of this technique is definitely discouraged. First, it depends on customization for each compiler. Second, it depends on those compilers not changing how they handle the 'no return' case. Third, it's potentially confusing to subsequent maintainers.

The only situation where something like this makes any sense is when you're taking advantage of highly specialized machine code, to achieve an otherwise impossible improvement in speed. Even then, it should be balanced against the trade-offs.

In this example, precisely two compilers are supported, and only if the machines have the specific hardware support to take advantage of. Otherwise, it's all handled through standard C code. That's a lot of effort. Make sure it's going to pay off before you do it.

这篇关于什么做 - 或做了什么 - “volatile void function（...）”做？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！