1. 项目概述：一个为嵌入式世界而生的C编译器

如果你在嵌入式领域摸爬滚打过几年，尤其是玩过那些资源极其受限的微控制器，比如经典的8位AVR，或者一些老旧的ARM Cortex-M0，那你一定对“内存”和“代码尺寸”这两个词有着刻骨铭心的敬畏。项目预算就给了你2KB的RAM和16KB的Flash，你写的每一行代码、声明的每一个变量，都得精打细算。这时候，你打开GCC或者Clang，编译一个简单的“Hello World”（当然，在嵌入式里可能是“Blink LED”），看着生成的几十KB的二进制文件，心里是不是会咯噔一下？你开始疯狂地调整优化等级，裁剪标准库，甚至手写汇编，只为把那宝贵的几字节给省下来。

这就是 joelmartinez/chimpiler 诞生的背景。它不是一个试图与GCC、Clang在通用领域一较高下的庞然大物，而是一个精准的“手术刀”。它的目标非常明确： 为资源极度受限的嵌入式系统，从头实现一个极简、可理解、可掌控的C编译器 。 chimpiler 这个名字本身就很有趣，“Chimp”是黑猩猩，加上“compiler”，你可以理解为这是一个“猿级”或“基础级”的编译器，它不追求智能，而是追求原始、直接和可控。这个项目对于嵌入式开发者、计算机科学学生，以及任何想揭开编译器神秘面纱的人来说，都是一个绝佳的实践宝库。它不是让你去编译Linux内核，而是让你能亲手打造一个工具，去点亮一块开发板上的第一颗LED，并且清楚地知道从源代码到机器指令的每一个比特是如何转化的。

2. 核心设计哲学与架构拆解

2.1 为什么从头写？理解“透明”的价值

在嵌入式开发中，“黑盒”是最大的敌人。当你使用GCC的 -Os （优化尺寸）选项时，你知道它帮你省了空间，但你知道它具体做了什么吗？它是否在某些极端情况下引入了你不期望的行为？当链接器报出一个诡异的“section .text‘ will not fit in region FLASH’”错误时，你能在多深的层次上定位问题？

chimpiler 的设计哲学就是 “透明化” 和 “教育性” 。它选择实现C语言的一个 高度精简子集 ，足以支撑嵌入式开发的核心需求：基本的算术与逻辑运算、控制流（if/else, for/while）、函数调用、指针操作（尤其是针对硬件寄存器的访问），以及简单的数据类型（ int , char , 指针）。它刻意避开了C语言中那些复杂且容易产生歧义的部分，比如完整的预处理、复杂的类型系统（ struct / union 位域）、动态内存分配（ malloc / free ）和标准库。

这样做的好处是巨大的：

1. 代码库小巧 ：整个编译器可能只有几千行代码，你可以在一两个小时内通读其核心逻辑。
2. 依赖极少 ：它可能只需要一个C标准库（甚至部分自制）和一个汇编器（用于生成最终的目标文件），极大降低了移植和理解的难度。
3. 行为可预测 ：没有复杂的优化流水线，你写的代码几乎会以最直观的方式被翻译成机器指令。这对于硬件时序要求苛刻、需要精确周期控制的场景（如软件模拟I2C、SPI）非常有用。
4. 教学意义 ：它完美地展示了编译器的经典阶段：词法分析、语法分析、语义分析、中间代码生成、目标代码生成。你可以像看一本活生生的教科书一样，看到 a = b + c; 是如何一步步变成 LD , ADD , ST 这样的汇编指令的。

2.2 目标定位：瞄准8/16位微控制器

chimpiler 的目标后端通常不会是x86或ARM Cortex-A这类高性能处理器。它的天然栖息地是 8位AVR 、 PIC 、 8051 ，或者 16位MSP430 ，以及**ARM Cortex-M0/M0+**这类极致追求能效比和成本的内核。这些架构的指令集相对简单，寻址模式有限，正好与一个简易编译器的输出能力相匹配。

