SSE3/SSSE3 + AES/RDRAND/RDSEED 在 Sun Studio 下
SSE3/SSSE3 + AES/RDRAND/RDSEED under Sun Studio
我在 SunOS 5.11 (Solaris 11.3) 上的 Sun Studio 12.3 下工作。我正在调整一个包含负面测试的脚本,其中包含 CPU 功能的奇怪组合。我们这样做是为了了解我们是否以及如何失败;并确保有 no unexpected surprises.
我正在尝试找到一种方法来启用本机指令集以及 AES、RDRAND 和 RDSEED。本机指令集由 Xeon 5100 提供,实际上是 SSE3/SSSE3 加上一些附加指令。
用 /opt/solarisstudio12.3/bin/CC -DNDEBUG -g3 -xO2 -template=no%extdef -native -m64 -KPIC -xarch=aes -D__AES__=1
编译所有源文件导致:
$ ./cryptest.exe
ld.so.1: cryptest.exe: fatal: cryptest.exe: hardware capability (CA_SUNW_HW_1) unsupported: 0x1000000 [ SSE4.2 ]
Killed
这是意料之中的,因为 Sun Studio 假定功能和可用性会不断发展。当我修改 makefile 以使用 -xarch=aes
构建 cpu.cpp
(用于功能测试)、rijndael.cpp
(提供 AES 实现)和 test.cpp
(执行测试)时,程序仍然崩溃,因为 SSE4 正在进入 test.cpp
.
我尝试使用 -xarch=aes -D__AES__=1 -xarch=no%sse4_1 -xarch=no%sse4_2
删除不需要的指令集,但未能按预期编译。 no%sse4_1
只是来自 -template=no%extdef
,因为 no%
前缀似乎是关闭事物的方式。
如何在 Sun Studio 下使用 SSE3/SSSE3 添加 AES/RDRAND/RDSEED?有可能吗?
我们使用的模式(到目前为止运行良好)是将编译时支持与运行时支持相结合。所以 AES 代码看起来像:
#if (__AES__ >= 1) || (SUNPRO_CC >= 0x512)
# define HAVE_AES 1
#endif
#if defined(HAVE_AES)
if (HasAES())
{
// Optimized implementation
...
return;
}
#endif
{
// Fall into C/C++ implementation
...
}
对于像 Clang 和 GCC 这样的编译器,我们只是 -march=native -maes -mrdrnd -mrdseed
。我很高兴接受没有发生异花授粉。
然后我在 Oracle 的留言板上看到两条消息,指示 RDRAND 在 Sun Studio 12.3 和 12.4 (here for 12.3 and here for 12.4) 下损坏。所以我必须确保启用 RDRAND 以确保其被测试,这需要 -xarch=aes
.
基于,这可能是不可能的。这个问题实际上是尽职调查,以确保我们尽一切努力确保无故障体验。
$ isainfo -v
64-bit amd64 applications
ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
在那里,我已经为你创建了一个 AES+SSSE3 二进制文件。
$ cat tmp.c
#include
#include
#include
int main(int argc, char* argv[])
{
// SSE2
int64_t x[2];
__m128i y = _mm_loadu_si128((__m128i*)x);
// AES
__m128i z = _mm_aeskeygenassist_si128(y,0);
return 0;
}
$ cat tmp2.c
#include
#include
void foo(void)
{
__m128i x;
x = _mm_hadd_epi16 (x, x);
}
$ cc tmp.c tmp2.c -xarch=aes
tmp.c:
tmp2.c:
$ file a.out
a.out: ELF 32-bit LSB executable 80386 Version 1 [AES SSSE3 SSE2 SSE], dynamically linked, not stripped
硬件功能位由编译器指定
取决于最终可执行文件中指令的实际存在。
所以 tmp.o 分配了 AES 位。并且 tmp2.o 最多有 SSSE3 位被分配。
当链接在一起时,它们会生成 [AES SSSE3] 二进制文件。因为 HWCAP 位 OR 在一起。
我在 SunOS 5.11 (Solaris 11.3) 上的 Sun Studio 12.3 下工作。我正在调整一个包含负面测试的脚本,其中包含 CPU 功能的奇怪组合。我们这样做是为了了解我们是否以及如何失败;并确保有 no unexpected surprises.
我正在尝试找到一种方法来启用本机指令集以及 AES、RDRAND 和 RDSEED。本机指令集由 Xeon 5100 提供,实际上是 SSE3/SSSE3 加上一些附加指令。
用 /opt/solarisstudio12.3/bin/CC -DNDEBUG -g3 -xO2 -template=no%extdef -native -m64 -KPIC -xarch=aes -D__AES__=1
编译所有源文件导致:
$ ./cryptest.exe
ld.so.1: cryptest.exe: fatal: cryptest.exe: hardware capability (CA_SUNW_HW_1) unsupported: 0x1000000 [ SSE4.2 ]
Killed
这是意料之中的,因为 Sun Studio 假定功能和可用性会不断发展。当我修改 makefile 以使用 -xarch=aes
构建 cpu.cpp
(用于功能测试)、rijndael.cpp
(提供 AES 实现)和 test.cpp
(执行测试)时,程序仍然崩溃,因为 SSE4 正在进入 test.cpp
.
我尝试使用 -xarch=aes -D__AES__=1 -xarch=no%sse4_1 -xarch=no%sse4_2
删除不需要的指令集,但未能按预期编译。 no%sse4_1
只是来自 -template=no%extdef
,因为 no%
前缀似乎是关闭事物的方式。
如何在 Sun Studio 下使用 SSE3/SSSE3 添加 AES/RDRAND/RDSEED?有可能吗?
我们使用的模式(到目前为止运行良好)是将编译时支持与运行时支持相结合。所以 AES 代码看起来像:
#if (__AES__ >= 1) || (SUNPRO_CC >= 0x512)
# define HAVE_AES 1
#endif
#if defined(HAVE_AES)
if (HasAES())
{
// Optimized implementation
...
return;
}
#endif
{
// Fall into C/C++ implementation
...
}
对于像 Clang 和 GCC 这样的编译器,我们只是 -march=native -maes -mrdrnd -mrdseed
。我很高兴接受没有发生异花授粉。
然后我在 Oracle 的留言板上看到两条消息,指示 RDRAND 在 Sun Studio 12.3 和 12.4 (here for 12.3 and here for 12.4) 下损坏。所以我必须确保启用 RDRAND 以确保其被测试,这需要 -xarch=aes
.
基于
$ isainfo -v
64-bit amd64 applications
ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
在那里,我已经为你创建了一个 AES+SSSE3 二进制文件。
$ cat tmp.c #include #include #include int main(int argc, char* argv[]) { // SSE2 int64_t x[2]; __m128i y = _mm_loadu_si128((__m128i*)x); // AES __m128i z = _mm_aeskeygenassist_si128(y,0); return 0; } $ cat tmp2.c #include #include void foo(void) { __m128i x; x = _mm_hadd_epi16 (x, x); } $ cc tmp.c tmp2.c -xarch=aes tmp.c: tmp2.c: $ file a.out a.out: ELF 32-bit LSB executable 80386 Version 1 [AES SSSE3 SSE2 SSE], dynamically linked, not stripped
硬件功能位由编译器指定 取决于最终可执行文件中指令的实际存在。
所以 tmp.o 分配了 AES 位。并且 tmp2.o 最多有 SSSE3 位被分配。
当链接在一起时,它们会生成 [AES SSSE3] 二进制文件。因为 HWCAP 位 OR 在一起。