Agfdhyk

Sorry about this really stupid question. But I have been reading my textbook the entire day and its getting really confusing.

I would like to clarify some syntax related questions with MIPS I-type instructions.

I understand that instructions like

addi $21, $22, -50

are possible and the immediate value is interpreted as a decimal (2s complement).

But can I write addi $21, $22, 0xF1DF? such that the immediate value is in hexadecimal?

That brings me to my next question with andi $10, $11, 0xFFFF and ori $8, $0, 0x0FA5. I understand that these 2 codes are correct.

But can I write andi $10, $11, 120 and ori $8, $0, -16such that the immediate values are in decimal? If it is possible, does it interpret 120 as hexadecimal or does it convert decimal 120 to hexadecimal which equates to 78 in hexadecimal.

I am very confused.

You can express immediates in both base 10 or hexadecimal. To express an hedacimal value you need to use the 0x prefix before the numeral (e.g. 0x10, which is 16 in base 10). If you don't use the prefix 0x before the numeral, the assembler will assume the numeral is in decimal notation.

Using your example, if you want to add 120 (base 10) you should encode the instruction like so addi $10, $11, 120 or like so addi $10, $11, 0x78. The assembler will produce the same binary instruction 0x20000000. You can try it for yourself here with this online assembler.

MIPS addi / addiu sign-extend the 16-bit immediate to 32 bits (2's complement):

Values from -32768 (0xFFFF8000) to 32767 (0x00007FFFF) are encodeable.

MIPS andi / ori zero-extend the 16-bit immediate to 32 bits,

Values from 0 (0x00000000) to 65535 (0x0000FFFFF) are encodeable.

So no, you can't write ori $8, $0, -16, you'll have to use addiu.

(Or inefficiently, lui $8, 0xFFFF / ori $8, $8, 0xfff0).

Usually you can leave this decision-making to the assembler, and let it choose how to create a constant with li $8, 0xFFFFFFF0 or li $8, -16. Those will assemble identically.

But if you're not just creating a constant, you do have to know what's encodeable. For example, on the Godbolt compiler explorer, gcc5.4 compiles these functions as follows for MIPS:

unsigned mask(unsigned a) {

    return a & -16UL;

}



      # not encodeable as an immediate for andi

    li      $2,-16                  # 0xfffffffffffffff0

    j       $31

    and     $2,$4,$2







unsigned mask_positive(unsigned a) {

    return a & 0xFF;

}



    j       $31

    andi    $2,$4,0x00ff   # encodeable as an immediate

The representation in the source is totally irrelevant; hex and decimal are 2 different serialization formats for numbers. 0x10 and 16 are literally the same thing. In the MIPS machine code, they're stored in 16-bit binary, not hex or decimal

-32768 and 0xFFFF8000 are also the same thing (in 32-bit 2's complement). It's also 0x8000 in 16-bit 2's complement. And it's not representable as a 16-bit unsigned number, because 0x8000 zero-extends to 0x00008000 (+32768).