深入解析MPC7450异常处理：从同步异步分类到实战编程指南

1. 项目概述：从手册到实战，拆解MPC7450异常处理机制

如果你曾经在嵌入式系统或高性能计算领域，与PowerPC架构的处理器打过交道，那么“异常处理”这个词对你来说一定不陌生。它不像应用层编程那样直观，更像是处理器内部的一套“应急预案”系统。当程序执行遇到意外——比如访问了非法内存地址、收到了一个外部中断信号，或者更严重的硬件故障——处理器如何优雅地“刹车”，保存现场，并跳转到正确的“急救站”（异常处理程序），这套机制直接决定了系统的稳定性和可靠性。

今天，我们就以飞思卡尔（Freescale，现为NXP）经典的MPC7450 RISC微处理器为例，深入它的“应急预案”中心。这份来自其家族参考手册的异常处理章节，虽然信息密集，但更像是一份官方的“电路图”和“操作手册”。我的工作，就是结合我过去在PowerPC平台进行底层驱动和RTOS移植的经验，把这份“电路图”翻译成一份“实战指南”。我们不仅要看懂MPC7450如何将异常分为同步/异步、精确/非精确，更要弄明白它内部那套复杂的优先级仲裁逻辑：为什么系统复位（System Reset）能随时打断一切？为什么机器检查（Machine Check）的优先级比一个普通的外部中断要高得多？这些设计背后的考量，对于编写健壮的操作系统内核、设计高可靠的嵌入式固件，乃至进行极致的性能调优，都至关重要。无论你是正在学习计算机体系结构的学生，还是需要为MPC7450或类似平台编写异常处理程序的工程师，这篇文章都将带你越过手册的表格与定义，直抵其设计精髓与实战要点。

2. MPC7450异常处理的核心设计思路

要理解MPC7450的异常处理，我们不能孤立地看一个个异常向量，而必须从顶层理解其设计哲学。PowerPC架构定义了一个异常处理的基本框架，而MPC7450作为一款高性能的RISC处理器，在实现这个框架时，针对其超标量、乱序执行的流水线特性，做了许多精妙的权衡与增强。

2.1 异常的分类：理解处理器看待“意外”的维度

手册开篇就点明了异常的两个核心分类维度，这是理解后续所有机制的基础。

同步 vs. 异步：这个分类依据是异常事件是否由当前正在执行的指令流直接导致。

• 同步异常：由指令执行本身触发。例如，执行了一条非法指令（Program Exception）、进行了一次未对齐的内存访问（Alignment Exception）、或者执行了系统调用指令（sc）。这类异常是“可预测”的，因为它在指令执行的那个精确时刻必然发生，并且与指令有直接的因果关系。处理同步异常时，处理器需要精确地定位到是哪条指令惹的祸。
• 异步异常：由处理器外部或内部与当前指令流无关的事件触发。例如，外部设备拉低了中断引脚（External Interrupt）、定时器递减器归零（Decrementer）、或者芯片外部发出了复位信号（System Reset）。这类异常是“不可预测”的，它可以在任何时间点发生，与CPU正在执行什么指令无关。

精确 vs. 非精确：这个分类描述的是异常发生时，处理器状态的“可还原性”。

• 精确异常：当异常发生时，处理器能够确保所有在异常指令之前按程序顺序的指令都已执行完成，所有状态（寄存器、内存）都已更新；而异常指令本身及其之后的指令都像从未执行过一样。处理器保存的返回地址（SRR0）能明确指向导致异常的指令或下一条指令。这对于调试和错误恢复至关重要。绝大多数同步异常和部分异步异常（如使能后的外部中断）都是精确的。
• 非精确异常：异常发生时，处理器的状态可能处于一个“中间态”。可能异常指令之前的某些指令还没完成，或者之后的某些指令已经被部分执行。机器检查（Machine Check）在默认情况下就是一种非精确异常，因为严重的硬件错误（如内存奇偶校验错）可能已经破坏了处理器的正常流水线状态，使得精确恢复现场变得不可能。