项目架构通常会遵循以下流程：

C源代码 (精简子集) -> Chimpiler前端 -> 中间表示 (IR) -> Chimpiler后端 -> 汇编代码 (AT&T/Intel风格) -> 外部汇编器 -> 目标文件 (.o) -> 外部链接器 -> 可执行文件 (.elf/.hex)

chimpiler 的核心工作集中在前后端。它负责将C代码翻译成针对特定架构的、正确的汇编代码。至于将汇编代码转换成机器码（汇编器）、合并多个目标文件并解决地址引用（链接器），这些工作通常会交给成熟的现有工具链（如 avr-as , arm-none-eabi-ld ）来完成，这是一种务实且高效的策略。

3. 关键模块深度解析与实现要点

3.1 词法分析器：从字符流到单词

词法分析器是编译器的“眼睛”。它的任务是将源代码的字符流（ char stream ）切割成一个个有意义的词素（ token ），比如关键字（ int 、 while ）、标识符（ variable_name ）、常量（ 123 、 0x1F ）、运算符（ + 、 = ）和界符（ ; 、 { 、 } ）。

在 chimpiler 中，实现一个词法分析器通常不会用 lex 这样的自动生成工具，而是手写一个状态机。这样做的目的是保持极简和可控。

实现要点与避坑指南：

1. 手写状态机 ：代码结构清晰。你会有一个主循环，根据当前字符 ch 跳转到不同的处理函数。

   Token get_next_token() {
       skip_whitespace();
       if (is_end_of_file(ch)) return TOKEN_EOF;
       if (is_alpha(ch) || ch == '_') return parse_identifier_or_keyword();
       if (is_digit(ch)) return parse_number();
       if (ch == '"') return parse_string_literal(); // 可能不支持或简化
       return parse_operator_or_punctuator();
   }
   

2. 标识符与关键字识别 ：识别出标识符后，需要在一个小的哈希表或查找表中比对，判断它是否是语言定义的关键字。 chimpiler 的关键字列表会很短。

3. 数字解析 ：这是第一个容易出错的地方。你需要处理十进制（ 123 ）、十六进制（ 0x1F ）、八进制（ 077 ，但简易编译器可能先不支持）。特别注意整数常量的类型，在嵌入式C中，默认的 123 可能是 int ，但 32768 在16位机上可能就需要是 long 。 chimpiler 初期可以做一个简单假设，比如所有整数都是 int 。

4. 字符串与字符常量 ：嵌入式环境中字符串处理很谨慎。 chimpiler 可能只支持字符串字面量作为常量数组初始化，而不支持复杂的转义序列（如 \n , \t ）。解析时要注意处理结束引号。

5. 注释处理 ：必须支持 /* */ 和 // 。在 skip_whitespace() 函数中，当遇到 / 时，需要预读下一个字符来判断是注释起始符还是除法运算符。

注意 ：词法分析器不应该关心单词的上下文含义。它只负责识别和分类。例如，它会把 int 识别为关键字 TOKEN_INT ，把 foo 识别为标识符 TOKEN_IDENT ，但不会知道 int 是类型声明符， foo 是变量名还是函数名。

3.2 语法分析器：构建抽象语法树

语法分析器是编译器的“大脑”，它根据预定义的语法规则（通常用扩展巴科斯范式EBNF描述），将词法分析器产生的 token 流组织成一棵 抽象语法树 。这棵树反映了程序的层次结构。

对于C语言的一个子集，其语法规则可以大大简化。例如，一个简单的声明和赋值语句的语法可能如下：

