企业官网建设流程全解析

1. 为什么需要软件中断：从"用户程序想干特权事"说起

做ARM裸机开发或者底层系统编程的人，早晚会撞上SWI（Software Interrupt，软件中断）这个东西。很多初学者刚接触它时总觉得有点绕：明明就是个中断，为什么还要分"软件"和"硬件"？更有人直接跳过这个知识点，觉得"反正我把IRQ中断弄明白就够用了"。但如果你打算深入理解系统调用（System Call）、操作系统的任务切换，或者想搞明白为什么有些程序可以随便操作寄存器、有些程序却会被拒绝访问，SWI就是你绕不过去的一道坎。

我用一个生活化的比喻来解释SWI的意义：想象你在一家公司里，普通员工（用户态程序）没有权限进入财务系统，但工作需要查一个数据，怎么办？正常途径是你提交一个申请单给财务部（操作系统内核），由财务部的专员（运行在特权模式下的代码）帮你查询，再把结果还给你。SWI就是那张"申请单"，而"提交申请单"的动作，就是执行一条SWI指令。

在ARM处理器体系下，程序运行在不同特权级别中。裸机环境下大家可能不觉得，因为你写的启动代码基本都跑在SVC（Supervisor，超级用户）模式下，权限拉满。但一旦你引入操作系统或者需要做简单的任务隔离，就必然面临这样的需求：普通任务把某些关键操作（如读写硬件寄存器、切换任务上下文、修改系统配置）委托给一个更可信、权限更高的程序段去执行，而不是让每个任务都能随意改动系统状态。否则一个任务写崩了，整个系统都跟着遭殃。

SWI异常就是实现这种"委托"的官方入口。只要用户程序执行了SWI指令，处理器会立即从当前模式切换到SVC模式，跳转到固定的异常向量地址，并把之前的状态保存好。整个过程不但自动完成模式切换，还把用户程序的"身份"也带进了异常处理程序——通过SWI指令本身携带的立即数，内核就能知道用户程序想调用哪个服务。

这篇文章以一个完整的SWI异常程序示例为主线，从ARM异常响应的底层机制讲起，手把手教你写向量表、配SVC栈、实现支持多个功能的SWI处理函数，再附上调试时最容易踩的几个坑。无论你是刚接触ARM体系结构的初学者，还是已经在写裸机代码但想系统梳理异常机制的开发者，这篇文章都可以当作一份可直接抄作业的参考。

2. 动手之前必须吃透的ARM异常响应机制

2.1 异常向量表就是一张"跳转地图"

ARM处理器的异常处理和X86的中断描述符表在思路上很相似，但更简洁。处理器把各种异常对应的入口地址固定放在内存的开头一段区域，这张表叫异常向量表。每种异常占一个槽位，每个槽位通常放一条跳转指令，共8个槽位：

看到规律了吗？ARM设计这张表时，把SWI的向量地址固定在0x08，和复位向量只隔了一个未定义指令槽。为什么很多嵌入式项目的链接脚本要把代码段的起始地址安排在0x00或者向量表所在的基地址？因为处理器跳异常处理程序时不经过间接跳转，它直接用PC跳向这些固定地址，搬不走也改不了（虽然可以用高性能向量偏移寄存器搬移，那是后话）。

2.2 SWI异常发生时，处理器自动做了哪些事

很多新手写SWI处理程序时最困惑的一点是：程序"莫名其妙"就跳进来了，有些寄存器已经变了，有些好像又没变，到底哪些是硬件已经帮我做好的、哪些必须由我自己来干？这里必须把ARM架构手册里的异常响应流程彻底搞清楚。

当一条SWI指令执行时，ARM处理器内部会按顺序完成以下几件事：

1. 把当前指令的下一条指令地址保存到LR_svc（即SVC模式下的链接寄存器）。注意一个关键细节：这里保存的是下一条指令的地址，而不是正在执行或者刚执行完的SWI指令地址。用术语说，SWI属于"指令中止型"异常，PC还没来得及更新到下一个指令，所以LR里实际上是PC + 4。后面要从LR往回找SWI指令时，应该用LR - 4。