MPC7450手册中的表4-1清晰地展示了这种分类。一个关键点是，MPC7450没有实现非精确的浮点异常。即使你将MSR寄存器的FE0/FE1位设置为非精确模式，处理器也会以精确模式来处理浮点异常。这是一个重要的实现细节，意味着在MPC7450上，浮点运算错误总是可以精确定位和恢复的。

2.2 优先级逻辑：处理器的“应急响应”决策树

当多个异常条件同时或几乎同时发生时，处理器先处理哪个？这就是优先级要解决的问题。MPC7450的优先级规则，体现了嵌入式系统设计中对“严重性”和“可延迟性”的权衡。

手册4.2节和表4-3详细列出了优先级。我们可以将其归纳为一个更易理解的层次模型：

1. 最高优先级：不可屏蔽、不可恢复的异步异常。这是系统的“紧急制动”按钮。

   • 系统复位（HRESET）：最高优先级。无论是上电复位还是硬复位信号，一旦生效，处理器立即停止一切活动，无条件跳转到复位向量。这是一种“毁灭性”的异常，不保存现场，因为系统需要从头开始。
   • 机器检查（Machine Check）：次高优先级。当检测到严重的、不可纠正的硬件错误（如L2缓存ECC多比特错误、总线奇偶错误）时触发。如果MSR[ME]=1，处理器会尝试进入异常处理程序；如果MSR[ME]=0，则直接进入检查停止（Checkstop）状态——处理器挂起。其优先级仅次于硬复位。

2. 高优先级：可屏蔽、但需立即关注的异步异常。这类异常需要系统尽快响应，但允许处理器先到达一个“安全点”。

   • 系统复位（SRESET）：软复位。它要求处理器先进入一个“可恢复状态”（即完成队列为空，所有已完成的存储操作已提交），然后再跳转到处理程序。这比硬复位“温和”，旨在允许系统进行有序重启。
   • 系统管理中断（SMI）与外部中断（INT）等：这些是常见的可屏蔽中断。它们的处理要等到当前正在执行的指令完成，并且处理器处于可恢复状态。如果这条指令本身又触发了同步异常，那么同步异常会优先被处理。

3. 程序顺序优先级：同步异常。所有由指令触发的异常，严格遵循程序顺序。即使流水线中后面的指令先执行完并触发了异常，也必须等待它之前的所有指令都完成（或发生异常）后，它的异常才会被处理。这保证了异常行为的确定性，对调试和程序逻辑正确性至关重要。

4. 最低优先级：可延迟的异步异常与后指令异常。例如性能监控异常和跟踪异常。它们可以被更高优先级的异常无限期推迟。

一个生动的类比：想象一个正在处理多项任务的办公室（处理器）。

• 硬复位：大楼火警突然响起，所有人必须立即撤离，不管手头工作做到哪一步。
• 机器检查：发现大楼承重结构出现裂缝，必须立即上报并疏散，但可能还有几秒钟时间保存最关键的文件。
• 软复位：经理要求重启整个项目，但需要大家先把手头当前这阶段的工作收尾，提交所有报告。
• 外部中断：快递员打电话让你下楼取件，但你需要先写完正在写的这个句子。
• 同步异常（如非法指令）：你正在写的句子中出现了语法错误，你必须停下来纠正这个错误，才能继续往下写。

这种优先级设计，确保了最紧急的、关乎系统存亡的事件能得到最及时的响应，同时保证了程序执行逻辑的完整性。

2.3 关键寄存器：现场保存与恢复的基石

异常处理的核心在于现场保存与恢复。MPC7450使用两个关键的特殊寄存器对（SRR0和SRR1）来完成这项工作。

• SRR0（机器状态保存/恢复寄存器0）：用于保存返回地址。对于大多数异常，它保存的是导致异常的指令地址（例如，对于DSI、Alignment异常）。但对于某些不中断特定指令的异常（如System Call、Trace），它保存的是下一条指令的地址。这是异常处理程序执行完毕后，通过rfi指令能够正确返回的关键。