program        = (function_definition | global_declaration)*
function_definition = type identifier '(' parameter_list? ')' compound_statement
global_declaration = type identifier ('=' expression)? ';'
statement      = expression_statement | return_statement | compound_statement | if_statement | while_statement ...
expression_statement = expression ';'
expression     = assignment
assignment     = logical_or ('=' assignment)?
logical_or     = logical_and ('||' logical_and)*
logical_and    = equality ('&&' equality)*
equality       = relational (('==' | '!=') relational)*
relational     = additive (('<' | '>' | '<=' | '>=') additive)*
additive       = multiplicative (('+' | '-') multiplicative)*
multiplicative = unary (('*' | '/' | '%') unary)*
unary          = ('+' | '-' | '!' | '~' | '*’ | ‘&’) unary | primary
primary        = identifier | constant | '(' expression ')'

实现策略与心得：

1. 递归下降法 ：这是手写编译器最直观的方法。为语法规则中的每一个非终结符（如 expression , statement ）编写一个对应的解析函数。函数内部根据当前 token 预测应该使用哪条产生式，并递归调用其他解析函数。这种方法代码结构清晰，错误信息容易定位。

2. 抽象语法树节点设计 ：AST节点的设计至关重要。它需要能表达所有语法结构。通常你会有一个基础的 Node 结构体，包含节点类型，然后通过联合体 union 来承载不同类型节点的特定数据。

   typedef enum { NODE_VAR_DECL, NODE_FUNC_CALL, NODE_BINARY_OP, NODE_CONSTANT, ... } NodeType;
   typedef struct Node {
       NodeType type;
       union {
           struct { char* name; Type* var_type; } var_decl;
           struct { struct Node* left; struct Node* right; int op; } binary_op;
           struct { int int_value; } constant;
           // ... 其他节点类型
       } data;
       struct Node* next; // 用于连接语句链表
   } Node;
   

3. 运算符优先级与结合性 ：上述语法规则中，从 expression 到 primary 的层层定义，实际上隐式地定义了运算符的优先级（ * 比 + 高）和结合性（ = 是右结合， + 是左结合）。在递归下降解析时，这种设计能很自然地处理优先级问题。例如，解析 expression 的函数会调用 assignment ，而 assignment 在遇到 = 之前，会先调用 logical_or 来解析左边的表达式，这就保证了 = 的优先级最低。

4. 错误恢复 ：一个健壮的编译器在遇到语法错误时不应立即崩溃。简易的错误恢复策略包括：同步到下一个分号 ; 或右大括号 } ，然后继续解析。虽然 chimpiler 可能不追求工业级健壮性，但基本的错误报告（如“第5行：期待分号”）是必须的。

3.3 语义分析：类型检查与符号表管理

语法分析只关心结构是否正确，语义分析则关心 含义 是否正确。这是编译器前端最复杂的部分之一，但在 chimpiler 的简化世界里，我们可以大幅缩减其职责。

核心任务：

1. 构建符号表 ：这是一个记录所有标识符（变量、函数、类型）信息的数据结构。当解析到一个声明（如 int a; ）时，你需要将 a 的名字和它的类型 int 插入到当前作用域的符号表中。当后面使用 a 时，你就可以从符号表中查找它的信息。

2. 类型检查 ：

   • 简单类型系统 ： chimpiler 可能只支持 int 、 char 、指针（如 int* ）。甚至为了简化，所有整数运算都可以在 int 类型下进行。
   • 赋值兼容性 ：检查 a = b; 中 b 的类型是否可以赋值给 a 的类型。对于简易编译器，可能只允许相同类型赋值，或者允许整数到指针的强制转换（在嵌入式寄存器操作中很常见，如 *(volatile int*)0x40000000 = 1; ）。
   • 函数调用检查 ：检查调用的函数名是否已声明，实参个数和类型是否与形参匹配。

3. 常量表达式求值 ：对于全局变量初始化 int x = 10 + 2 * 3; ，编译器应该在编译时计算出 16 ，并将这个值直接写入数据段，而不是生成运行时计算的代码。

实现心得：

