On Sat, 21 Aug 2004 06:37:10 -0700, "Peter Nachtwey"
<p...@comcast.net> wrote:

>"John Harlow" <s...@hotmail.com> wrote in message
>news:a...@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

Paul Keinanen <k...@sci.fi> writes:
> On Sat, 21 Aug 2004 09:19:11 -0400, "John Harlow"
> <s...@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.

"Everett M. Greene" wrote:
> Paul Keinanen <k...@sci.fi> writes:
>> "John Harlow" <s...@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

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.

"John Harlow" <s...@hotmail.com> wrote in message
news:a...@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.

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:p...@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

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
> bit

This 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:p...@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

"Paul Black" <n...@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.

David Brown wrote:
> "Paul Black" <n...@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:p...@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

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.