【问题标题】:Sparc V8 RTOS QuerySparc V8 RTOS 查询
【发布时间】:2017-04-07 14:18:16
【问题描述】:

在 Sparc V8 架构中,我们有一些 N 个寄存器窗口。通常,上下文切换期间的 RTOS 会推送和弹出寄存器。是否有可能(或已经完成)将这些注册窗口中的每一个用作线程之一。这将使切换到下一个线程与移动寄存器窗口以及推送和弹出 PSR 一样好!从而节省上下文切换时间并实现更快的上下文切换频率。

【问题讨论】:

  • 一个实现可能有 3 到 32 个注册窗口,这会限制使用这种方法的任务数量。 V8 Arch 手册描述了上下文切换;我希望实现遵循这一点。 V9 Arch 手册提到了设计上的改进,以实现更快的上下文切换。
  • 我知道你的观点。我的问题是,这是否可能。如果是它是否会允许超快速的上下文切换。
  • 不要忘记相邻寄存器窗口之间存在重叠。一个窗口的输出寄存器成为下一个窗口的输入。因此,即使您为每个任务指定一个寄存器窗口,您仍然需要在每个上下文切换时保存/恢复输入寄存器(当然还有全局变量)。
  • 另外请记住,窗口化寄存器保存/恢复在上下文切换中可能不会花费大量时间。你有陷阱进入内核并返回,硬件上下文寄存器的变化等等。
  • 如果你想减少寄存器保存/恢复开销,也许可以考虑一种方法来提醒系统哪些寄存器正在实际使用中。我在现有方案中看到的问题之一是我们有很多寄存器,而且它们都在不断地被“推送”和“弹出”。但是,大多数这种活动都是浪费时间,因为在任何给定时刻只有少数寄存器是“脏的”。例如,查看任何函数的反汇编;即使是相当复杂的函数也不会使用很多寄存器。但是上下文切换或寄存器溢出仍然可以保存所有

标签: rtos sparc


【解决方案1】:

也许,这取决于您所说的线程以及线程数。

寄存器窗口是围绕函数调用和返回的概念构建的,通过定义明确的操作在硬件和软件陷阱中实现这一点。如果您的线程只是以循环方式调用的函数等......那么是的,它们将以这种方式切换,就像从您的“线程”调用的任何其他函数一样。也就是说,一旦您的功能超过了注册窗口的数量,它们就会开始在注册文件中进行分页。

从操作系统和用户代码的角度来看...您无法控制进入和离开注册窗口时会发生什么,因为据我所知,这可能是在固件中作为陷阱实现的。如果你改变它的工作方式,你将不再运行 Sparc,因为它在规范中定义了它的作用。

Register 窗口的重点一直是快速上下文切换。但 Sparc 硬件的其他方面(例如 TLB)可能会妨碍...在具有平坦地址空间的 Sparc MCU 的上下文中。 ..那么是的,它会非常快。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-04-28
    • 1970-01-01
    • 2011-08-24
    • 1970-01-01
    • 2019-11-25
    • 2022-07-20
    • 2022-07-18
    • 2012-03-08
    相关资源
    最近更新 更多