• SRR1（机器状态保存/恢复寄存器1）：用于保存机器状态。主要包括发生异常时的MSR寄存器关键位，以及异常特定的状态信息。例如，对于DSI异常，SRR1的低位会包含DSISR寄存器的内容，从而告诉处理程序具体是什么原因导致了数据存储中断（是保护违规、对齐错误还是TLB缺失？）。

而MSR（机器状态寄存器）则是处理器的“控制面板”。在异常发生时，MSR的许多位会被自动修改，以切换到异常处理模式：

• MSR[PR]位被清零，处理器从用户模式切换到超级用户模式，从而可以执行特权指令。
• MSR[EE]位被清零，屏蔽外部中断，防止在异常处理过程中被嵌套中断打断（除非处理程序显式重新打开）。
• MSR[IR]和MSR[DR]位被清零，关闭地址翻译。这意味着异常处理程序最初的几条指令必须位于物理地址空间，或者通过直接映射的存储区域来访问。这是一个非常重要的安全机制，防止在内存管理单元（MMU）处于不稳定状态时进行地址翻译。
• MSR[RI]位（可恢复中断指示位）的状态决定了异常是否可恢复。在异常处理程序的开头，通常需要尽快设置此位，以允许在异常处理期间发生更高优先级的异常（如机器检查）时，系统仍有可能恢复。

理解这三个寄存器在异常发生瞬间的互动，是编写正确异常处理程序的第一步。手册中的表4-6清晰地列出了每种异常发生后，MSR各个位的具体状态，这是异常处理程序进行环境判断的重要依据。

3. 核心异常机制深度解析与实战要点

掌握了设计思路，我们深入到几个最关键、也最容易在实战中出问题的异常机制中。手册提供了定义，而我将结合实践，告诉你这些定义背后的“坑”和“技巧”。

3.1 系统复位与机器检查：生死攸关的顶层设计

系统复位异常是优先级最高的异常，它分为两种，其区别远不止于优先级：

• 硬复位：由HRESET信号触发。这是最彻底的重置。处理器不尝试达到任何可恢复状态，立即跳转到向量0xFFF00100（假设MSR[IP]=1）。所有内部状态（除了少数由硬件决定的初始状态）都会丢失。它用于上电初始化或系统完全崩溃后的恢复。实战要点：硬件设计必须保证HRESET信号在上电期间满足最小脉宽要求。如果HRESET信号在处理器运行过程中被意外毛刺触发，将导致系统毫无征兆地重启，且无法追踪原因。在可靠性要求高的系统中，需要对复位信号进行良好的去抖和监控。

• 软复位：由SRESET信号触发。处理器会尝试进入一个“可恢复状态”——等待完成队列清空，已完成的存储操作提交到内存。然后保存状态到SRR0/SRR1，跳转到向量0x00000100或0xFFF00100（取决于MSR[IP]）。关键区别：软复位是可屏蔽、可恢复的异步异常。如果软复位发生时，处理器正处于跟踪模式（MSR[SE]或[BE]=1），则该异常会被标记为不可恢复（SRR1[RI]被清零）。这是因为单步调试状态非常脆弱，难以在复位后恢复。

机器检查异常是硬件错误的最后一道软件防线。其触发条件众多（见表4-2），从总线错误到各级缓存ECC错误。它的处理策略由MSR[ME]位决定：

• MSR[ME] = 1：启用机器检查异常。当错误发生时，处理器尝试进入异常处理程序。处理程序可以通过检查MSSSR0等状态寄存器来诊断错误根源（是L2数据错误还是地址奇偶错？）。
• MSR[ME] = 0：禁用机器检查异常。当错误发生时，处理器直接进入检查停止状态——时钟停止，处理器挂起，等待外部干预。这在某些对安全性要求极高的场景中使用，确保任何无法处理的硬件错误都导致系统立即停止，而不是带着错误继续运行。

