Question about endianness in register.

[jimmyjo...@nospicedham.yahoo.com]

Hello all,

I am currently trying to learn about about the differences between
little and big endian. I understand the basic textbook explanation and
theory between the two, but when I see this example in my assembly
book I am confused.

mov eax,'ABCD' ; Eax shows 0x44434241
mov eax,0FFEEDDCCh ; Eax shows 0xffeeddcc

My computer is using little endian and when I move the value 'ABCD'
into eax I expect to see the value I am getting. I was wondering why
when I moved 0xffeeddcc into the eax register the debugger isn't
displaying the result as 0xccddeeff.

Thanks.

[wolfgang kern]

jimmyjones8577 asked:

Yeah, value of 0xffeeddcc is stored in little Endian order
(LSByte '0xcc' at the lower address of course then).
And an ASCII-quad become converted into a four byte value, so you see the
'A' as the LSByte because it shall appear on the screen before the 'B'
and screen memory starts at top left corner (left to right incrementing).

It's just due to human number reading in western text-mode is wrong
in terms of digital logic (reading the most signifant letter first
mean that it's at lowest position in memory is not really logical :)

Big Endian number storage got many disadvantages on x86 CPUs,
check yourself: ADD,SUB, carry handling and more.
__
wolfgang

[James Harris]

IIRC some assemblers reverse the order of four-byte text strings
loaded into a register.

Besides, endianness doesn't really apply to values in registers. Stick
to applying it to values in memory and you'll be fine.

James

[s_dub...@nospicedham.yahoo.com]

These are both 'immediate values' to the opcode, endianness usually
refers to how the data is stored in memory.

Of 'ABCD' the ascii value of 'A' is the low order byte, because this
is the choice of the compiler or assembler designer to handle a string
literal for a double word value enclosed in single quotes. -see below
how this immediate value is stored in memory..

Of 0FFEEDDCCh, 0FFh is the high order byte. The high order byte is
shown as the left most in the debugger for the register contents, just
like you typically see it in print.

- so for: -

1 ;; tst_code.nsm
2 ;; ck endian of immediate
value
3
4 ;; tst_code.mak =>
5 ;; -f bin
6 ;; -l TST_CODE.LST
7 ;; -E TST_CODE.WPD
8 ;; -o TST_CODE.BIN
9 ;; TST_CODE.NSM
10
11
12 [MAP ALL TST_CODE.MAP]
13
14 section .text
15
16 start:
17 00000000 66B841424344 mov eax, 'ABCD' ;; quoted
literal
18 00000006 66BBCDAB0000 mov ebx, 0ABCDh ;; value
19
20 0000000C 66C706[8000]414243- mov dword [DataStor], 'ABCD'
21 00000014 44
22 00000015 66C706[8400]CDAB00- mov dword [DStor2], 0ABCDh
23 0000001D 00
24 0000001E 90 nop
25 0000001F 90 nop
26 00000020 EBDE jmp start
27
28 00000022 90<rept> TIMES (80h - ($-$$)) db 90h ;;
nop's
29
30 00000080 00000000 DataStor: db 0,0,0,0
31 00000084 00000000 DStor2: db 0,0,0,0
32
33 ;; -eof-

- Little Endian x86 -
- run in your debugger and view the stored contents for the stored
byte sequence..

#d80
0C01:0080 41 42 43 44 CD AB 00 00 00 00 00 00 00 00 00 00
ABCD............
0C01:0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ................
0C01:00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ................

Maybe Wikipedia can help..

http://en.wikipedia.org/wiki/Big_endian

Steve

[Rod Pemberton]

<jimmyjo...@nospicedham.yahoo.com> wrote in message
news:0d32bddf-b6a0-4124...@l29g2000yqf.googlegroups.com...

The ordering for integers with x86 assemblers is usually the same:

mov eax, 0FFEEDDCCh
B8CCDDEEFF ; MASM
B8CCDDEEFF ; NASM

The ordering for strings with x86 assemblers is assembler dependent:

mov eax, 'ABCD'
B844434241 ; MASM
B841424344 ; NASM

I.e., you were probably using MASM ...

The difference between big-endian and little-endian is how the data is
ordered when read into a register from memory. Little-endian, like x86,
will place the first read byte into the LSB and the last read byte into the
MSB. You can see this above with the 0FFEEDDCCh value. It's stored in
reverse of the way an integer written. CC is read first. FF is read last.
Big-endian will place the first read byte into the MSB and the last read
byte into the LSB. I.e., it'll match the way an integer is written. FF
will be read first. CC will be read last. The reading order didn't change.
The byte order changed: FFEEDDCC. Basically, little-endian reverses the
memory byte order when reading from memory to register.

Put out four fingers. That's how four bytes of data is stored in memory.
Now, flip your hand over. That's what x86 (little-endian) does when
reading. For big-endian, your hand doesn't flip.

Little-endian is more efficient with integer offsets encoded into
instructions. This helps the microprocessor. Big-endian is more efficient
with string encodings. This helps you. I.e., if you read part of a string
which was stored as bytes on x86 in memory using an integer larger than a
byte in size, the characters will be reversed. E.g., if 'A' and 'B' and 'C'
and 'D' are stored as bytes on x86, reading a word starting at 'A' will
return 'BA', dword will be 'DCBA'. On a big-endian matchine, if you do the
same, you'll get 'AB' and 'ABCD' respectively. Frequently, you'll see C
code written for big-endian machines make use of integer types other than
CHAR, e.g., UNSIGNED LONG. This is to make strings faster by using larger
integer sizes. Such code won't work on x86 without reversing the byte order
of each integer.


Rod Pemberton

[Tim Roberts]

The only time endianness matters is when you look at the value as bytes,
not as dwords. 0FFEEDDCCh is always going to load as 0FFEEDDCCh, but they
are stored in memory differently. Consider this data in memory:

00004000: 00 11 22 33 44 55 66 77

On a little-endian processor, if you load that into a 32-bit register, you
get this:
mov eax, [4000h] ; 0x33221100

But if I do the same operation on a big-endian processor:
ldr r3, #0x4000 ; 0x00112233

With that same piece of memory, notice the differences:

Little Big
Load byte 00 00
Load word 1100 0011
Load dword 33221100 00112233
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Bob Masta]

As others have noted, you are probably using MASM or
something similar, which flips the order of string
immediates. Although I use MASM32 exclusively, this odd
behavior is a continual annoyance. (Another is that the
error reporting gives line numbers modulo 65536... guess
Microsoft never used it for any big projects!)

Best regards,


Bob Masta

DAQARTA v6.02
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!