5

I am designing a MIPS processor as my individual project, by now I met a very confused question. I just can not summarize when to use signed-extend and when to use zero-extend in MIPS.

I have searched lots of resources, mostly said:

1) ADDI, ADDIU are both use signed-extend.
2) ANDI, ORI, XORI both use zero-extend.

However, In those two instruction, I am start getting confused:

SLTIU/SLTI

In the Imagination's "MIPS Architecture for Programmers Volume II-A: The MIPS instruction set Manual" page 368 says: Picture 1

It clearly mentioned the 16-bit immediate is signed-extend.But I don't understand the following statement:

[0, 32767] or maximum [max_unsigned-32767, max_unsigned] end of the unsigned range.

and some other people say the 16-bit immediate is zero-extend, like this:

http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Mips/pseudojump.html

Well, can some one explain what exactly differences between the signed instruction and unsigned instruction in MIPS?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Shuaiyu Jiang
  • 239
  • 1
  • 3
  • 15
  • Hope some expert can give a full summarize about which instruction use signed-extend, and which instruction use zero-extend. – Shuaiyu Jiang Mar 26 '15 at 19:57

2 Answers2

4

I'm not sure if the two descriptions that you are showing behave exactly the same. They seem to be different implementations.

The implementation of Imagination's MIPS as it appears in their document is as follows (in SystemVerilog syntax, assuming GPR regsiters are 32 bits):

if ({1'b0 , GPR[rs]} < {1'b0 , sign_extend(immediate)} 
   GPR[rd] = 32'h00000001;
else
   GPR[rd] = 32'h00000000;

Notice that this is a 33 bit comparison where the 33rd bit is 0, hence an unsigned comparison.

Also, notice that:

sign_extend(immediate) returns: { {16{immediate[15]}}, immediate }

This means immediate is first treated as a signed number, i.e., a 15 bit value and the 16th bit is the sign. Therefore:

If immediate >=0, then sign_extend(immediate) is in [0,32767]. 

On the other hand if immediate is a negative number, we will have:

sign_extend(immediate)  = { {16{1'b1}}, 1'b1, immediate[15:0] }, which is in [32'hFFFFFFFF-32767, 32'hFFFFFFFF]

where 32'hFFFFFFFF is called max_unsigned.

Basically this instruction enables you to perform an unsigned comparison between GPR[rs] and an unsigned number either in [0,32767] or [32'hFFFFFFFF-32767, 32'hFFFFFFFF].

The second implementation performs an unsigned comparison between GPR[rs] and [0,65535].

EDIT:

Note that in SLTI and SLTIU the immediate value is sign extended but with different intentions. In SLTIU, the two numbers being compared are forced to be unsinged (by adding the 33rd bit). So the sign extension of immediate enabled a different range of comparison: the 32767 smallest and the 32767 largest unsigned values as opposed to just 0 to 65535. The sign extension was not done for the purposes of signed comparison as one might be confused.

In SLTI however, the sign extension of immediate is done for a different purpose: to compare a negative value to a positive value (signed comparison).

Ari
  • 7,251
  • 11
  • 40
  • 70
  • I am actually more prefer your answer, can I ask one more question. In imagination's implementation, whats the purpose of signed-extent the immediate and then treat it as unsigned number to compare with GPS[rs]? In my point of view, if you signed-extend a number then treat it as unsigned, the original value will be distorted. This is not make any sense to me :( – Shuaiyu Jiang Mar 27 '15 at 11:34
  • @ShuaiyuJiang: I already answered this in the comments. I added a summary of the comments in my answer above. – Ari Mar 27 '15 at 17:49
1

The docs imply that the instruction first sign-extends the 16-bit immediate, but then performs a 32-bit unsigned comparison. In verilog this should amount to:

if (gpr[rs] < { {16{imm[15]}}, imm })
  gpr[rt] = 1;
else
  gpr[rt] = 0;
Guy
  • 167
  • 9
  • Thanks for your answer Guy. What make me confused is, when you do the comparison between two binary, whether you treat unsigned or signed, the result should be same. For example 4'b1011, 4'b1001. When you treat as unsigned is 11 >> 9, when you treat signed is -5 >> -7, So what is the point to signed-extend the immediate? SLTI, and SLTIU both got the same result, which is first value bigger than second. – Shuaiyu Jiang Mar 26 '15 at 19:54
  • @ShuaiyuJiang: The point of sign extending immediate in the second implementation is to be able to compare signed values (which also includes comparison of a positive number with a negative number). In Imagination's implementation the sign extension gives you a different range: the 32767 smallest and the 32767 largest unsigned values as opposed to just 0 to 65535. – Ari Mar 26 '15 at 20:44
  • In your example both items are the same size, but this instruction is comparing a 32-bit quantity with a 16-bit quantity. If you take your example as 8'b00001011 and 4'b1001, then the answers are different. 8'h0B > 8'h09, but 8'h0B < 8'hF9. – Guy Mar 26 '15 at 20:50
  • @Ari, First, thanks for your answer, Let me ask the question in this way: The manual says SLTIU uses signed-extend, however SLTI also uses signed-extended (here is the copy SLTI description: Compare the contents of GPR rs and the 16-bit signed immediate as signed integers; record the Boolean result of the comparison in GPR rt. If GPR rs is less than immediate, the result is 1 (true); otherwise, it is 0 (false).) Since two instruction are both using signed-extent, then what is the difference of those two instruction? Hope this make sense :( – Shuaiyu Jiang Mar 26 '15 at 21:42
  • @ShuaiyuJiang: I think the U in SLTIU is confusing. In both SLTI and SLTIU the immediate value is sign extended but with different intensions. In SLTIU, the two numbers being compared are forced to be unsinged (by adding the 33 bit 0). So the sign extension of immediate just enabled a different range of comparison (it was not done for the purposes of signed comparison as one might be confused). In SLTI however, the sign extension of immediate was done for a different purpose: to compare a neg value to a pos value (signed comparison) – Ari Mar 26 '15 at 22:04