On Sat, 21 Aug 2004 06:37:10 -0700, "Peter Nachtwey" <pnachtwey@comcast.net> wrote:>"John Harlow" <sirsausage@hotmail.com> wrote in message >news:a_ydnSXrtctO1rrcRVn-pA@comcast.com... >> > 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. >> >> But the hex dumps are harder to read! ;) >> >> >Hex dumps are things of the 80s.Just curious: would I be correct in assuming you are a "software person" as opposed to a "hardware/software person"? Mike Harding
Big-Endian vs. Little-Endian
Started by ●August 20, 2004
Reply by ●August 22, 20042004-08-22
Reply by ●August 22, 20042004-08-22
Paul Keinanen <keinanen@sci.fi> writes:> On Sat, 21 Aug 2004 09:19:11 -0400, "John Harlow" > <sirsausage@hotmail.com> wrote: > > >> 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. > > > >But the hex dumps are harder to read! ;) > > Use a proper dump program that dumps bytes from right to left as the > VAX/VMS DUMP command did (since 1970's).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 by ●August 22, 20042004-08-22
"Everett M. Greene" wrote:> Paul Keinanen <keinanen@sci.fi> writes: >> "John Harlow" <sirsausage@hotmail.com> wrote: >> >>>> 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. >>> >>> But the hex dumps are harder to read! ;) >> >> Use a proper dump program that dumps bytes from right to left as the >> VAX/VMS DUMP command did (since 1970's). > > 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.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 that are worse than the original problem. Usage: "Windows ME fixes many of the shortcomings of Windows 98 SE". - Hutchison
Reply by ●August 23, 20042004-08-23
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 Everett M. Greene wrote:> 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 by ●August 23, 20042004-08-23
"John Harlow" <sirsausage@hotmail.com> wrote in message news:a_ydnSXrtctO1rrcRVn-pA@comcast.com...> > 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. > > But the hex dumps are harder to read! ;) >It depends on what you are used to. I use both big-endian (68k, ppc) and little-endian (msp430, avr (little-endian by compiler convention more than architectural necessity, since it is 8-bit), Nios) processors. I find little-endian to be easier to work with, easier to view in hex dumps, and easier to work out which bit is in which place - even though I know that big-endian is more consistent and should be easier. It's just a matter of habit and familiarity.
Reply by ●August 23, 20042004-08-23
Rene Tschaggelar wrote:> Usually the processor manufacturer made the choice for you > by implementing the instruction set. Even for 8bit machines.You've missed the point that some processors can be used in either big or little endian mode. -- Paul Black mailto:paul.black@oxsemi.com Oxford Semiconductor Ltd http://www.oxsemi.com 25 Milton Park, Abingdon, Tel: +44 (0) 1235 824 909 Oxfordshire. OX14 4SH Fax: +44 (0) 1235 821 141
Reply by ●August 23, 20042004-08-23
CBFalconer wrote:>>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. > > > OTOH big-endian has the advantage of immediate access to the sign > bitThis information would be immediately available on some little endian systems as well: the ARM instruction set, for example, can encode an immediate offset in the instruction. -- Paul Black mailto:paul.black@oxsemi.com Oxford Semiconductor Ltd http://www.oxsemi.com 25 Milton Park, Abingdon, Tel: +44 (0) 1235 824 909 Oxfordshire. OX14 4SH Fax: +44 (0) 1235 821 141
Reply by ●August 23, 20042004-08-23
"Paul Black" <nospam@nospam.oxsemi.com> wrote in message news:cgc79r$fdl$1@jupiter.oxsemi.com...> Rene Tschaggelar wrote: > > Usually the processor manufacturer made the choice for you > > by implementing the instruction set. Even for 8bit machines. > > You've missed the point that some processors can be used in either big > or little endian mode. >Yes, but many of these have a prefererance for one mode. The PPC architecture, for example, perfers big-endian - some implementations (like the MPC56x) don't support little-endian at all, while those that do have certain restrictions - I believe the string instructions only function in big-endian mode, for example. This is because all cpus have are fixed-endian at heart (normally big- or little-endian, though there have historically been computers with all sorts of arrangements), and the non-native mode is handled using thunking - the bytes of multi-byte data are re-arranged on the fly as data is moved into and out of the cpu.
Reply by ●August 23, 20042004-08-23
David Brown wrote:> "Paul Black" <nospam@nospam.oxsemi.com> wrote in message > news:cgc79r$fdl$1@jupiter.oxsemi.com... > >>Rene Tschaggelar wrote: >> >>>Usually the processor manufacturer made the choice for you >>>by implementing the instruction set. Even for 8bit machines. >> >>You've missed the point that some processors can be used in either big >>or little endian mode. >> > > > Yes, but many of these have a prefererance for one mode. The PPC > architecture, for example, perfers big-endian - some implementations (like > the MPC56x) don't support little-endian at all, while those that do have > certain restrictions - I believe the string instructions only function in > big-endian mode, for example.The one I'm most familar with is the ARM where the endianness is set by an external line.> This is because all cpus have are > fixed-endian at heart (normally big- or little-endian, though there have > historically been computers with all sorts of arrangements)CPUs internally have no endianness. The endianness only comes into play when accessing memory. -- Paul Black mailto:paul.black@oxsemi.com Oxford Semiconductor Ltd http://www.oxsemi.com 25 Milton Park, Abingdon, Tel: +44 (0) 1235 824 909 Oxfordshire. OX14 4SH Fax: +44 (0) 1235 821 141
Reply by ●August 23, 20042004-08-23
Everett M. Greene wrote:> 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.When dealing with bitstreams such as raster lines, big-endian is way better. The ultimate machine for these apps have large words and are big-endian. Bulk operations such as applying masks are not affected, but some operations such as shifting, shearing, and bit-bending are way easier on a natural order machine when having to cast around types. I say natural order - maybe that should be anthropic order. We read numbers LtoR, MSD to LSD. -- ------------------------------------------------------------ Creepy, Soulless Gigolo for President ? NOT ! --------------------------------------------- THK is one weird, weird something.
