Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!mtxinu!frk From: frk@mtxinu.COM (Frank Korzeniewski) Newsgroups: comp.arch Subject: Re: Byte ordering Message-ID: <1116@mtxinu.UUCP> Date: 4 Feb 90 05:57:22 GMT References: <9656@spool.cs.wisc.edu> <1990Feb2.215421.24894@utzoo.uucp> <131201@sun.Eng.Sun.COM> Reply-To: frk@mtxinu.UUCP (Frank Korzeniewski) Organization: mt Xinu, Berkeley Lines: 35 In article <131201@sun.Eng.Sun.COM> david@sun.com (philosophy is my hobby) writes: #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 I have written bitblt and graphics routines for an EGA on an 80386, and I consider this in"consistency" to be a serious mistake. You cannot take advantage of 32 bit shifts when the bits are laced back and forth thru the 32 bit word. This can (and does) result in a factor of two or more LOSS in performance. Wait you say, the EGA only has an 8 or 16 bit interface and so you don't need to reference it in 32 bit chunks. Hmmmm, I say, not all your pixel manipulation occurs onscreen. There is plenty of offscreen work to do where you can reference 32 bits at a time (or you could if the hardware were done correctly). Frank Korzeniewski (frk@mtxinu.com)