Xref: utzoo comp.arch:7736 comp.misc:4583 comp.lang.misc:2429 comp.protocols.misc:431
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!haven!uflorida!gatech!hubcap!hutch
From: hutch@delft (David Hutchens)
Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc
Subject: Re: "big endian" and "little endian" - first usage for computer
Message-ID: <4008@hubcap.UUCP>
Date: 4 Jan 89 17:31:45 GMT
References: <170@microsoft.UUCP>
Sender: news@hubcap.UUCP
Reply-To: hutch@delft
Lines: 20

From article <170@microsoft.UUCP>, by w-colinp@microsoft.UUCP (Colin Plumb):
> In article <145@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes:
>>The problem is, there are no consistent little-endian machines, the
>>big-endian infiltrators have sabotaged every last one (that I know of).
> 
> The Inmos transputer is uniformly little-endian.  This applies to both
> integers and floating-point numbers (where most others mess up).
> -- 
> 	-Colin (uunet!microsof!w-colinp)

Actually, where most little-endian machines screw up is storing the
bits in the byte in the wrong order.  It is good to hear that somebody got it
right and stored a one as 100000...0000 rather than 00000001000...000.
(That is what you meant wasn't it?).  Note that this implies one
multiplies by 2 by using a RIGHT shift (else there is an inconsistancy
in the little-endian view in the registers)!  The Inmos sounds interesting.

		David Hutchens
		hutch@hubcap.clemson.edu
		...!gatech!hubcap!hutch