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