如何在C语言中实现可移植的GameBoy 16位寄存器模拟结构？

首先明确核心问题：GameBoy的LR35902 CPU是小端序架构，16位寄存器的高字节（如AF中的A、BC中的B）对应16位值的高8位，低字节（如AF中的F、BC中的C）对应低8位，即16位值为 高字节 << 8 | 低字节。你当前的union实现依赖宿主机器的字节序，在大端机器上会导致高低字节对应错误，同时union类型双关在C标准中属于未定义行为（主流编译器虽支持，但严格来说不符合标准）。

最优解决方案：用结构体+封装函数（标准合规，完全可移植） #

放弃依赖union的类型双关，改用结构体存储高低字节，通过静态内联函数封装16位值的读写逻辑，完全规避字节序差异和标准合规性问题，这也是模拟器开发中的良好实践：

#include <stdint.h>

// 存储16位寄存器的高低字节，明确对应GameBoy的定义
typedef struct register16_t {
    uint8_t lo;  // GameBoy寄存器的低字节（如F、C、E、D）
    uint8_t hi;  // GameBoy寄存器的高字节（如A、B、H、L）
} register16_t;

// 获取16位寄存器值，严格按照GameBoy的字节序计算
static inline uint16_t reg16_get(const register16_t* reg) {
    return (uint16_t)reg->hi << 8 | reg->lo;
}

// 设置16位寄存器值，拆分高低字节到对应成员
static inline void reg16_set(register16_t* reg, uint16_t val) {
    reg->lo = val & 0xFF;
    reg->hi = (val >> 8) & 0xFF;
}

使用示例：

register16_t af_reg;
reg16_set(&af_reg, 0x1234);  // af_reg.hi = 0x12, af_reg.lo = 0x34
uint16_t af_val = reg16_get(&af_reg);  // af_val = 0x1234

这种方式的优势：

• 完全不依赖宿主机器的字节序，在大端/小端机器上行为一致
• 严格符合C标准，无未定义行为风险
• 代码可读性强，明确对应GameBoy的寄存器定义

备选方案：带字节序检测的union（依赖编译器扩展） #

如果希望保留直接访问16位值的便利性，可以通过编译时字节序检测调整结构体成员顺序，同时依赖编译器对union类型双关的支持：

#include <stdint.h>

#if defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __LITTLE_ENDIAN__)
// 小端机器：结构体成员顺序lo在前，对应16位值的低字节
typedef union register16_t {
    struct {
        uint8_t lo;
        uint8_t hi;
    };
    uint16_t reg16;
} register16_t;
#elif defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)
// 大端机器：结构体成员顺序hi在前，对应16位值的高字节
typedef union register16_t {
    struct {
        uint8_t hi;
        uint8_t lo;
    };
    uint16_t reg16;
} register16_t;
#else
// 无法检测字节序时， fallback到标准合规的结构体+函数
typedef struct register16_t {
    uint8_t lo;
    uint8_t hi;
} register16_t;

static inline uint16_t reg16_get(const register16_t* reg) {
    return (uint16_t)reg->hi << 8 | reg->lo;
}

static inline void reg16_set(register16_t* reg, uint16_t val) {
    reg->lo = val & 0xFF;
    reg->hi = (val >> 8) & 0xFF;
}
#endif

注意事项：

• 不同编译器的字节序宏可能不同（如MSVC使用_BIG_ENDIAN和_LITTLE_ENDIAN），需要额外适配
• union类型双关属于编译器扩展，严格来说违反C标准，存在潜在的未定义行为风险
• 代码可读性和维护性不如方案一

关于union类型双关的标准合规性 #

C标准（C11 §6.5.2.3）明确规定：访问union的一个成员后，再访问另一个非unsigned char类型的成员，属于未定义行为。主流编译器（GCC、Clang、MSVC）均将union类型双关作为扩展支持，但这并非标准行为，因此在追求严格可移植性的场景下，方案一是更稳妥的选择。

内容的提问来源于stack exchange，提问作者Sambhunath Meher