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