4

I have translate this code so far and what I'm not understanding is how to figure out (calculate)the amount of 16-bit immediate address.

0x2237FFF1

To binary

0010 0010 0011 0111 1111 1111 1111 0001

Now I'm reading the opcode (001000) and know that it is I-type and addiinstruction

Now I'm grouping the binary into I-type instruction

   op     rs    rt       imm
 001000 10001 10111 1111111111110001
   8      17    23        ?

Looking at the MIPS reference sheet and found out that the instruction must be

 addi $s7,$s1,????

I'm stack here and don't know the method how to determine the 16-bit immediate address in genral.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Adam
  • 856
  • 2
  • 9
  • 18
  • 1
    You have already found the immediate, it's `1111111111110001`. Can you convert from binary? Note that immediates are sign extended, so that's actually `-15` in decimal. – Jester Feb 08 '17 at 11:56
  • 1
    *"immediate address"* sounds suspicious to me, usually in Assembly it's either *immediate* (value directly encoded in the instruction, in your case `0xFFF1` => sign extended to 32b = `0xFFFFFFF1` = `-15`), or *address* in one of possible addressing modes, the one mode resembling immediate is `pc + offset`, in such case it would be address `pc - 15`. I'm writing this as general information, I didn't check particular opcode in MIPS reference guide, so I don't know if such address mode exists on MIPS, but I guess you have the immediate variant anyway. – Ped7g Feb 08 '17 at 12:28
  • 1
    Or even absolute addressing would resemble immediate encoding even more, like when instruction contains the absolute address of memory to work with, but that's very unlikely on RISC-like processors, as usually they have fixed size instructions of "word" size, and absolute address would usually require whole "word" to define it. So if any addressing is involved, then it will be 99% some relative one, using the value as sign-extended offset. – Ped7g Feb 08 '17 at 12:31
  • @Jester Thanks for the answer i think i have some issue converting signed numbers i will read about it, i still don't understand how you convert it to -15. – Adam Feb 08 '17 at 14:01
  • @Ped7g Thanks for the explanation. – Adam Feb 08 '17 at 14:06
  • 1
    Read about [two's complement on wikipedia](https://en.wikipedia.org/wiki/Two's_complement). You duplicate the most significant bit (bit #15) to all the top 16 bits, then convert to decimal. If the duplicated bit (the sign bit) was set your number is negative so subtract `2^32`. `0xFFF1` extended is `0xFFFFFFF1=4294967281`, now subtract `2^32=4294967296` and you get `-15`. – Jester Feb 08 '17 at 14:12

1 Answers1

3

You can start by letting the tools do it for you

.word 0x2237FFF1

then assemble and disassemble.

mips-elf-as so.s -o so.o
mips-elf-objdump -D so.o

so.o:     file format elf32-bigmips

Disassembly of section .text:

00000000 <.text>:
   0:   2237fff1    addi    s7,s1,-15

and then do what you were doing, immediates in general are either signed or not (in general within and across instruction sets) in this case it is going to be either 0x0000FFF1 or 0xFFFFFFF1 you can use your calculator or just look at the bits you expanded, twos complement negate invert and add one so your number becomes a binary 1110+1 or 1111 which is 15 so 0xFFFFFFF1 is the signed number -15. Or unsigned 0xFFFFFFF1 whatever that is, a few billion.

EDIT

Unhappy to see my binutils using abi register names, so fixed that:

Disassembly of section .text:

00000000 <.text>:
   0:   2237fff1    addi    $23,$17,-15
old_timer
  • 69,149
  • 8
  • 89
  • 168
  • Thanks for the answer now it's solved and i used two's complement, Also inverted all bits and add 1 to the least significant bit '0000 0000 0000 1110 +1 = 0000 0000 0000 1111' This is 15 in decimal hence the number was negative so it's -15. – Adam Feb 08 '17 at 18:10