Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!rb
From: rb@cci632.UUCP (Rex Ballard)
Newsgroups: comp.sys.m68k
Subject: Re: Intel vs Motorola Byte ordering (network standards)(long)
Message-ID: <713@cci632.UUCP>
Date: Tue, 9-Dec-86 16:39:57 EST
Article-I.D.: cci632.713
Posted: Tue Dec  9 16:39:57 1986
Date-Received: Wed, 10-Dec-86 04:16:08 EST
References: <22921@rochester.ARPA>
Reply-To: rb@ccird2.UUCP (Rex B)
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 27
Keywords: networks
Summary: No endian protocols.

There are several protocols that are Non-endian, such as AX.25.
Most such protocols simply establish a hierarchy of addresses.
This hierarchy simplifies routing significantly, since only the
the machine that matches the first ID will have to look at the
second...

In general, there is not "Best" endian approach.  Little-endian
machines have advantages in the integer processing of words larger
than their registers/backplane, while Big-endian has advantages
in raw search/compare/sort type applications.  Even graphics
isn't "cut and dried" in favor of either one, since there is
lots of shifting (which gives Big-endian an advantage), and
lots of integer computation (which favors Little-endian).

The worst of course is "middle-endian", such as that used on
the PDP-11 and some 808X machines for longs.

When discussing network protocols, or data interchange formats,
it is a good idea to avoid "endian" thinking at all.  Bytes
with "extension bits", or just raw bytes are definately preferable.
Some psychological factors which work well, is to think in terms of
"system; node" rather than "nodelow; nodehigh" type labelling.

Internally, so long as the machine is consistant, either end
is acceptable, based on the trade-offs desired for the application.

Rex B.