Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!ames!ucla-cs!sdcrdcf!psivax!nrcvax!minnie!ihm
From: ihm@minnie.UUCP (Ian Merritt)
Newsgroups: comp.sys.m68k
Subject: Re: Intel vs Motorola Byte ordering (network standards)(long)
Message-ID: <345@minnie.UUCP>
Date: Thu, 11-Dec-86 11:12:41 EST
Article-I.D.: minnie.345
Posted: Thu Dec 11 11:12:41 1986
Date-Received: Mon, 15-Dec-86 21:42:50 EST
References: <22921@rochester.ARPA> <713@cci632.UUCP>
Reply-To: ihm@minnie.UUCP (Ian Merritt)
Organization: The Frobboz Magic Network Co., Inc.
Lines: 71
Keywords: networks
Summary: Say what?

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

What you describe sounds like IP Source routing, where each address
examines the address chain, strips the first and sends the rest on to
that address.  Still, if the basic address size is larger than the CPU
basic word (as it will certainly be in any network with more than 256
nodes (or at least 256 nodes per heirarcical subnet), the issue of how
to combine the basic size at the destination is no more well established
by your suggestion than by the existing standards.

>
>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).

Agreed, mostly, though I am somewhat partial (as I have mentioned
before) to the Little endian school.

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

"middle-endian", you seem to use as a generic form for describing
anything that is not consistently either little or big.  I disagree with
the term, but not with the conclusion you draw.  To what 808x machines
do you refer?

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

I can't agree that extension bits are preferable, and in any case, as I
mentioned above, there is often a need for numbers larger than can be
represented in a single byte.  There is no need to constrict the
capability of the protocol just because it's "hard" to juggle the bytes
around to accomodate a particular machine.  If computers aren't here to
juggle bits and bytes, what ARE they for? Granted it would save time in
this case if every machine had the same standard, but since we can't
agree on a uniform standard, juggling is likely to be here to stay for a
while at least.

>Some psychological factors which work well, is to think in terms of
>"system; node" rather than "nodelow; nodehigh" type labelling.

Again, source routing: not always useful; not necessarily byte oriented.

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

Agreed, but there are very few machines that are totally consistent
about it.

>
>Rex B.


Cheerz--
						<>IHM<>
-- 

uucp:	ihnp4!nrcvax!ihm