• 作用域栈 ：符号表需要支持作用域。通常用一个栈来实现。进入一个函数体或复合语句块时，压入一个新的作用域；退出时，弹出并销毁。查找标识符时，从栈顶（当前作用域）向栈底（全局作用域）查找。
• 类型表示 ：用一个简单的结构体表示类型信息，如 { base_type, is_pointer, pointer_to } 。
• 错误报告 ：语义错误的报告比语法错误更有价值。需要明确指出“第10行：未声明的标识符 ‘foo‘”或“第15行：类型不匹配，无法将 ‘char*‘ 赋值给 ‘int‘”。

3.4 中间代码生成与优化

对于 chimpiler 这样的简易编译器，中间表示可能非常低级，甚至直接跳过IR，从AST生成汇编。但引入一个简单的IR（如三地址码）可以让后端与目标架构解耦，提高可移植性。

三地址码示例：

t1 = b + c
a = t1

这表示一个加法操作和赋值操作。

简易优化 ：即使是最简单的编译器，也可以做一点优化，比如 常量传播 和 死代码消除 。

• int x = 5; int y = x + 2; 可以优化为 int y = 7; 。
• 如果一个变量被赋值后从未使用，那么赋值语句可以被删除。

在资源受限的嵌入式环境中，这类优化带来的代码尺寸减少有时是至关重要的。 chimpiler 可以实现一个非常简单的、在IR或AST上进行的优化遍历。

3.5 目标代码生成：从抽象到具体机器指令

这是后端的主要工作，也是最具挑战性、最贴近硬件的一步。你需要将IR或AST映射到特定CPU的指令集上。

以生成ARM Thumb指令（Cortex-M系列常用）为例：

1. 寄存器分配 ：这是最大的难点。嵌入式CPU的通用寄存器数量有限（Cortex-M通常有13个）。复杂的算法（如图着色寄存器分配）对于 chimpiler 来说可能太重了。一个简单实用的策略是 局部变量栈帧分配 ：将所有局部变量都放在栈上，只有当前参与运算的少数值才加载到寄存器中，用完后立即写回。虽然性能不高，但实现简单，且对代码大小影响可控。

   • 策略 ：为每个函数计算其局部变量所需的总栈空间大小。在函数入口处生成指令调整栈指针（ SUB SP, SP, #size ），出口处恢复（ ADD SP, SP, #size ）。访问变量时，通过栈指针加偏移量（ [SP, #offset] ）来寻址。

