Little-endian MIPS inconsistency

Question

From what I can understand, there is an inconsistency with the endianness in MIPS assembly when run on QtSpim (no an x86_64 machine, which means QtSpim is little-endian). However, I am not sure if it's a bug or if I'm wrong.

When a word is loaded into a register, the bytes are not reversed to reflect little-endianness. For example, if a word in memory contains 0x11223344 and we load it in a register, we get 0x11223344 (I would expect 0x44332211).

Consider the following snippet:

    .text
    .globl main
main:
    la   $t0, letters
    lw   $t1, 0($t0)   # Expected ($t1): 0x61626364
    sll  $t2, $t1, 8   # Expected ($t2): 0x62636400
    sw   $t2, 0($t0)   # Expected (mem): 0x00646362
    jr   $ra

    .data
letters:
    .ascii "abcd"

Before the program runs, "abcd" is stored little-endian, as expected: 0x64636261 (dcba). After the program has completed, I would expect 0x00646362 (\0dbc) to be stored in memory, however 0x63626100 (cba\0) is stored.

Why is this the case?

Tested on Fedora 24, x86_64, QtSpim version 9.1.17.

Michael Michael · Accepted Answer · 2016-11-18T08:21:22

There's no inconsistency. You take 0x64636261 and shift it 8 bits to the left (i.e. shifting out bits to the left while shifting in zeroes from the right). So 0x64636261 becomes 0x63626100
If you wanted 0x00646362 you should've used srl instead of sll.

Here's an ASCII diagram showing the relationship between a 32-bit word and the individual bytes in a little-endian configuration:

0x64636261
  | | | |
  | | | ----> |'a'| letters
  | | |       -----
  | | ------> |'b'| letters+1
  | |         -----
  | --------> |'c'| letters+2
  |           -----
  ----------> |'d'| letters+3

Little-endian MIPS inconsistency

1 Answers