实战心得：

1. 系统启动代码：必须为硬复位和软复位分别设计处理流程。硬复位处理程序负责最底层的硬件初始化（时钟、内存控制器、基本IO）。软复位处理程序则可以更“温和”，可能只是重新初始化软件状态，然后恢复执行，类似于一个“看门狗”复位后的处理。
2. 机器检查处理程序：绝不能简单地在处理程序里打印一条错误信息就rfi返回。因为触发机器检查的错误可能已经破坏了内存或缓存数据，系统状态可能已不可信。常见的做法是：a) 尽可能将关键错误信息记录到非易失性存储中；b) 尝试进行局部恢复（如清除错误的缓存行）；c) 如果错误严重，应触发系统软复位或硬复位。永远不要假设从机器检查异常返回后程序还能正常运行。
3. RI位的管理：在异常处理程序最开始的汇编代码中，在保存必要的寄存器后，应立即执行mfmsr rX; ori rX, rX, MSR_RI; mtmsr rX（或等效指令）来设置MSR[RI]位。这标志着“我已保存了足够的状态，现在可以允许更高优先级的异常（如另一个机器检查）发生了”。在通过rfi返回之前，再清除MSR[RI]位。

3.2 同步异常：程序错误的精确捕获

DSI和ISI异常是两种最常见的同步异常，分别对应数据访问和指令访问问题。

• DSI异常：当加载、存储指令遇到问题时触发。原因极其多样，手册表4-3的优先级列表里，从优先级7到17都有DSI的身影。常见原因包括：

  • TLB缺失：虚拟地址没有对应的物理页表项。如果启用了软件页表遍历（HID0[STEN]=1），则会触发DTLB缺失异常，由操作系统负责查页表并填充TLB。
  • 保护违规：试图写入只读页面，或从用户模式访问超级用户页面。
  • 对齐错误：访问非对齐地址（例如，lwz指令访问一个不是4字节对齐的地址）。
  • 直接存储访问：访问了标记为直接存储（SR[T]=1）的段。

• ISI异常：当处理器取指遇到问题时触发。主要原因包括：

  • 页面不存在（页错误）。
  • 试图从不可执行的内存页取指。
  • 保护违规。

为什么需要这么复杂的优先级？考虑一个场景：一条存储指令的目标地址既没有TLB映射（DTLB缺失），又处于一个只读页面（保护违规）。这两个条件可能同时被检测到。MPC7450定义了优先级：保护违规（优先级15）高于DTLB缺失（优先级14）。因此，处理器会报告一个DSI异常，并在DSISR寄存器中同时设置保护违规位和TLB缺失位。异��处理程序需要检查DSISR来判断根本原因。优先级规则避免了歧义，确保了异常原因报告的一致性。

实战中的坑：

1. 对齐错误：PowerPC架构对许多指令有严格的对齐要求。在C语言中，不当的指针强制转换或结构体打包（#pragma pack）很容易导致非对齐访问，从而触发Alignment异常。在编写对性能要求极高的代码或驱动程序时，必须确保数据结构的对齐符合架构要求。
2. TLB缺失处理：这是操作系统内存管理的核心。DSI/ITLB缺失异常处理程序（通常称为“页错误处理程序”）必须非常高效。它需要：
   • 从引发异常的地址（保存在SRR0或相关寄存器中）解析出虚拟地址。
   • 遍历进程的页表结构（在PowerPC上通常是两级页表）。
   • 找到或分配一个物理页帧，建立映射。
   • 填充对应的TLB条目（使用tlbwe指令）。
   • 然后返回，让导致异常的指令重新执行。 这个过程如果太慢，会严重影响系统性能。因此，内核中TLB缺失处理路径通常是用高度优化的汇编语言编写的。

3.3 异步可屏蔽中断：系统响应性的关键

外部中断、递减器中断等，是操作系统实现多任务、定时调度的基础。它们的共同点是受MSR[EE]位控制。

