benchmarking display speed? Speedups for little-endian machines...

Tim Rowledge tim at sumeru.stanford.edu
Sun Jul 23 17:59:34 UTC 2000



Ned Konz wrote:

> I was looking at the byte swapping code in the VM... is is really necessary
> to swap bytes for every display?
Currently, on a little endian machine, yes. Squeak Bitmaps are
big-endian; all the code in the image that manipulate them assumes
big-endian. A long time ago I spent a few mind manglind weeks rewriting
BitBLT (see http://sumeru.stanford.EDU/tim/pooters/LEBB.html) and a
whole raft of Form code etc to cope with little endian machines. More
recently, I convinced Andreas that it would really be nice to actaully
put the capability into the main release. 

In the course of those discussions, we eventually came up with the
Treaty of Denver and the ideas that now exist in the FXBLT code ( I
think - I haven't had time to even properly read the code yet) and
should allow us to arbitrarily mix big-endian, little endian,
middle-endian (yes it exists - dear old M$ does Windows bitmapts in
middle-endian form!) as source, destiniatio, texture, halftone,
whatever. It also allows bitmaps to be external to the Squeak object
memory, so that memory in accelerator cards can be used.

Sometime soon, VMs can be updated to make use of this and the
pixel-swapping code will be removed from the Acorn, Windows and Unix
windows files.

Oh, and in most cases, the reversing loops you mentioned spend all their
time reading from and writing to the cpu cache, so trying to do clever
things by readinga word and hand manipulating instead of reading each
byte separetly has no actual benefit. Been there, wasted my time on that....

tim





More information about the Squeak-dev mailing list