2. 指令选择 ：将IR操作映射到机器指令。例如：

   • IR: t = a + b -> ARM: LDR r0, [sp, #a_offset] ; LDR r1, [sp, #b_offset] ; ADDS r0, r0, r1 ; STR r0, [sp, #t_offset]
   • 注意处理立即数。ARM的 ADD 指令对立即数有范围限制，可能需要分多条指令加载一个大常数。

3. 函数调用约定 ：必须遵循目标平台的ABI。对于ARM Cortex-M，通常使用 AAPCS 简化版。例如，前4个整型参数通过寄存器 R0-R3 传递，返回值通过 R0 传递，调用者需要保存 R0-R3 和 R12 ，被调用者需要保存 R4-R11 。 chimpiler 在初期可以做一个极度简化的约定，比如所有参数都通过栈传递，这虽然效率低，但实现简单。

4. 汇编代码生成 ：遍历AST或IR，为每个节点生成对应的汇编文本。你需要一个代码生成器，它知道如何生成变量加载、存储、算术运算、跳转、函数调用/返回等指令的字符串形式。

一个简单的代码生成函数示例：

void gen_binary_op(Node* node, FILE* out) {
    // 生成左操作数，结果假设在虚拟寄存器r0
    gen_expression(node->data.binary_op.left, out);
    // 将左操作数保存到栈上临时位置，因为接下来要计算右操作数
    fprintf(out, "  str r0, [sp, #-4]!  @ 压栈保存左值\n");
    // 生成右操作数，结果在r0
    gen_expression(node->data.binary_op.right, out);
    // 将左操作数从栈中弹出到r1
    fprintf(out, "  ldr r1, [sp], #4    @ 出栈恢复左值到r1\n");
    // 根据操作符生成运算指令
    switch (node->data.binary_op.op) {
        case '+': fprintf(out, "  adds r0, r1, r0\n"); break;
        case '-': fprintf(out, "  subs r0, r1, r0\n"); break;
        case '*': fprintf(out, "  muls r0, r1, r0\n"); break; // M0+支持
        // ... 其他操作
    }
    // 此时运算结果在r0中
}

4. 从源码到点亮LED：完整实操流程

让我们假设目标平台是 STM32F030F4P6 （一款典型的Cortex-M0芯片，仅有16KB Flash和4KB RAM），我们要用 chimpiler 编译一个点灯程序。

4.1 准备最简单的C源码

我们写一个极简的程序，不涉及中断、不涉及复杂的启动代码。假设我们已经知道LED连接在 PA4 引脚上。

blink.c :

// 定义GPIOA寄存器地址 (简化，实际地址需查手册)
#define GPIOA_MODER   (*((volatile unsigned int*)0x48000000))
#define GPIOA_ODR     (*((volatile unsigned int*)0x48000014))

// 简单的延时函数（软件循环，不精确）
void delay(unsigned int count) {
    while(count--) {
        // 空循环，充当延时
        __asm__ volatile ("nop");
    }
}

int main() {
    // 1. 配置PA4为输出模式 (01)
    // 先清零PA4对应的位域（2位），然后设置为01
    GPIOA_MODER &= ~(0x3 << (4 * 2)); // 清零
    GPIOA_MODER |=  (0x1 << (4 * 2)); // 设置为输出

    // 2. 主循环，闪烁LED
    while(1) {
        GPIOA_ODR |= (1 << 4);   // 置位PA4，LED亮（假设低电平点亮）
        delay(500000);
        GPIOA_ODR &= ~(1 << 4);  // 清零PA4，LED灭
        delay(500000);
    }
    return 0; // 实际上永远不会执行
}

4.2 使用Chimpiler进行编译

假设我们已经构建好了 chimpiler ，它接收一个C文件，输出一个汇编文件。

# 1. 使用chimpiler编译C文件，生成汇编
./chimpiler -target arm-cortex-m0 -o blink.s blink.c

# 2. 使用GNU工具链的汇编器将汇编转换为目标文件
arm-none-eabi-as -mcpu=cortex-m0 -mthumb -o blink.o blink.s

# 3. 链接。我们需要一个简单的链接脚本（linker script）来定义内存布局（FLASH和RAM的起始地址和大小）
# 同时，我们需要提供最简化的启动文件（startup.s），至少包含堆栈指针初始化和跳转到main的代码。
arm-none-eabi-ld -T stm32f030f4.ld -nostdlib -o blink.elf startup.o blink.o

# 4. 从ELF文件中提取原始的二进制镜像
arm-none-eabi-objcopy -O binary blink.elf blink.bin

# 5. 使用编程器（如OpenOCD、ST-LINK Utility）将blink.bin烧录到芯片的Flash起始地址（0x08000000）

4.3 链接脚本与启动文件简析

这是 chimpiler 生态中不可或缺但通常由用户提供的外部部分。

简易链接脚本 stm32f030f4.ld ：

MEMORY
{
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
    RAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 4K
}

SECTIONS
{
    .text : {
        *(.text*)   /* 所有代码段 */
        *(.rodata*) /* 只读数据 */
    } > FLASH

    .data : {
        _sdata = .;
        *(.data*)
        _edata = .;
    } > RAM AT > FLASH  /* 数据在Flash中，上电后需拷贝到RAM */

    .bss : {
        _sbss = .;
        *(.bss*)
        _ebss = .;
    } > RAM

    /* 堆栈指针初始值（位于Flash开头） */
    . = ORIGIN(FLASH);
    LONG(ORIGIN(RAM) + LENGTH(RAM)); /* 初始SP值 */
    LONG(main);                      /* 复位向量，指向main函数 */
}

最简化启动文件 startup.s (ARM汇编)：

.syntax unified
.cpu cortex-m0
.thumb

.global _start
.section .text
_start:
    // 1. 设置堆栈指针（由链接器脚本提供初始值）
    ldr r0, =_stack_top
    mov sp, r0

    // 2. 将.data段从Flash拷贝到RAM（如果需要）
    ldr r0, =_sdata
    ldr r1, =_edata
    ldr r2, =_text_end
    cmp r0, r1
    beq .skip_data_copy
.copy_loop:
    ldr r3, [r2], #4
    str r3, [r0], #4
    cmp r0, r1
    blt .copy_loop
.skip_data_copy:

    // 3. 清零.bss段
    ldr r0, =_sbss
    ldr r1, =_ebss
    mov r2, #0
    cmp r0, r1
    beq .skip_bss_clear
.clear_loop:
    str r2, [r0], #4
    cmp r0, r1
    blt .clear_loop
.skip_bss_clear:

    // 4. 跳转到C语言的main函数
    bl main

    // 5. 如果main返回（理论上不会），进入死循环
    b .

这个启动文件完成了最基本的C运行时环境初始化：设置栈、初始化静态数据、清零未初始化数据。

4.4 编译结果分析与优化思考

运行完上述流程后，你会得到一个 blink.bin 文件。用 arm-none-eabi-objdump -d blink.elf 反汇编，可以看到 chimpiler 生成的代码。

你可能会发现：

1. 代码尺寸 ：相比于GCC -Os编译的版本， chimpiler 生成的代码可能更大。这是因为缺乏高级优化（如指令调度、循环展开、函数内联），并且寄存器分配策略保守。
2. 性能 ：由于所有局部变量都在栈上，每次访问都需要 LDR / STR 指令，性能会低于使用寄存器频繁的GCC版本。
3. 可读性 ：生成的汇编代码结构会非常直接，几乎是你C代码的逐句翻译，这对于理解和调试底层行为非常有帮助。

这正是 chimpiler 的价值所在： 用性能和尺寸上的一点牺牲，换取极致的透明度和可控性 。你可以精确地知道每一条指令是如何产生的，你可以修改编译器后端来为特定的代码模式生成更优的指令序列，这是使用大型编译器难以做到的。

5. 常见问题、调试技巧与进阶方向

5.1 编译过程问题排查

问题现象	可能原因	排查思路与解决方法
chimpiler 解析失败，报语法错误	1. C源码使用了 chimpiler 不支持的语法（如 for 循环初始化语句内声明变量）。 2. 词法分析器未正确处理某些字符或数字格式。	1. 简化测试代码，使用最基本的语句。 2. 在 chimpiler 的词法分析阶段添加调试输出，打印每个识别出的 token ，看在哪里出错。
生成的汇编文件无法被 as 汇编	1. 生成了目标架构不支持的指令或语法。 2. 标签（Label）或指令格式不符合GNU汇编器的要求（如缺少 .thumb 指令）。	1. 查阅目标架构的指令集手册，确保生成的每一条指令都是合法的。 2. 在汇编文件开头添加必要的汇编器指令（如 .syntax unified , .cpu cortex-m0 , .thumb ）。 3. 用 arm-none-eabi-as -a blink.s > blink.lst 生成列表文件，查看错误具体位置。
链接失败，提示未定义符号 main	1. chimpiler 生成的汇编中， main 函数的标签名可能不是 main （例如被修饰成了 _main ）。 2. 启动文件中跳转的符号名不匹配。	1. 检查 chimpiler 后端代码生成时，函数标签的命名规则。 2. 确保链接时所有目标文件中的符号命名一致。使用 arm-none-eabi-nm blink.o 查看目标文件中的符号。
程序烧录后无反应，芯片“砖化”	1. 堆栈指针初始化错误，导致一开始就硬件错误。 2. 中断向量表缺失或错误。Cortex-M要求向量表前几个字是初始SP和复位向量地址。 3. 时钟未初始化，芯片没有运行在正确的频率下。	1. 最可能原因 ：链接脚本中初始SP值设置错误，或者启动文件没有正确加载它。检查链接脚本中 _stack_top 的计算（通常是RAM末尾）。 2. 确保Flash起始地址（0x08000000）处的前两个字是正确的：第一个字是RAM末尾地址，第二个字是 _start 或 main 的地址。可以用hex查看器检查bin文件。 3. 对于STM32，在 main 函数最开始需要初始化时钟（HSI或HSE）。我们的示例省略了这点，可能导致指令执行极慢或外设不工作。需要添加RCC相关配置代码。

5.2 调试技巧：从软件到硬件

1. 软件仿真 ：在真正烧录前，使用QEMU或ARM官方提供的模拟器（如Arm Fast Models）来运行你的 blink.elf 。这可以排除硬件问题，专注于软件逻辑。
2. printf调试法（简陋版） ：在没有调试器的情况下，可以复用一个串口GPIO引脚，通过特定的高低电平变化来发送“信号”。例如，在关键函数入口和出口拉高/拉低某个引脚，用逻辑分析仪或示波器观察，可以判断程序是否执行到该处。
3. 内联汇编插入断点 ：对于Cortex-M，你可以插入 __asm__ volatile ("bkpt #0") 。当芯片在调试模式下运行时，这会触发一个断点。虽然 chimpiler 可能不支持内联汇编，但你可以在C源码中写一个空函数，然后在 chimpiler 的后端中，将这个特定函数调用直接翻译成 BKPT 指令。
4. 分析反汇编 ：养成看反汇编代码的习惯。 objdump -d 是你的好朋友。对比 chimpiler 输出和GCC -O0的输出，能帮你理解编译器工作的差异，并发现自己的后端生成逻辑是否有误。

5.3 进阶优化与扩展方向

当你让基础的 chimpiler 工作起来后，可以考虑以下方向深化：

1. 实现更完整的C子集 ：逐步添加 switch 语句、 struct 基本操作、枚举类型、 const 限定符等。
2. 改进寄存器分配 ：实现一个简单的线性扫描寄存器分配算法，将最活跃的变量保留在寄存器中，能大幅提升性能。
3. 窥孔优化 ：在生成汇编后，进行一次简单的窥孔优化。例如，将连续的 STR / LDR 指令合并为 STM / LDM （块传输指令）；将 MOV r0, r0 这种空操作指令删除。
4. 支持内联汇编 ：允许在C代码中直接嵌入目标汇编指令，这对于操作特殊寄存器或实现极致性能的代码块至关重要。
5. 集成简单的链接器 ：将多个 .c 文件编译成的多个 .o 文件，合并链接成一个可执行文件，自己处理符号解析和重定位。这能让你彻底理解链接过程。
6. 转向其他架构 ：尝试为RISC-V（一个更简单、开源的指令集）或经典的AVR 8位机编写后端。不同指令集的设计哲学会给你带来全新的挑战和启发。

从头实现一个编译器，尤其是面向嵌入式场景的编译器，是一个将计算机科学众多理论知识（数据结构、算法、形式语言、计算机体系结构）串联起来的绝佳实践。 joelmartinez/chimpiler 这样的项目提供了一个完美的起点。它剥离了商业编译器的复杂性，让你能聚焦于核心原理。当你亲手编译的程序第一次让LED按照你的逻辑闪烁起来时，那种对计算机系统从高层语言到硅片底层的完整掌控感，是使用现成工具链无法比拟的。这个过程会深刻重塑你对代码、内存和机器指令的理解，让你在未来面对任何嵌入式系统的疑难杂症时，都多了一份从编译器层面思考问题的底气和视角。