• 使能与屏蔽：MSR[EE]=1时，这些中断才可能被处理器响应。任何异常（包括中断本身）发生时，硬件会自动清除MSR[EE]，进入关中断状态。这给了异常处理程序一个安全的执行环境，防止被嵌套中断打断。处理程序如果需要支持中断嵌套，必须手动重新置位MSR[EE]。
• 中断延迟：中断不是即时响应的。从中断信号有效，到处理器真正跳转到异常处理程序的第一条指令，中间存在延迟。这个延迟包括：
  1. 同步化时间：外部异步信号需要被处理器内部时钟同步。
  2. 流水线排空时间：处理器需要等待当前正在执行的指令到达一个“可中断点”（对于精确中断，就是完成）。
  3. 更高优先级异常处理时间：如果此时发生了更高优先级的异常（如同步异常或机器检查），中断必须等待。
  4. 硬件上下文保存时间：保存SRR0、SRR1和修改MSR。 在实时系统中，必须计算最坏情况下的中断延迟，以确保能满足实时性要求。

中断处理程序编写要点：

1. 现场保存：硬件只自动保存了PC和MSR到SRR0/SRR1。所有通用寄存器、浮点寄存器、向量寄存器（如果使用AltiVec）都需要由软件在中断处理程序开头保存到栈中。
2. 中断源识别：MPC7450通常与一个外部中断控制器（如MPIC）配合工作。处理器收到外部中断后，需要读取中断控制器的寄存器来获取中断向量号，从而确定是哪个设备产生的中断。
3. 中断结束：在处理完设备中断后，必须向中断控制器发送“中断结束”信号。否则，该中断线会一直保持有效，导致无法接收新的中断。
4. 嵌套中断：如果需要支持中断嵌套，必须在保存完关键现场后，尽早执行wrtee 1（或等效操作）重新打开中断。但必须注意栈空间的管理，防止嵌套过深导致栈溢出。

4. 异常处理程序的编写与调试实战

理解了理论，最终要落到代码上。编写MPC7450的异常处理程序，尤其是内核级别的异常向量表和处理程序，是一项细致且挑战性的工作。

4.1 异常向量表的建立

异常向量表是一系列代码的起始地址，每个异常都有固定的偏移量（如表4-2所示）。向量基址由MSR[IP]位决定（0x00000000 或 0xFFF00000）。系统上电后，MSR[IP]通常处于不确定状态，但硬件复位会强制从0xFFF00100开始执行。因此，在0xFFF00000和0x00000000这两个物理地址区域，都需要部署有效的异常处理代码或跳转指令。

一个典型的向量表初始化汇编代码片段如下：

/* 假设代码链接在0x00000000附近 */ .section .vectors, "ax" _vector_start: b _hard_reset_handler /* 0x00100 - 系统复位 (HRESET) */ . = _vector_start + 0x200 b _machine_check_handler /* 0x00200 - 机器检查 */ . = _vector_start + 0x300 b _dsi_handler /* 0x00300 - DSI */ . = _vector_start + 0x400 b _isi_handler /* 0x00400 - ISI */ . = _vector_start + 0x500 b _external_int_handler /* 0x00500 - 外部中断 */ /* ... 以此类推，填充其他向量 ... */ _hard_reset_handler: /* 1. 设置MSR[IP]为0，将异常向量重定位到0x00000000 */ lis r3, MSR_IP@h ori r3, r3, MSR_IP@l mtmsr r3 isync /* 2. 初始化关键寄存器，如SP、BAT、TLB等 */ /* 3. 清零BSS段 */ /* 4. 设置栈指针 */ /* 5. 跳转到C语言入口 main() */

注意：b指令是相对跳转，范围有限。如果处理程序代码距离向量表较远，可能需要使用lis/ori/mtctr/bctr的组合进行绝对地址跳转。

4.2 通用异常处理框架

尽管每个异常的原因不同，但其处理流程有共通之处。下面以一个DSI异常处理程序的汇编骨架为例：

