现代C++中不推荐使用__asm__嵌入汇编，因其非标准、不可移植，GCC是唯一较稳定支持者，MSVC在x64已彻底移除；必须用volatile和约束符，裸指令易致崩溃，执行机器码应通过mmap/VirtualAlloc实现。
现代 C++ 项目里直接用 __asm__ 嵌入汇编指令，绝大多数情况不推荐——它不是标准 C++，不可移植，且在主流编译器上支持严重受限。GCC 是目前唯一还能较稳定支持 GNU 风格扩展内联汇编的编译器；Clang 对部分语法兼容但不保证；MSVC 在 x64 下已彻底移除支持，x86 下也仅限 MASM 语法且无变量约束机制。
gcc/clang 下必须用 volatile + 约束符，不能裸写指令
像 __asm__("movl $1, %eax") 这种写法看似能过编译，但实际危险：编译器不知道你改了 %eax，也不知道是否读写了内存，一开 -O2 就可能把上下文寄存器重用掉，导致值错乱或崩溃。
-
volatile必须加，否则整个块可能被优化删除（哪怕只读一个寄存器） - 所有涉及 C 变量的读写，必须用约束符（如
"=r"(out)、"r"(in)），不能硬编码寄存器名（如"movl %0, %eax"） - 修改了但未声明为输出的寄存器，必须列在 clobber list 里（如
"rax"、"cc"、"memory"） - 多条指令要用
\n\t换行分隔："incl %0\n\taddl $2, %0"
MSVC 的 __asm 块根本不支持约束语法，无法安全交互变量
VS 2019+ 在 x86 模式下仍允许 __asm { mov eax, a } 这类写法，但它没有输入/输出约束概念，a 必须是全局或静态变量，且编译器不检查你是否破坏了调用约定。典型问题包括：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 局部变量地址需用
lea eax, a或mov eax, offset a，不能直接mov eax, a（后者读的是值，不是地址） - 无法表达“把寄存器结果写回变量”，只能靠手动
mov a, eax，极易因寄存器分配冲突出错 - push/pop 会破坏栈帧，尤其开启 /GS 保护后直接触发
STATUS_STACK_BUFFER_OVERRUN - x64 下连
__asm关键字都报错C4409：“asm is not supported on this architecture”
想执行 raw bytes？别碰 asm，用 mmap + mprotect
真正“嵌入机器码字节”的需求（比如 JIT、shellcode 测试），和 __asm__ 完全无关。GNU 内联汇编生成的是编译期确定的指令序列，不是运行时写入的字节流。
立即学习“C++免费学习笔记（深入）”；
- 要执行动态生成的指令，得用
mmap()（Linux/macOS）或VirtualAlloc()（Windows）分配PROT_EXEC/PAGE_EXECUTE_READWRITE内存 - 写入 raw bytes 后，需用
mprotect()或VirtualProtect()切换权限（现代系统默认禁用 W^X） - 函数指针强转执行前，确保指令对齐、栈空间足够、调用约定匹配（比如 x86-64 System V 要 16 字节栈对齐）
- 这种操作会被杀软拦截，且在 ASLR + SMEP/SMAP 环境下极易失败
最常被忽略的一点：即使你在 GCC 下写对了 __asm__ volatile，只要换到 Clang 或迁移到 ARM64，整段代码就得重写——寄存器名、clobber 列表、约束符含义全都不一样。真要控制底层行为，优先查 <immintrin.h></immintrin.h> 里的 intrinsic，或用 std::atomic + 编译器 barrier 替代。
