Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!decvax!tektronix!uw-beaver!ubc-vision!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch,comp.sys.intel,comp.sys.m68k
Subject: Re: byte order: be reasonable - do it my way...
Message-ID: <753@vaxb.calgary.UUCP>
Date: Tue, 13-Jan-87 18:05:27 EST
Article-I.D.: vaxb.753
Posted: Tue Jan 13 18:05:27 1987
Date-Received: Wed, 14-Jan-87 23:30:53 EST
References: <760@orcisi.UUCP> <1011@cuuxb.UUCP>
Organization: U. of Calgary, Calgary, Ab.
Lines: 38
Xref: mnetor comp.arch:187 comp.sys.intel:100 comp.sys.m68k:109

In article <1011@cuuxb.UUCP>, mwm@cuuxb.UUCP (Marc W. Mengel) writes:
> ... The point I am trying to make
> is that for computational purposes, they byte-ordering question is 
> moot.  When you introduce the paradign of typed memory locations and
> type conversion instructions, the two systems become computationally
> equivalent.

Not quite. Consider the following C code:

    int i;
    char c;

    void proc(x)
      char *x;
    { ...
      access to *x;
      ...
    }

    ...

    c = 'a';
    proc(&c); 
    i = 'a';
    proc(&i);

The two calls to 'proc' both deliver parameters for which *x is 'a' on a
little-endian machine, but they don't on a big-endian machine. The litte-
endian method thus allows a certain flexibility in typing that the
big-endian method doesn't. This is NOT just a notational matter.

I do not recommend use of this technique in C code, due to the obvious
portability problems. But if little-endian memory were entirely standard it
might be a usefull technique, though really you want a more general run-time
typing scheme if you want to do this sort of thing.

    Radford Neal
    The University of Calgary