2. 把当前程序状态寄存器（CPSR）完整备份到SPSR_svc。CPSR里的条件标志位、中断屏蔽位、处理器模式位，全部原样存进去，这是将来恢复现场的唯一依据。

3. 修改CPSR，完成模式切换。处理器把CPSR的模式位改成SVC模式（M[4:0] = 10011），同时把I位（IRQ屏蔽位）置1，意思是SWI异常处理过程中，普通外部中断暂时被屏蔽。注意F位（FIQ屏蔽位）并不会被自动置位，所以FIQ快中断依然可以进来打断SWI处理程序。

4. 跳转到0x08。更准确地说，是跳转到"向量地址 + 向量基地址偏移"。如果向量基地址是0，就是从0x08执行。

这套动作完全由硬件在几个时钟周期内闪电完成，不需要你写哪怕一行代码。你真正要做的是：在0x08处放一条跳转指令，让程序跳到真正的SWI处理函数；在进入处理函数后第一时间保存现场；在处理完成后恢复现场并返回。

2.3 SWI指令自身的编码格式：一个12位的"暗号"

SWI指令的机器码长什么样？这是整个示例的灵魂。ARM指令集里SWI指令的编码格式是：

COND 1 1 1 1 —— 24位立即数（其中低12位实际可用）

具体来说，SWI指令的高8位是条件码（COND）和固定的1111标志位，低24位里只有低12位是真正有效的立即数，高12位通常被忽略或者保留。也就是说，你可以在SWI指令里塞入一个最高4096的编号，这个编号就是操作系统或你自定义的异常处理程序判断"用户要调用什么服务"的依据。我习惯把这12位叫"SWI编号"或者"系统调用号"。

举个例子：指令SWI 0x01的机器码是0xEF000001，指令SWI 0x02的机器码是0xEF000002。异常处理程序从LR - 4处读取这条指令的机器码，把高8位清掉，就能拿到低24位里的编号（实际用低12位就够了）。这相当于用户程序给处理程序递了一张写了编号的小纸条，处理程序扫一眼编号就知道该做什么。

我见过有的教材喜欢用"系统调用号即SWI编号"这个说法，这没问题，但要注意：裸机环境下SWI编号的意义完全由开发者自己定义，ARM架构本身不规定哪个编号对应哪个功能。到了Linux等操作系统里，SWI编号才和系统调用号产生了固定的映射关系。

3. 从零写SWI异常处理程序：一套可直接烧录的完整示例

3.1 先搭好启动代码和向量表

要验证SWI异常，第一步是让处理器在上电后能走到你写的代码里，并且0x08位置有正确的跳转指令。我习惯用一段极简的汇编启动代码来做这件事，不依赖任何库，适合直接烧到开发板上观察现象。

向量表部分：

.text .global _start _start: b reset_entry @ 0x00: Reset b undef_entry @ 0x04: Undefined Instruction b swi_entry @ 0x08: Software Interrupt b prefetch_entry @ 0x0C: Prefetch Abort b data_entry @ 0x10: Data Abort nop @ 0x14: Reserved b irq_entry @ 0x18: IRQ b fiq_entry @ 0x1C: FIQ

注意我这里用的是b分支指令而不是ldr pc, 某地址。两种写法都常见，区别在于：

