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
The C99 standard says this in §6.7.3/3:
The properties associated with qualified types are meaningful only for expressions that are lvalues.114)
114) The implementation may place a
const
object that is notvolatile
in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its address is never used
§6.2.5/19 says:
The
void
type comprises an empty set of values; it is an incomplete type that cannot be completed.
And §6.3.2.1/1 says:
An lvalue is an expression with an object type or an incomplete type other than
void
;53) [...]
Hence, void
is not an lvalue, so the type qualifiers (const
, volatile
, and restrict
) are not meaningful for expressions of type void
. So, in any C99-compliant compiler, const void
and volatile void
are meaningless (although pointers to const void
and const volatile
are meaningful).
Furthermore, the constraints of §6.9.1/3 disallow a function to return a qualified type of void
:
The return type of a function shall be
void
or an object type other than array type.
Since this is a constraint, a conforming compiler must issue a diagnostic (§5.1.1.3/1). So a function returning volatile void
is not allowed in C99.
As for what volatile void
may have used to do, I have no idea and can't really speculate. The AES code you're looking at probably just has old cruft that never got cleaned up, I'd guess.
According to the gcc documentation (until February 2015), volatile void
as a function return value in C (but not in C++) is equivalent to __attribute__((noreturn))
on the function and tells the compiler that the function never returns.
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.
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.
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.
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.
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.
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.