_dsi_handler: /* 第一步：保存现场 */ stwu r1, -EXCEPTION_FRAME_SIZE(r1) /* 开辟栈帧 */ stw r0, FRAME_R0(r1) /* 保存GPR0 */ mfcr r0 stw r0, FRAME_CR(r1) /* 保存CR */ stw r2, FRAME_R2(r1) /* 保存GPR2 */ /* ... 保存所有需要使用的寄存器 r3-r31 ... */ mfsrr0 r0 stw r0, FRAME_SRR0(r1) /* 保存SRR0 */ mfsrr1 r0 stw r0, FRAME_SRR1(r1) /* 保存SRR1 */ /* 第二步：设置MSR[RI]，允许更高优先级异常 */ mfmsr r0 ori r0, r0, MSR_RI mtmsr r0 isync /* 第三步：调用C语言处理函数 */ addi r3, r1, 0 /* 将栈帧指针作为参数 */ bl handle_dsi_exception /* 第四步：恢复现场 */ lwz r0, FRAME_SRR1(r1) mtsrr1 r0 lwz r0, FRAME_SRR0(r1) mtsrr0 r0 /* ... 恢复所有寄存器 ... */ lwz r0, FRAME_CR(r1) mtcr r0 lwz r0, FRAME_R0(r1) lwz r2, FRAME_R2(r1) /* ... */ addi r1, r1, EXCEPTION_FRAME_SIZE /* 释放栈帧 */ /* 第五步：返回 */ rfi

在C函数handle_dsi_exception中，我们可以从栈帧里读取保存的SRR0、SRR1，以及通过mfdar指令读取DAR寄存器（存放导致异常的地址），通过mfdsisr读取DSISR寄存器来获取详细错误原因，然后进行相应的处理（如页分配、发送SIGSEGV信号等）。

4.3 调试技巧与常见问题排查

在开发底层异常处理代码时，调试往往非常困难，因为一旦出错，系统可能直接挂起或复位。以下是一些实用的技巧：

1. 利用LED或串口进行“printf调试”：在异常处理程序的最开始，如果硬件条件允许，立即通过GPIO点亮一个特定的LED，或通过UART发送一个特定的字符（如‘D’代表DSI，‘I’代表ISI）。这能帮你快速定位是哪个异常触发了。
2. 保存关键上下文到固定内存：在异常处理程序中，将SRR0、SRR1、DAR、DSISR等关键寄存器的值保存到一个预先定义的、不会被覆盖的内存区域（例如，片内SRAM的某个固定地址）。即使后续处理程序崩溃导致系统复位，你也可以在复位后通过调试器查看这块内存，了解“案发现场”的情况。
3. 处理TLB缺失的递归问题：这是编写页错误处理程序时的一个经典陷阱。如果TLB缺失处理程序本身发生了页错误（例如，处理程序代码或数据所在的页面被换出），会导致无限递归。解决方法通常是：a) ��TLB缺失处理程序的代码和关键数据结构锁定在内存中（通过TLB属性设置WIMG位）；b) 在处理程序中非常小心地访问内存，确保使用的栈和全局数据是常驻物理内存的。
4. 注意rfi指令的副作用：rfi不仅恢复MSR和跳转，它还是一个上下文同步指令。这意味着在rfi之前的所有存储操作，必须对返回后的上下文可见。在异常处理程序中，如果你修改了页表或TLB，必须在rfi之前使用tlbsync和isync指令来确保这些更改对后续指令生效。
5. 性能监控异常的使用：MPC7450的性能监控单元可以配置为在计数器溢出时触发异常。这为性能剖析提供了强大的硬件支持。你可以用它来采样程序计数器，分析热点函数。但要注意，性能监控异常是异步的、可屏蔽的，其优先级较低，处理程序必须非常高效，避免引入过大的性能开销。

5. 从理论到实践：一个综合案例分析与避坑指南

让我们通过一个假设的、但综合了多个要点的案例，来串联起所有知识。

