MIPS汇编、寄存器遍历?
您好,提前致谢,
我的问题是是否可以遍历寄存器,例如在一个寄存器中放置一个指针($t0)并将指针移动到另一个寄存器($t1)。
我真正想做的是在一个循环中读取 8 个整数并将它们存储在 ($s0-$s7) 中
Hello and thanks in advance,
My question is if it is possible to go through registers like having a pointer in one ($t0) and moving the pointer to another one ($t1).
What i actually want to do is in one loop read 8 integers and store them in ($s0-$s7)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以尝试更改 sw 操作码中的位以指向增加的寄存器,但这是一个糟糕的主意。我认为你最好的选择是自己编写展开的循环:
重新安排事物以最大限度地减少停顿,但这与你所能得到的一样好。
You could try changing the bits in the
sw
opcode to point to increasing registers, but that's a terrible idea. I think your best bet is to just write your unrolled loop yourself:Rearrange things to minimize stalls, but that's about as good as you're going to get.
您想让寄存器编号可变吗?我对MIPS一无所知,但我怀疑这是可能的。我所知道的唯一具有类似功能的 ISA 是 SPARC(寄存器窗口,不能用于您想要的用途)和 IA64(“旋转寄存器”,可以用于您想要的用途,但只能用于浮点)。
You want to have a register number be variable? I don't know MIPS inside and out, but I doubt it's possible. The only ISAs I know of that have anything like that are SPARC (register windows, not usable for what you want) and IA64 ("rotating registers", could be used for what you want, but only with floating point).
我不知道现有的 MIPS 架构支持通过寄存器的内容引用寄存器,这将允许您建议的类型,例如:
尽管在我看来,无论如何这都不是一个好主意,但对于一些人来说原因。首先,无论如何,您要处理的寄存器数量非常少,因此无论如何,循环上都有一个小的上限,这使得直接方法的灵活性并没有降低多少。
更重要的是,这样的循环效率极低。它将为每次迭代进行初始化、递增、执行
移动
和(至少)分支检查。即使不考虑分支停顿,这也至少比简单的慢 3 倍:I'm not aware of an existing MIPS architecture that supports referencing a register by the contents of a register, which would allow the type of thing you suggest, like:
Although in any case it's not a good idea in my opinion, for a few reasons. Firstly, you're dealing with a very small number of registers anyway, so there is a small upper bound on the loop in any case, making the direct approach not much less flexible.
More importantly, a loop like that would be horribly inefficient. It would initialise, increment, perform a
move
and a branch check (at least) for every iteration. Even without taking branch stalls into account this is at least 3x slower than simply: