栈管理
Stack Management

在经典 8051 架构中，SP（Stack Pointer）用于指示当前栈顶位置。 典型 PUSH 操作会先递增 SP，再将数据写入新栈顶位置； 因此，分析栈使用情况时，必须结合具体指令行为、内存区域和初始 SP 值。

HRTOS 的任务栈、内核使用栈和中断执行期间的栈需求，应根据实际内存布局分别分析。 如果多个执行路径共享某段栈空间，或中断期间仍会继续压栈，就必须把这些路径的叠加使用量纳入预算。

软件可以在任务切换、进入内核或其他指定检查点读取 SP， 并将其与该执行路径对应的有效栈范围进行比较。 但检查是否存在、在哪些路径执行，以及比较的是哪个栈区间， 都必须由实际实现确认。

读取当前 SP
确定需要检查的栈区域
依据该区域的边界定义执行检查

若检测到栈异常：
    调用 HRTOS 栈溢出处理路径

经典 8051 的栈通常随压栈操作向高地址方向增长， 但边界比较条件必须与实际栈区间、初始 SP、检查时机和具体实现一致。 HRTOS 的具体检查逻辑应以其真实实现为准，不宜用未经核实的变量名和比较式代替。

HRTOS 提供 os_slab_overflow() 栈溢出处理函数、 os_slab_overflow_register() 回调注册接口，以及 g_slab_overflow_hook 回调函数指针。 应用可以通过注册回调接入自定义处理逻辑，使异常处理与具体应用需求相结合。

void (*g_slab_overflow_hook)(void);

void os_slab_overflow(void)
{
    if (g_slab_overflow_hook)
    {
        g_slab_overflow_hook();
    }
    else
    {
        while (1);
    }
}

void os_slab_overflow_register(void (*hook)(void));

当回调已经注册时，os_slab_overflow() 会调用 g_slab_overflow_hook 指向的处理函数； 未注册回调时，上述实现进入循环停机路径。 os_slab_overflow_register() 用于注册处理回调。

栈需求不仅来自任务代码本身。函数调用层数、局部变量、编译器生成的临时数据、 中断现场保存以及嵌套执行路径，都可能影响峰值使用量。 对 8051 这类资源受限平台，容量预算应结合实际编译结果和执行路径进行。

栈需求分析应覆盖：

1. 任务调用路径的最大使用量
2. 内核调用与上下文切换的额外使用量
3. 中断入口、现场保存及嵌套中断
4. 编译器生成代码带来的栈使用
5. 必要的余量与异常处理路径

高水位（High-Water Mark）通常通过预填充标记并在运行后检查残留区域， 或通过其他监测方法估算历史最大栈使用量。 这种方法能否用于某个 HRTOS 栈区，取决于该区域是否可安全初始化和扫描， 以及监测代码是否覆盖全部相关执行路径。

在 8051 系统中，中断响应可能触发额外的现场保存和函数调用。 如果高优先级中断能够打断较低优先级中断，或者中断处理程序调用了内核 API， 就需要按实际控制流分析这些路径的叠加使用量。

对任务栈进行独立分配和边界检查，有助于组织资源并发现部分栈使用异常。 但在没有 MPU/MMU 的系统中，如果任务代码可以直接读写某段 RAM， 仅仅维护栈边界信息并不会自动禁止这类访问。

完成核对后，可以将确实存在的机制、对应配置和测试结论写入正式文档， 并明确区分静态分析结果、压力测试结果与理论保证。