场景：在一个运行自制RTOS的MPC7450系统中，某个任务正在执行一段计算密集的AltiVec向量运算。此时，外部定时器（递减器）中断到期，同时，该任务访问了一个尚未映射的虚拟地址（触发DTLB缺失）。此外，由于内存硬件故障，总线上同时产生了一个奇偶校验错误（可能触发机器检查）。

处理流程推演：

1. 事件发生：三个异常条件几乎同时出现：DTLB缺失（同步精确）、递减器中断（异步可屏蔽）、总线错误（异步非屏蔽-机器检查）。

2. 优先级仲裁：

   • 机器检查优先级最高（仅次于硬复位）。如果MSR[ME]=1，处理器会立即尝试处理机器检查。它会暂停当前所有活动，尝试进入可恢复状态。由于机器检查可能是非精确的，当前向量运算的现场可能部分丢失。
   • 如果机器检查被成功处理或未发生，接下来是DTLB缺失异常。因为它是同步异常，且由一条明确的加载/存储指令触发，处理器会等待该指令之前的所有指令完成（包括可能正在流水线中的其他向量指令），然后处理DTLB缺失。
   • 最后才是递减器中断。它必须等待DTLB缺失异常处理完毕，并且处理器从那个异常返回后，才会被响应。

3. 潜在问题与规避：

   • 中断延迟过长：如果DTLB缺失处理程序（需要遍历页表，可能很慢）执行时间很长，递减器中断的响应时间就会变得不可接受，影响系统实时性。
     • 规避：优化TLB缺失处理路径。使用软件填充TLB（STEN）通常比硬件遍历慢，但对于实时系统，可以考虑使用更大的TLB或锁定关键页面的TLB条目来减少缺失率。或者，将实时任务的关键代码和数据锁定在物理内存中，避免页错误。
   • 机器检查导致任务状态丢失：如果总线错误发生在向量寄存器保存到内存之前，整个任务上下文可能损坏。
     • 规避：对于关键任务，除了硬件自动保存的上下文，软件应定期将任务状态检查点保存到受ECC保护的内存区域。机器检查处理程序应尝试从检查点恢复，而不是盲目地继续执行。
   • 嵌套异常处理复杂度：在DTLB缺失处理程序中，如果MSR[EE]被重新打开，递减器中断可能会嵌套进来。这要求异常处理栈足够大，且所有处理程序都是可重入的。
     • 规避：在关键的、非抢占的内核路径（如TLB缺失处理）中，保持中断关闭。或者，使用专门的中断栈来处理嵌套中断。

给开发者的最终建议：

1. 从简单开始：首先实现最基础的异常处理程序，比如将未处理异常的信息打印到串口，然后进入死循环。确保异常向量表设置正确，能捕获到异常。
2. 逐步完善：先实现外部中断和系统调用，让任务可以调度和通信。然后实现DSI/ISI处理，添加简单的虚拟内存管理。最后再考虑机器检查、性能监控等高级特性。
3. 充分测试：故意制造异常来测试你的处理程序。例如，在C代码中访问一个空指针（触发DSI），执行非法指令（触发Program），或配置一个不存在的内存映射访问（触发总线错误/机器检查）。
4. 参考成熟代码：学习Linux或VxWorks等开源或商业RTOS在PowerPC架构上的异常处理实现，尤其是它们的上下文切换、中断嵌套处理和错误恢复逻辑，这些都是经过千锤百炼的宝贵经验。

MPC7450的异常处理机制，是PowerPC架构稳健性的一个缩影。它通过精细的分类、严格的优先级和完备的状态保存，为操作系统构建了一个坚固的底层安全网。理解它，不仅是为了解决那些令人头疼的硬件异常，更是为了能够设计出更高效、更可靠的嵌入式系统。当你下次再看到“Machine Check”或“DSI”这样的错误时，希望你能透过现象，直击其背后的处理器运行机理，并自信地拿出解决方案。