The "Go" tools

understand ....

by Jeremy Gordon -

This file is intended for those interested in 32 bit assembler programming, in particular for Windows.

This is a topic you will need to know about if you intend to examine the data and memory or your computer using a debugger. If not, then this article will be of interest only.

Basically Intel processors do not keep data in memory in the order you would expect. Instead the data is reverse stored on a byte by byte basis.
Let me explain. A single byte will be stored in memory at the address intended.
But a word (two bytes) will be stored in memory with the least significant byte at the word's address in memory, but with the most significant byte at the next address up.
Regarded as a byte sequence this is sometimes called a "little-endian" format because the least significant byte is first and the most significant byte is second. The other way round is called "big-endian" and is used by some other processors.

Word example
Suppose therefore you have a word of value 248Ch which is to be stored at 400000h. This will be stored as follows:-
8Ch at 400000h
24h at 400001h.

When the memory at 400000h is read into a word register by a word instruction, the bytes will be read in reverse so that the value 248Ch will be loaded into the register.

Dword example
A dword (four bytes) will be stored in memory with the least significant byte at the dword's address in memory, then the next two bytes and finally with the most significant byte at the fourth address up.

For example suppose you have a dword of value 12345678h to be stored at 400000h. This will be stored as follows:-
78h at 400000h
56h at 400001h
34h at 400002h
12h at 400003h

When the memory at 400000h is read into a dword register by a dword instruction, the bytes will be read in reverse so that the value 12345678h will be loaded into the register.

Note that the nibbles in the byte are not reversed at any time.

By now you may be asking why this happens. Wouldn't it be much easier to store data in the same order as we visualise it? Well it would be for us, but not for the computer. And this is not something that you can blame on assembler language. All data whatever language is used is stored in this way on Intel processors. Normally this is something transparent to the programmer and you needn't worry about it.