🚀 go-pugleaf

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)