Understanding the endianness of MIPS. Why is data being stored in little endian format but output looks big endian - Stack Overf

admin管理员组

文章数量:1403438

This MIPS assembly program shown below is meant to count the number of characters in a string. This program was written using the MARS MIPS simulator (available from /)

#---------------------------------------------
# Count the number of characters of a string.
#--------------------------------------------- 
.data 
inputStr: .asciiz "Help"

.text
la $t0, inputStr         # This now contains the address of the leading byte of inputStr
li $t2, 0                # This will contain the count of the characters.   

start_while_loop:
   lb   $t3, 0($t0)       # Load a byte from computed address into integer
   sne  $t1, $t3, '\0'    # Check if the character in $t3 is NUL 
   beqz $t1, end_for_loop # Goto the end of the loop if the character is indeed NUL

   #-------------------------------------------
   # Print the non-null character just loaded
   #------------------------------------------
   li   $v0, 11
   move $a0, $t3
   syscall

   addi $t2, $t2, 1       # Increment the count of the characters.       
   addi $t0, $t0, 1       # Increment the address, for the next iteration. 

   b start_while_loop
end_for_loop:

move $a0, $t2 
li   $v0, 1
syscall

# Exit the program
li $v0, 10
syscall

Here is a screenshot of my output window

The code counts the number of characters (4 in this case) as expected, I am having trouble understanding the behavior from the perspective of endianness. Specifically, I would have expected the output of the program to be pleH4 and not Help4 for the reasons given below.

When I execute the program, and I look into the Data Segment window of MARS I see this

As you can see Help is stored backward as pleH. This seemed weird since Hennessey Patterson say explicitly in their book "Computer Organization and Design" that the MIPS processor is in the Big Endian camp. Since each character is a byte and MIPS word is 4 bytes long, I would have expected the 4 characters to be stored inside a word as Help and not pleH. Hennessey and Patterson mention however, in the appendix when describing SPIM (their own MIPS simulator)

So ostensibly the same thing is happening on my machine that has an AMD Ryzen CPU and so Mars is using the CPU's little endianness.

BUT then when I try to print out the characters one byte at a time I get the letters Help in the "normal" order and not pleH.

What exactly is happening here? Where am I messing up in my understanding of endianness vis-a-vis MIPS?

This MIPS assembly program shown below is meant to count the number of characters in a string. This program was written using the MARS MIPS simulator (available from https://dpetersanderson.github.io/)

#---------------------------------------------
# Count the number of characters of a string.
#--------------------------------------------- 
.data 
inputStr: .asciiz "Help"

.text
la $t0, inputStr         # This now contains the address of the leading byte of inputStr
li $t2, 0                # This will contain the count of the characters.   

start_while_loop:
   lb   $t3, 0($t0)       # Load a byte from computed address into integer
   sne  $t1, $t3, '\0'    # Check if the character in $t3 is NUL 
   beqz $t1, end_for_loop # Goto the end of the loop if the character is indeed NUL

   #-------------------------------------------
   # Print the non-null character just loaded
   #------------------------------------------
   li   $v0, 11
   move $a0, $t3
   syscall

   addi $t2, $t2, 1       # Increment the count of the characters.       
   addi $t0, $t0, 1       # Increment the address, for the next iteration. 

   b start_while_loop
end_for_loop:

move $a0, $t2 
li   $v0, 1
syscall

# Exit the program
li $v0, 10
syscall

Here is a screenshot of my output window

The code counts the number of characters (4 in this case) as expected, I am having trouble understanding the behavior from the perspective of endianness. Specifically, I would have expected the output of the program to be pleH4 and not Help4 for the reasons given below.

When I execute the program, and I look into the Data Segment window of MARS I see this

As you can see Help is stored backward as pleH. This seemed weird since Hennessey Patterson say explicitly in their book "Computer Organization and Design" that the MIPS processor is in the Big Endian camp. Since each character is a byte and MIPS word is 4 bytes long, I would have expected the 4 characters to be stored inside a word as Help and not pleH. Hennessey and Patterson mention however, in the appendix when describing SPIM (their own MIPS simulator)

So ostensibly the same thing is happening on my machine that has an AMD Ryzen CPU and so Mars is using the CPU's little endianness.

BUT then when I try to print out the characters one byte at a time I get the letters Help in the "normal" order and not pleH.

What exactly is happening here? Where am I messing up in my understanding of endianness vis-a-vis MIPS?

• mips
• endianness
• mips32
• mars-simulator

Share Improve this question Follow edited Mar 20 at 22:36 smilingbuddha asked Mar 20 at 22:30 smilingbuddhasmilingbuddha 14.8k3636 gold badges120120 silver badges206206 bronze badges 10

• 1 Why would you ever expect endianness to affect the order of characters in a char string? It's not an integer in the first place – Useless Commented Mar 20 at 22:45
• 1 Right. The ONLY time endianness is an issue is when you treat a series of bytes as a larger structure, by reading/writing to/from a register. A stream of bytes does not have any endianness. The byte string "Help" is stored with the "H" first. If you load that dword into a 32-bit register little-endian, you'll get 0x706C6548, where the "H" is at the bottom. If you load it big-endian, you'll get 0x4856C70, where the "H" is at the top. – Tim Roberts Commented Mar 20 at 22:59
• 1 It's just a choice of the debugger, to show the data that way, in that order. These debuggers don't know what kind of data you're storing in memory, so make their best guess and try to be helpful so you can make your own interpretation, which is ultimately your job. Most debuggers try to show the data in multiple ways, here we see ascii and hex of the same data. – Erik Eidt Commented Mar 20 at 22:59
• @Useless As to your first comment, I never expected anything specific the first time the program was written :-). I just got confused why "Help" being stored as "pleH" as I showed in the screenshot. Hence the SO post – smilingbuddha Commented Mar 20 at 23:02
• 1 @Useless Oh dear me! So all this time it was the debugger's weird method of displaying the data that has been throwing me off. To confirm, the characters "H", "e", "l" and "p" are stored in successive and increasing addresses in memory, correct? – smilingbuddha Commented Mar 20 at 23:14

 |  Show 5 more comments

1 Answer 1

Sorted by: Reset to default 1

Where am I messing up in my understanding of endianness vis-a-vis MIPS?

As far as I can tell you understand it perfectly and you're just being confused by the debugger display.

The MARS 4.5 Debugger documentation says

... All data are stored in little-endian byte order (each word consists of byte 3 followed by byte 2 then 1 then 0). Note that each word can hold 4 characters of a string and those 4 characters will appear in the reverse order from that of the string literal.

(my emphasis)

---

Endianness is (according to Wikipedia whose definition looks as good as any)

the order in which bytes within a word of digital data are transmitted ... or addressed (by rising addresses) in computer memory ...

Where "word" means some natural fixed-size datum larger than a byte, like for example a register (or practically including 16-bit halfwords on 32-bit or 64-bit systems, etc).

A character string is not such a datum, and endianness is not at all applicable.

Strings are variable length and stored with successive characters in consecutive increasing addresses. The characters are not typically packed into registers for integral computation (exceptions like vectorized string operations are an implementation detail, and the traditional layout of character strings is not affected).

本文标签：