量化模型在ARM设备上退出，或某种输入明显变慢，应该分别问三个问题：C代码是否有定义良好的行为？具体指令与内存属性是否允许访问？数值优化是否改变结果？把它们混成“ARM不宽容”，很容易得到错误修复。
地址对齐不是一句“NEON必须16字节”
Armv8-A文档区分Normal与Device内存，对齐检查还依赖指令与控制条件。不能断言所有AArch64 NEON加载都要求16字节对齐、否则必然SIGBUS；也不能因一次Normal内存加载成功，就认为设备寄存器与原子操作都允许同样访问。Arm官方指南，历史背景
C层有自己的规则。从任意字节地址强转uint32_t *再解引用，可能违反对齐或有效类型约束。硬件碰巧执行，不等于程序可移植。普通内存的序列化字段可先memcpy到正确类型对象，再按协议处理字节序；设备I/O则按驱动接口访问。
只运行安全路径
safe_value.c只做普通字节拷贝、解码和浮点分类，没有故意触发未定义行为，不改FPCR。
#include <assert.h>
#include <float.h>
#include <math.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
int main(void) {
unsigned char packet[5] = {0xff, 1, 2, 3, 4};
uint32_t native;
memcpy(&native, packet + 1, sizeof native);
uint32_t le = (uint32_t)packet[1] | (uint32_t)packet[2] << 8 |
(uint32_t)packet[3] << 16 | (uint32_t)packet[4] << 24;
assert(le == UINT32_C(0x04030201));
volatile float base = FLT_MIN;
float half = base * 0.5f;
printf("native=%08x little_endian=%08x\\n", (unsigned)native, (unsigned)le);
printf("FLT_MIN=%a half=%a class=%s\\n", (double)base, (double)half,
fpclassify(half) == FP_SUBNORMAL ? "subnormal" :
half == 0.0f ? "zero" : "other");
return 0;
}
实际使用clang -std=c11 -Wall -Wextra -Werror -O2 safe_value.c -o safe_value编译，再执行./safe_value。在macOS arm64、Apple Clang 21.0.0得到native=04030201和little_endian=04030201。这台机器的字节序与示例协议一致，显式小端解码不依赖这项巧合。
浮点输出FLT_MIN=0x1p-126、half=0x1p-127，分类为subnormal。它只说明当前环境保留了该值，不代表Cortex-A55时延，也不证明所有运算都使用相同模式。
非规格化数先是语义问题
“低功耗ARM遇到subnormal必然陷入内核软件模拟”不是通用结论。判断具体设备需要CPU手册、浮点模式、生成汇编与实际测量。flush-to-zero可能把很小的值处理成零，从而改变数值结果，不能作为无条件开启的安全开关。
GCC文档列出-ffast-math包含的多项语义放宽；它不等于每个目标都会采用某一种FTZ流水线。只追加-fno-finite-math-only也没有撤销其他放宽。GCC优化选项
应冻结严格浮点基线，准备正常值、正负零、极小值、NaN/Inf和任务边界输入，先比较误差及任务判定，再在相同条件下测时。若库或线程更改浮点环境，还要检查作用范围和恢复方式。没有这层证据，不应全局裁掉1e-6以下的值：阈值与单位、量化尺度、任务分布有关。
问题单要足够小，也要足够完整
记录CPU型号、内核与运行时commit、模型哈希、编译器和选项、最小输入、信号及回溯、相关指令和分配方法。性能问题另附预热、温度、频率与重复样本，不能用单次时间定位根因。
这里完成了用户态安全取值与分类验证，没有Linux板卡测量，没有NEON吞吐测试，没有修改系统寄存器。更换目标、编译选项或数值模式都应重新验收，不能沿用开发机结论。
