What does—or did—“volatile void function( … )” do?

Question

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 clea

Answer 1

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.