BGE在MIPS中实施
我需要在MIPS中实现BGE指令：
bge $ r1，$ r2，despl（跳到pc + 4 + despl（＆lt;＆lt;＆lt;）如果rega ＆gt; = reg b）
我需要修改体系结构，但我不知道
I need to implement BGE instruction in MIPS:
BGE $r1,$r2,despl (jump to PC + 4 + despl(<<) if regA >= reg B)
I need to modify the architecture but I do not know how
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
的确，对于已签名的算术，从ALU出来的MSB表示答案的迹象 - 但仅在没有溢出时才有效。
从数学上讲，添加两个32位数字会产生一个33位的答案，没有溢出。＆nbsp;如果通过截断将33位的答案强加于32位（截断意味着丢失/丢弃33'rd的高位，并且没有其他合理的裁缝方法），那么可能会溢出。当溢出时，32位的答案将使标志与应有的符号相反，因此32位的答案只是垃圾 - 虽然可预测的垃圾，但它并不直接使用。
但是，
bge指令不需要在32位存储中捕获33位答案，但只能告诉我们第一个操作数是否为＆gt; =第二操作数。在所有情况下都可以做到这一点：我们永远不需要将33位的答案截断为32位，但是只需要一个答案作为输出（是/否），因此与减法不同，不需要截断。＆nbsp;因此，这是实现bge的最合适方法。相反，如果您通过使用ALU中的减法，然后查看32位结果的MSB来实现
bge，则无法检测到溢出，因此当输入时，此说明将给出错误的答案超出范围，例如将最大签名的int与最小签名的int。如果您选择检测溢出（可以通过将a＆amp; b alu输入的符号与alu输出的符号进行比较），那么您要做的是引起异常（例如add add）和sub做），或更正Alu之外的答案。要更清楚地看一下，让我们看一些示例，好像我们在8位中这样做：让我们看看大约1和-1，答案为1-（ - 1）= 2，这是正面的，所以我们知道1确实是＆gt; = -1。＆nbsp;使用较大的值63和-63：63-（-63）= 126，也为正，因此我们知道＆gt; = holds。＆nbsp;但是，如果我们做127和-127，我们将获得127 - （-127），即254，，但截断回8位，我们有-2（溢出），这将使我们相信-127是-127大于127 。
因为可以并且可以实施此指令以避免所有溢出问题，所以应该这样做！
如果是我，我将为
ge操作添加一个opalu值，而当它使alu简单地输出z = 1 if＆gt; =时，则Z = 0否则否则。＆nbsp;没有溢出，只有ALU中的一些自定义电路，还有一个额外的Opalu值来喂养Alu。但是，似乎您的教授正在寻找一个不同的答案，可能涉及现有的Alu减法（OPALU）。
为此，您将要求Opalu要求减法，然后将32位从Alu中拉出32位。您可以将其进行（当然是倒置的，因为MSB = 1含义小于小于Z = 1通常意味着要拿分支），然后在
bge的条件下将其插入Z线中，或者喂一秒钟与Unidad de Control一起，让它弄清楚是否使用Z与您的新线路。＆nbsp;该解决方案将涉及溢出问题，应该以某种方式缓解这些问题（但对于此任务不必要）。这两种潜在的方法并没有那么不同。＆nbsp;假设您对馈送给ALU的OPALU
GE值，ALU可以使用33位算术或32位算术进行溢出检测＆amp;更正。＆nbsp;减法方法也可以进行溢出检测＆amp;更正，主要区别是它将发生在Alu之外与Alu内部。就最终硬件而言，Alu内部的大门与Alu外部的门之间没有框边界，但是在这种框图的级别上，我会将这种复杂性放在Alu中。
It is true that for signed arithmetic, the MSB coming out of the ALU indicates the sign of the answer — but it is only valid when there is no overflow.
Mathematically speaking, adding two 32-bit numbers produces a 33-bit answer with no overflow. If that 33-bit answer is forced into 32 bits by truncation (truncation means loosing/discard the 33'rd high bit, and there's no other reasonable approach to such downsizing), then there is the possibility of overflow. When there is overflow, the 32-bit answer will have the sign reversed from what it should be, so the 32-bit answer is just junk — and while predictable junk, it is not directly usable.
However, a
bgeinstruction doesn't need to capture a 33-bit answer in 32 bits of storage, but only tell us if the first operand was >= the second operand. This can be done in all cases without overflow: we never need to truncate a 33-bit answer to 32 bits, but only need one bit of answer as output (yes/no) so unlike subtraction, no truncation is ever needed. So, this is the most appropriate way to implementbge.If, instead, you implement
bgeby using subtraction in the ALU and then looking at the MSB of a 32-bit result, that won't detect overflow, so this instruction will give wrong answers when the inputs are out of range, such as comparing max signed int to min signed int. If you choose to detect overflow (possible by comparing signs of the A & B ALU inputs with the sign of the ALU output), what you'd have to do is either cause an exception (likeaddandsubdo), or correct the answer outside the ALU.To see more clearly, let's look at some examples as if we were doing this in 8 bits: let's see about 1 and -1, where the answer is 1 - (-1) = 2 which is positive so we know that 1 is indeed >= -1. Using a larger values 63 and -63: 63 - (-63) = 126, also positive so we know >= holds. But if we do 127 and -127, we get 127 - (-127) which is 254, but truncated back to 8 bits we have -2 (which is overflow) and that would lead us to believe that -127 is larger than 127.
Because this instruction could and can be implemented so as to avoid all issues of overflow, well, it should be done that way!
If it was me, I would add an OPALU value for
geoperation to the ALU, and when that, have the ALU simply output Z=1 if >= holds on the operands and Z=0 otherwise. No overflow, just some custom circuitry in the ALU, and an extra OPALU value to feed the ALU.However, it seems that maybe your professor is looking for a different answer possibly involving reuse of existing ALU subtraction (OPALU) instead.
For that you would have OPALU call for subtraction, and then pull the 32 bit, the MSB out of the ALU. You can take that (inverted of course, since MSB=1 means less than and Z=1 usually means take the branch) and then mux that into the Z line on condition of
bge, or feed a second line to the UNIDAD DE CONTROL, and let it figure out whether to use Z vs. your new line. This solution would involve overflow problems, which ought to be mitigated in some way (but perhaps unnecessary for this assignment).These two potential approaches are not that different. Assuming you did the OPALU
gevalue fed to the ALU, the ALU could do either 33-bit arithmetic or 32-bit arithmetic with overflow detection & correction. The subtraction approach could also do overflow detection & correction, with the main difference being it would occur outside the ALU vs. inside the ALU.As far as the final hardware is concerned, there is no box boundary between the gates inside the ALU vs. outside the ALU, but at the level of this kind of block diagram, I would put this complexity inside the ALU.