Big-Endian vs. Little-Endian

At the risk of starting a flame war, which choice have people really made with regard to Little-Endian vs. Big-Endian for those processors where it's a design choice (ARM, PowerPC,...)? I'm asking in the context of using such processors in embedded applications where compatibility with anything in the outside world is not a factor.

Reply to
Everett M. Greene
Loading thread data ...

Given a choice, I prefer big-endian in isolation.

--
Grant Edwards                   grante             Yow!  Don't SANFORIZE me!!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

In this situation, why bother with it, since it is hard to imagine situations in which this really matters. In the unlikely situation that the order might be important in a special situation, I would suggest using the endianess in which your team has worked previously. This may help to avoid one or two errors during a large project.

Although the current specifications do not require any binary interfacing to the outside world, there is always a risk that in a future version such connections are needed. In these situations, remember to write the actual code that work with any endianess (e.g. explicitly using shifts, ORs and masks) to assemble and/or disassemble a string of bytes.

Paul

Reply to
Paul Keinanen

There is a slight advantage in little-endian: you can address the least significant part of a longer item with the same address as the original item.

In Intel 80x86 family, the lowest byte of a longword is in the same address as the longword, which most often is intuitively clear. This does not work in big-endian architectures.

Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

But the hex dumps are harder to read! ;)

Reply to
John Harlow

Hex dumps are things of the 80s. However, I prefer little endian because of reasons previous stated except in communication applications where data normally comes over the wire in big endian format AND the CPU has a word length greater than 8 bits. Using big endian in communication applications avoids having to swap all the data.

Peter Nachtwey

Reply to
Peter Nachtwey

How sweet ... a newbie. ;-)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

An old discussion on this subject:

formatting link

Reply to
Craig Bergren

Exactly! I recently switched from a long line of little-endian processors to the big-endian Coldfire. I spent too many years reading byte-oriented hex dumps and trying to reorder the bytes in my head.

You just keep telling yourself that ....

Casey

Reply to
Casey

OTOH big-endian has the advantage of immediate access to the sign bit, and the penalty of requiring an initial address calculation for most arithmetic operations.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
CBFalconer

And?

It may be intuitively clear, but for what purpose? How often do you wish to address the LSbyte of a multi-byte value?

Reply to
Everett M. Greene

...and the 60's, the 70's, the 90's, and the 00's...

-- Dan Henry

Reply to
Dan Henry

Use a proper dump program that dumps bytes from right to left as the VAX/VMS DUMP command did (since 1970's).

Paul

Reply to
Paul Keinanen

Everett M. Greene ??:

network packets' header use the bigedian, but no need to call converting fuctions to convert the value in packet header if use bigedian machine

BZ

Reply to
Bill Zhao

I do it all of the time, but I don't see having it at the same address as the longword as being any intuitively clearer. In fact, I find the opposite to be slightly more intuitive.

How about 4-bit processors? I am sure that I am not the only one here who like them... Any opinions about Big-Endian vs. Little-Endian when using multiple nybbles to make bytes?

Reply to
Guy Macon

Strange, I thought I was looking at one a few days ago :)

Al

Reply to
Al Borowski

Just curious: would I be correct in assuming you are a "software person" as opposed to a "hardware/software person"?

Mike Harding

Reply to
Mike Harding

But you then have to dump the locations a second time if you want to see the binary values in their memory order without playing mental calesthentics.

Reply to
Everett M. Greene

Without further comment:

[1] c:\>symdeb Microsoft (R) Symbolic Debug Utility Version 4.00 Copyright (C) Microsoft Corp 1984, 1985. All rights reserved.

Processor is [80286]

-d 100 120

235B:0100 69 70 74 73 04 04 43 3A-5C 44 4A 47 50 50 5C 4C ipts..C:\DJGPP\L 235B:0110 49 42 5C 4C 44 53 43 52-49 7E 31 0D 0A 43 3A 5C IB\LDSCRI~1..C:\ 235B:0120 64 d

-dw 100 120

235B:0100 7069 7374 0404 3A43 445C 474A 5050 4C5C 235B:0110 4249 4C5C 5344 5243 7E49 0D31 430A 5C3A 235B:0120 6A64

-da 100 120

235B:0100 ipts..C:\DJGPP\LIB\LDSCRI~1..C:\d

-dd 100 120

235B:0100 7374:7069 3A43:0404 474A:445C 4C5C:5050 235B:0110 4C5C:4249 5243:5344 0D31:7E49 5C3A:430A 235B:0120 7067:6A64

-q

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
 Click to see the full signature
Reply to
CBFalconer

Usually the processor manufacturer made the choice for you by implementing the instruction set. Even for 8bit machines.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
 Click to see the full signature
Reply to
Rene Tschaggelar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.