• b指令是相对跳转，范围受限制（前后约32MB），但指令短，代码紧凑。
• ldr pc, [pc, #offset]是绝对跳转，可以跳转到任意32位地址，但每条指令占8字节（跳转地址也占一个word）。

不同启动代码风格各有拥趸。个人经验：如果你的向量表放在最低地址、镜像也在低地址，用b最省事；如果向量表要通过MMU映射到高地址，或者要做动态重定位，用ldr更稳。这里示例放在0地址启动，用b就够了。

复位入口里要做的核心事情有三件：设置SVC栈、设置各模式栈（如果后续用到中断，建议连IRQ模式栈一起配好）、然后跳到主程序。

reset_entry: @ 设置SVC模式的栈指针 ldr sp, =svc_stack_top @ 顺便设置IRQ模式栈，避免后续做实验时踩到缺栈的坑 mrs r0, cpsr bic r0, r0, #0x1F orr r0, r0, #0x12 @ IRQ模式 msr cpsr, r0 ldr sp, =irq_stack_top @ 切回SVC模式 mrs r0, cpsr bic r0, r0, #0x1F orr r0, r0, #0x13 @ SVC模式 msr cpsr, r0 @ 进入主程序 bl main dead_loop: b dead_loop

这段代码里最关键的是ldr sp, =svc_stack_top。SWI异常一发生，处理器自动切到SVC模式，如果你没给SVC模式配栈，那么这个模式下的SP寄存器还是复位后的初始值（可能是0或随机值），处理程序里只要一压栈，立刻写飞到天边，系统必挂。所以SWI实验的第一步永远是"先聊聊SVC栈有没有配好"。

3.2 最简单的SWI处理函数：保存现场与恢复现场

现在进入正题。当处理器跳到0x08的b swi_entry时，真正的SWI处理函数开始执行。第一件事是保存现场，最后一件是恢复现场，这两件事的写法有固定格式，我直接给完整代码再逐行解释。

swi_entry: @ 保存现场：将用户程序可能用到的寄存器都压入SVC栈 stmfd sp!, {r0-r12, lr} @ 从LR-4处取出SWI指令的机器码，并提取SWI编号 ldr r0, [lr, #-4] bic r0, r0, #0xFF000000 @ 清除高8位条件码和指令标志，保留低24位 @ 根据编号做功能分发 cmp r0, #0x01 bleq swi_func_print cmp r0, #0x02 bleq swi_func_add @ 恢复现场 ldmfd sp!, {r0-r12, lr} movs pc, lr

先解释stmfd sp!, {r0-r12, lr}。FD全称是Full Descending，意思是栈向低地址生长，且SP指向栈顶的有效数据。压栈时寄存器编号小的放在低地址（ARM规定编号低的寄存器在低地址，但这不影响你使用）。这里把通用寄存器r0到r12全部保存，同时保存了LR。为什么要保存LR？因为SWI处理程序内部还可能调用子函数，主程序原本放在LR里的返回地址会被内层调用的BL指令覆盖，必须提前压栈保存。实际上，ARM在进入SWI异常时已经把"异常返回地址"装进了LR_svc，但如果你在SWI处理程序里继续用BL调用子程序，那这个LR又会被覆盖，所以压栈LR非常必要。

恢复现场用ldmfd sp!, {r0-r12, lr}，和压栈顺序对应。注意最后一句返回指令写的是movs pc, lr，而不是普通的mov pc, lr。这个s后缀有大学问：movs pc, lr在算术逻辑运算类指令里带了S标志位时，执行完会同时把SPSR_svc恢复回CPSR。也就是说，它不只让PC跳回用户程序的断点处，还会把用户程序的处理器模式、中断屏蔽位、条件标志全部恢复原样。如果你漏写了s后缀，程序虽然能跳回来，但CPSR还停留在SVC模式，中断屏蔽位也保持禁止状态，后面再跑就可能出现"从SVC模式执行用户代码"的混乱局面。

3.3 功能分发和具体服务函数的实现

上面代码里的bleq是"条件相等且带链接地调用"，意思是只有r0里的SWI编号等于你cmp的比较值时才调用对应函数。用这种方式实现功能分发最简单直观。

主程序里通过SWI调用服务的代码：

.global main main: @ 初始化串口之类的操作省略，假设printf可用 bl serial_init @ 调用1号服务：打印一条消息 mov r0, #0x01 ldr r1, =hello_msg swi 0x01 @ 调用2号服务：执行加法，参数放在r0, r1，结果也回写到r0 mov r0, #100 mov r1, #23 swi 0x02 @ 此时r0应该有123，可以再打印出来验证 dead_end: b dead_end hello_msg: .asciz "Hello from SWI handler!\n"

注意我这里的参数传递约定：r0放SWI编号，r1放第一个参数，返回值用r0带回。这个约定不是ARM强制规定的，而是系统调用API的一种常见ABI风格。你可以完全按照自己的约定来，但一定要在文档或注释里写清楚，否则过两周回来看代码自己都会懵。

对应的处理函数：

@ 1号服务：打印r1指向的字符串 swi_func_print: mov r0, r1 bl serial_puts mov pc, lr @ 2号服务：计算r0 + r1，结果放r0 swi_func_add: add r0, r0, r1 mov pc, lr

这里有个容易被忽略的细节：swi_func_print和swi_func_add都是普通子函数，返回用的是mov pc, lr，不是movs。为什么？因为它们执行完后只是回到swi_entry主框架里，此时还不需要恢复CPSR，等整体处理完了，由movs pc, lr一次性恢复。这里的层次关系一定要理清楚：SWI异常入口保存现场 → 功能分发 → 具体服务函数（普通BL调用） → 回到分发处 → 恢复现场 → 异常返回。每层的返回方式不一样，混用了就会出诡异的bug。

我再强调一个点：swi_func_add修改了r0，所以在加完数之后，r0成了运算结果。这个结果会被后续的ldmfd sp!, {r0-r12, lr}恢复现场时覆盖掉吗？不会吗？会吗？——答案：会被覆盖！因为保存现场时压栈的r0还是用户程序传入参数时的值，恢复现场会把r0改成那个旧值。如果想让运算结果带回用户程序，必须在恢复现场之前，把返回值单独写到某个指定的地方，比如用户程序的寄存器是在栈上保存着的，那就找到栈上保存r0的位置，把新值写进去。更通用的做法是：把返回值放在用户程序的r0里，所以在恢复现场后让r0保持新值。怎么实现？简单：不把结果存在本函数的r0里，而是存在swi_entry里的一段代码中，在恢复现场之后、返回之前，再单独把返回值写入r0。

我再给一种更实用的写法，整体框架如下：

swi_entry: stmfd sp!, {r0-r12, lr} ldr r4, [lr, #-4] bic r4, r4, #0xFF000000 cmp r4, #0x01 bleq swi_func_print cmp r4, #0x02 bleq swi_func_add @ 恢复现场 ldmfd sp!, {r0-r12, lr} movs pc, lr

但如果swi_func_add要改r0，恢复现场会把r0还原，结果就带不回去了。解决思路是：在恢复现场之前，把要返回的值暂存到r4这样的寄存器，恢复完现场再把r4赋给r0。但r4在恢复现场时也被原样覆盖了。

绕来绕去，正规的解决方案有两个：

方案一：在压栈时特意多压一个寄存器当"临时返回值载体"，并在恢复现场前把它修改到用户程序r0所在的栈位置。

方案二（推荐）：把"返回值回写到保存的r0栈位置"这件事放到保存现场和恢复现场之间完成，也就是说，恢复现场的ldmfd用的是^后缀配合pc，能直接从栈里恢复出新的r0。

具体实现是修改压栈/出栈的寄存器集合，把r0的计算结果写到SP+0处（r0保存在栈中的位置）。例如：

@ 恢复现场时，让被调用的add函数的结果通过栈回写 str r0, [sp, #0] @ 把返回值写到栈上保存r0的位置 ldmfd sp!, {r0-r12, lr} movs pc, lr

这样就保证了恢复后r0是新的运算值。做法看似平淡，考虑到的原理却不简单：因为压栈时r0是第一个压入的，位于栈顶（低地址），恢复时它也是第一个被弹出。所以在弹出前把新r0写到栈顶，弹栈后r0就是新值了。

4. 完整工程里各部分的配合：链接脚本、栈空间与启动顺序

4.1 为什么你的代码烧进去后SWI一触发就硬fault

这是新手最容易卡住的地方。代码看着没毛病，向量表也写了，SWI也执行了，但一执行就死机或者跑飞。排除掉向量表没放对位置、链接脚本起始地址不对这两个常见因素外，剩下的高频原因就是我前面反复提过的SVC栈没配。

照着我之前的启动代码写法给SVC模式配栈就行。栈空间的分配也很简单，在汇编或者C文件里定义一块内存：

.section .bss .align 4 svc_stack: .space 4096 svc_stack_top: irq_stack: .space 4096 irq_stack_top:

.align 4保证栈顶地址是16字节对齐的，这对ARM处理器的栈操作不是硬性要求，但建议遵守。ARM的栈是满递减栈，SP要从栈底最高地址开始用，所以我们定义svc_stack_top指向栈空间的末尾。

还有个细节：如果你的链接脚本把.bss段放在SDRAM或者外部内存，那么要确保这段内存已经被初始化可访问。很多开发板启动时需要先初始化SDRAM控制器，如果SVC栈被分配在外部SDRAM里但SDRAM还没初始化，那SWI一触发照样死。解决办法要么把栈放在片内SRAM里，要么确保在能触发SWI之前完成SDRAM初始化。

4.2 主程序和SWI处理函数之间的ABI约定

我在这里明确一下这套示例使用的调用约定，方便你对照检查：

• r0：传递SWI编号（调用约定里的第一参数）
• r1：第一个用户参数
• r2：第二个用户参数（如果有）
• r3：第三个用户参数（如果有）
• 返回值：放在r0
• 在SWI处理程序内部使用BL调用子程序时，遵循ARM ATPCS规则，r4-r11必须在子程序里保存

为了让这套约定在实际项目里少踩坑，我建议把"触发系统调用"的入口封装成一个C函数或者汇编宏。比如在C文件里用内联汇编写：

int my_add(int a, int b) { int result; register int r0 __asm__("r0") = a; register int r1 __asm__("r1") = b; register int r0_out __asm__("r0"); __asm__ volatile( "swi 0x02\n" : "=r"(r0_out) : "r"(r0), "r"(r1) : "memory" ); result = r0_out; return result; }

不过裸机环境下绕开C内联汇编、直接在汇编层做系统调用更直观，也更容易理解寄存器传参的本质。

4.3 在实际开发板上验证（QEMU或用ARM开发板实测）

如果你手头没有真实开发板，用QEMU的ARM模拟器完全够做这个实验。QEMU以-machine vexpress-a9为例：

qemu-system-arm -M vexpress-a9 -m 32M -nographic -kernel my_swi_example.bin

注意这里需要把代码做成立即运行在0x60000000这种地址的形式，或者直接用-bios方式加载到0地址，不同加载方式对应不同的链接地址，玩QEMU时别光顾着改代码，链接脚本的起始地址也要跟着变。

烧到真机上的验证步骤：

1. 在SWI处理函数入口加LED翻转或者串口打印标志，确认异常真的进入了处理函数。
2. 在返回指令movs pc, lr前加断点或串口打印，确认处理流程完整走到返回点。
3. 检查返回后用户程序的PC指向哪里——应该指向SWI指令的下一条指令，也就是PC = LR。

5. 参数传递、返回值与多服务分发的进阶处理

5.1 从用户程序到SWI处理程序的参数传递方式

上节的例子是简单的r0传编号、r1传字符串地址。但当参数变多、甚至要传递结构体指针时，这套约定依然够用，只要和你的服务函数定义匹配即可。我整理一份常用参数传递分配表，供你设计时参考：

为什么第四个参数开始要压栈？因为ARM的ATPCS约定就只允许前4个参数放寄存器。SWI异常本身跳进SVC模式后栈已经切换，如果用户程序压栈传参，处理程序拿到的栈是SVC栈，根本看不到用户栈上的东西。所以SWI参数传递尽量少依赖栈，最好全用寄存器搞定。

5.2 返回值的回写细节：r0的"劫后余生"

前面提到的"返回值怎么写回r0"问题，我再用一个表格把不同写法的效果对比清楚，省得调试时一头雾水：

第三种写法其实是ldmfd sp!, {r0-r12, pc}^，这个^后缀的作用是加载PC的同时从SPSR恢复CPSR，相当于把ldmfd和movs pc, lr合并成一条指令。个人建议初学者用第二种：str指令显式写回，逻辑一目了然，不容易出错。

5.3 多服务分发：用跳转表替代一串CMP

如果服务数量超过三四个，继续用一堆cmp+bleq会让汇编代码变得很啰嗦。更工程化的做法是用跳转表：

swi_entry: stmfd sp!, {r0-r12, lr} ldr r4, [lr, #-4] bic r4, r4, #0xFF000000 @ 检查编号是否越界 cmp r4, #(swi_table_end - swi_table) / 4 ldrhs pc, =swi_default @ 越界走默认处理 adr r5, swi_table ldr pc, [r5, r4, lsl #2] swi_table: .word swi_func_print .word swi_func_add .word swi_func_delay .word swi_func_set_led swi_table_end: swi_default: @ 默认处理：忽略或打印未知编号 b swi_default

注意adr r5, swi_table这一行，ADR指令会生成一条基于PC的相对寻址指令，它靠PC计算表的实际地址，所以跳转表必须放在代码段里，和该指令距离不要太远。如果表放得太远，指令无法表达偏移，汇编器会直接报错。这是ARM汇编的相对寻址限制，写表时务必给足空间。

6. 调试SWI程序最容易踩的坑：来自真实项目里的排查清单

6.1 案例一：恢复现场后模式没切回来，程序继续在SVC模式乱跑

症状：SWI服务执行完后，程序貌似正常运行，可一旦用户代码里再触发别的异常，行为就完全不对；或者用户代码里想设置CPSR的某些位，读出来发现模式位不对。

原因：返回指令写成了mov pc, lr而不是movs pc, lr。少了s后缀，CPSR没有被恢复，用户程序依然运行在SVC模式下。这样一来，后续再触发SWI或者IRQ时，处理器会认为还处于SVC模式，异常返回地址和SPSR保存的时机全乱套。

排查方法：在处理程序返回前和返回后各读一次CPSR的值，对照模式位。正常应该是：用户程序在USR模式（0b10000）下执行SWI，返回后仍变回USR模式；如果你发现返回后CPSR显示的是0b10011（SVC），那就是movs后缀丢了。

6.2 案例二：LR_swi被覆盖导致返回地址错乱

症状：SWI服务函数内部有多个嵌套BL调用，最后返回时总是回到奇怪的位置，甚至变成死循环。

原因：进入SWI异常时，LR_svc保存的是用户程序的下一条指令地址。但你在SWI处理程序内部要调服务函数，比如bl swi_func_add，这会让LR_svc被覆盖成swi_func_add的返回地址。如果不提前把LR压栈，等处理完再想返回用户程序时，LR已经不是当初那个值了。

这也是为什么我在入口处用stmfd sp!, {r0-r12, lr}把LR一并压栈。这里压进去的LR是进入SWI异常时硬件填好的LR_svc（用户程序的下一条指令地址），压了它，后面ldmfd sp!, {r0-r12, lr}才能正确恢复出返回地址。

6.3 案例三：从SVC模式下执行SWI导致栈污染

症状：程序频繁调用SWI服务几次后，栈空间越用越多，过一会儿就炸了。

原因：如果用户程序本身就跑在SVC模式下（裸机常见的默认模式），此时执行SWI指令并不会真正切换模式——处理器本就处于SVC模式，SWI异常响应只是重新进入SVC模式而已。但异常响应流程依然会保存返回地址和CPSR，你的处理程序依然会压栈和出栈。如果调用者没注意SVCall和实际模式的关系，就会出现"同一个SVC栈被反复压栈出栈但SP没有归位"或者"用户栈和SVC栈混用"的问题。

排查方法：先确认用户程序运行在什么模式。如果确实运行在SVC模式，要么把用户程序切到USR模式再做SWI实验，要么接受这种重叠、但要确保栈深度充足。类比我做模拟项目X时的经历：最初一把梭，所有代码跑在SVC模式，SWI功能看起来正常，但项目里一旦引入任务切换，Bug立刻爆发。后来规规矩矩把用户代码切到USR模式，把SVC模式留给异常处理程序，问题才彻底干净。

6.4 案例四：向量表起始地址和链接地址不匹配

症状：程序烧进去后SWI执行时根本没有跳进处理函数，单步追踪发现0x08处内容不是你写的条目。

原因：要么链接脚本把代码段起始地址放在了0x00000000之外，而异常向量表并没有被正确映射到0x0；要么你把.vectors段单独放在某个地址，但中断控制器或内存映射没有把它重映射到向量位置。这在NOR Flash启动和RAM启动的板子上尤其常见——NOR启动时地址0就是Flash，RAM启动时地址0要映射到内部SRAM，不同板子差异很大。

解决办法：写链接脚本时显式划出向量段，并确保它的LMA和VMA一致，例如：

.vectors : { *(.vectors) } > RAM AT > ROM

复杂的内存映射不是本文重点，但你要时刻记住：处理器只认固定的向量地址，你的向量表必须真真切切地放在那里。

6.5 一次完整的SWI异常时序排查演示

我把自己调试时常用的检查顺序整理成下面这份清单，每次遇到SWI相关诡异问题我基本都按它过一遍：

1. 向量表是否在正确地址（读0x08处的word，看是不是指向swi_entry的跳转指令）。
2. SVC模式SP是否有效（在swi_entry入口打印SP值，确认指向栈空间内部）。
3. 压栈是否成功（打印压栈后SP的值，检查是否下降了56字节，r0-r12加LR共14个寄存器）。
4. 提取的SWI编号是否正确（打印r4或者r0，核对和SWI指令里的立即数一致）。
5. 返回指令是否用了movs（反汇编看返回处的编码，确认后缀）。
6. 返回后PC和CPSR是否都恢复（单步到用户程序断点，看PC和SPSR模式位）。

这6步走完，90%的SWI异常问题都能定位。剩下10%多半藏在内存初始化、MMU映射或者中断优先级这类环境问题里，那就得分而治之了。

7. 从SWI到完整系统调用的跃迁：你的下一步扩展思路

复现完上面这套示例，你已经掌握了ARM裸机环境下软件中断的核心机制。再往前走，有几个方向值得深入：

一是把SWI处理程序扩展成一个小型"系统服务层"。你可以定义几十个服务号，比如任务延时、任务创建、串口输出、内存分配，然后在SWI分发函数里统一调度。这样用户程序运行在USR模式，内核服务运行在SVC模式，一个极简的微内核雏形就出现了。

二是配合内存管理单元（MMU）做特权隔离。ARM的MMU允许你按页设置内存访问权限，USR模式访问不了标记为"仅特权可访问"的内存区域，而SVC模式可以。SWI就可以作为USR程序请求特权操作的唯一合规入口——USR任务想操作某个硬件寄存器，必须通过SWI把请求抛给SVC模式的内核代码。这个设计在真实操作系统中是日常操作。

三是把SWI和IRQ结合使用。当外设中断来临时，处理器进入IRQ模式处理中断，但如果IRQ处理程序需要唤醒一个用户态任务，就需要通过SWI切入SVC模式来完成任务切换。这样IRQ和SWI形成了完整的中断-系统调用闭环，很多RTOS的底层就是这种结构。

我在实际做某轻量级系统模拟时，最深的体会是：SWI机制的核心价值不在汇编指令本身，而在于它天然提供了一个"安全边界和内外部接口"。写SWI处理程序时多思考"用户程序应该拥有多少权限""哪些操作必须在特权模式下完成"，比死记硬背几条汇编指令重要得多。这套示例毕竟是第14课中段的进阶实验，主线任务是把异常机制吃透，后续再慢慢往任务调度和内存保护方向延伸，就不会再被"软件中断"这个概念卡住很久了。

最后送上一句调试心得：SWI程序出问题时别急着改代码，先把异常响应流程的时序在纸上过一遍。什么时候谁保存了什么、什么时候谁恢复了什么，理清了，问题基本就藏不住了。