Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!mayer
From: mayer@rochester.ARPA (Jim Mayer)
Newsgroups: comp.sys.m68k
Subject: Re: Intel vs Motorola Byte ordering (network standards)(long)
Message-ID: <22921@rochester.ARPA>
Date: Fri, 5-Dec-86 13:51:09 EST
Article-I.D.: rocheste.22921
Posted: Fri Dec  5 13:51:09 1986
Date-Received: Fri, 5-Dec-86 21:21:44 EST
References: <1509@ihlpl.UUCP> <1335@hoptoad.uucp> <138@pembina.alberta.UUCP> <791@nike.UUCP>
Reply-To: mayer@rochester.UUCP (Jim Mayer)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 77
Keywords: networks
Summary: Network byte order standards already exist

I have never been convinced of any fundamental reason to prefer one
byte ordering over another, however I believe there are some practical
ones.  Basically, any networked machine that uses a different byte
order than the network(s) it is connected to will pay a (possibly
significant) performance penalty.  Furthermore, code that written to
run on both byte orders will always pay some penalty even if run on
the "right" machine.  The rest of this article contains an example,
a possible way out of the mess, an observation, and a question.

THE EXAMPLE:

Suppose a C program reads a message into a structure (let's assume
problems with byte size and alignment have gone away).  A correct
program has two choices: it can convert the structure to the machine's
byte order, or it can leave the structure in network order an convert on
each reference.  In the first case, there are three options.  The first
two are:

(1)	struct message { short x; long y; } m;
	m.x = ntohs(m.x); m.y = ntohl(m.y);

(2)	if (host byte order is not network byte order) {
		m.x = ntohs(m.x); m.y = ntohl(m.y);
		}
(3)	if (sending machine byte order is not host machine order) {
		m.x = ntohs(m.x); m.y = ntohl(m.y);
		}

In (1), there is a constant penalty of at least one unnecessary copy.
Unnecessary copy operations can quickly destroy the performance of a
message passing system.  Also, any missing swap operations will not be
detected on a machine with network byte order.  Case (2) assigns the
penalty where it is due, but opens up even more possibilities for
errors.  Case (3) uses the same trick the X display server uses:
accept messages in either byte order.  The code ends up being similar
to (2), but swapping is only done if the sending machine has a
different byte order than the receiving machine.  It has the same
testability problems as (2).

If the structure is maintained in network byte order, then each reference
to the structure entails a possible conversion.  The possibilities for
programmer error are quite large here as well.

THE SUGGESTION:

All of the above solutions are error prone when written in a language like
C that has no notion of byte order.  Languages like CLU and C++ offer
the possibility of encapsulating most of the nasty conversions.  Another
possibility is the addition of a "message" type constructor, analogous to
"struct" in C, but maintaining a particular byte order (and floating
point representation, etc.) and either prohibiting or interpreting correctly
things like pointer references.  Adding a "message" construct would be
syntactically prettier (I think) than forcing a lot of calls to "m.get_x()"
and "m.set_x(value)".  It would also help with other representation issues
(like value alignment, byte and word size, and floating point).

THE OBSERVATION:

I can easily envision a Load/Store architecture machine with a completely
bisexual instruction set.  Only the load and store operations would have
to be modified.  I understand from other postings that the MIPS processor
can already be configured in either mode.

THE QUESTION:

TCP and friends use a "big-endian" order (since TCP is a byte stream
protocol this applies only to things like addresses and headers).  What
order do other protocol families use?  Are there any major
"little-endian" protocol families?

-- Jim Mayer					Computer Science Department
(arpa) mayer@Rochester.EDU			University of Rochester
(uucp) rochester!mayer				Rochester, New York 14627
-- 
-- Jim Mayer					Computer Science Department
(arpa) mayer@Rochester.EDU			University of Rochester
(uucp) rochester!mayer				Rochester, New York 14627