Mar*_*ler 5 crc32 portability arm64
aarch64 上的用户程序是否可以检测 crc32 指令是否可用?我发现了对此类检测的内核支持的引用,这意味着包含有关哪些指令将在用户模式下工作的信息的寄存器在用户模式下不可用(!)。
是这样吗?或者是否有一种可移植的方法来确定 crc32 指令是否可用?
注意:我所说的“用户程序”和“可移植”是一种不需要特权指令或特定于操作系统的调用或文件(例如/proc/cpuinfo)的方法。代码本身需要能够检测指令是否可用,如果可用则使用它们,如果不可用则退回到替代方案。例如,英特尔处理器具有cpuid用于此目的的指令。
更新:
在查阅 ARM 架构描述时,我发现了一个用户级寄存器 ,PMCR_EL0它为处理器提供了 8 位实现者代码和 8 位 ID 代码。也许如果我能找到这些代码的列表,我可能会更接近我正在寻找的东西。
更新2:
但是,当我尝试读取该寄存器时,出现非法指令异常。那么即使 EL0 寄存器也需要特权访问吗?
据我所知并非如此。
我在 Chromium 的 zlib 中实现它的方式是使用可用的操作系统功能: https://cs.chromium.org/chromium/src/third_party/zlib/arm_features.c ?l=29
还值得一提的是,ARMv8 上的 crc32 指令是加密扩展的一部分,在 ARMv8 上是可选的,在 ARMv8-1 上是强制的。这也意味着运行时特征检测是必要的,更多详细信息请查看: https: //cs.chromium.org/chromium/src/third_party/zlib/BUILD.gn ?l=64
我会避免直接从 /proc/cpuinfo 读取,因为这在某些情况下可能不可用(也取决于 Android 风格,它可能是漏报)。
在 Chromium 中,zlib 将在特权上下文(即主浏览器进程中的网络代码的一部分)和沙盒上下文(即选项卡中的 RendererProcess 的一部分)中运行。在 RendererProcess 中,从 /proc/cpuinfo 读取应该会失败。
大锤方法是安装信号处理程序并使用内联汇编执行指令,如果指令不可用(并且可以被处理程序捕获),这将导致错误。不过不推荐。
上述示例(https://github.com/torvalds/linux/blob/master/Documentation/arm64/cpu-feature-registers.txt)在我测试过的 1 个 ARM 板(MachiatoBin)中工作,但在另外 2 个中失败( rock64 和 nanopi m4)。
Chromium 中实现的方法适用于所有主板(以及我测试过的一些手机)。
关于 getauxval 的另一个细节:如果在 32 位或 64 位上运行,正确的标志将会改变。因此,在 64 位中,它将是 HWCAP_CRC32,而在 32 位中,它将是 HWCAP2_CRC32。
关于大锤方法:信号很容易出现竞争条件,而且您仍然依赖于操作系统特定 API 的使用(即安装信号处理程序)。
最后,根据上下文,如果给定任务崩溃(即使是设计上的并且与执行上下文隔离),它将触发危险信号。
这一点(即特征检测)在 x86 上更容易实现。
话虽这么说,依赖操作系统功能可能是一个可以接受的折衷方案。自 M66 版本(当前稳定版本是 M72)以来,我们一直在 Chromium 中发布链接代码,大约一年前首次发布,没有任何不良报告。
Android 上的一个考虑因素是,NDK 内部可能会使用 dlopen()/dlsym() 实现 android_getCpuFeatures(),这会在第一次启动时增加大约 500us 到 1000us,这就是我们缓存 CPU 功能检测结果的原因。
多线程应用程序(如 Chromium)的另一个考虑因素是需要线程屏障(即 pthread_once_t)以避免执行 CPU 功能检测时的竞争条件。
| 归档时间: |
|
| 查看次数: |
2167 次 |
| 最近记录: |