Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!cs.utexas.edu!sun-barr!newstop!sun!sun.com
From: david@sun.com (philosophy is my hobby)
Newsgroups: comp.arch
Subject: Re: Byte ordering
Message-ID: <131201@sun.Eng.Sun.COM>
Date: 4 Feb 90 03:30:28 GMT
References: <9656@spool.cs.wisc.edu> <1990Feb2.215421.24894@utzoo.uucp>
Sender: david@sun.Eng.Sun.COM
Lines: 22

In article <1990Feb2.215421.24894@utzoo.uucp> henry@utzoo.uucp (Henry
Spencer) writes:
>As far as *technical* issues, the only ones
>I'm aware of weakly favor big-endian: ...  and it makes for consistent
>bit ordering in things like frame buffers (do the dots on the screen
>run left-to-right in successive bytes, or successive words? -- on a
>little-endian machine, they're not the same), which simplifies the
>code for optimized raster operations.

You can have "consistent" display pixel ordering with either byte sex.  For
big-endian machines you put the most significant bits of a word on the
left, and for little-endian machines you put the least significant bits on
the left.  Sun's 68K, SPARC, and 386 machines are "consistent" in this way.

I believe that IBM PCs are "inconsistent" -- they have a little-endian CPU,
but display the most significant bits on the left.

I have written a lot of optimized (?) raster graphics code, and I don't
consider this "consistency" to be particularly important.

-- 
David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david@eng.sun.com