[RFI]Mac performance gap between OS-9 and OSX

Andreas Raab andreas.raab at gmx.de
Tue Aug 5 20:42:05 UTC 2003


> Clearly I would much prefer that Squeak's bitmap handling
> could work cleanly with little endian and well as big endian 
> but we had that debate several years ago after I implemented
> a working little endian bitblt.

Every now and then you should try a different machine ;-) If you use Squeak
on a Windows PC you'll find that Squeak's "set display depth" menu offers
you the choice between little endian and big endian formats. I have done
this partly as a proof of concept to show that the byte endian conversions
really do work (it's easy to find if some portion of your screen goes just
black or garbage ... well as long as you have a way to turn it back at least
;) so all of this is (as far as I am aware) working perfectly well for the
last couple of years.

However, due to not changing the byte ordering of all of the *internal*
forms of Squeak this has precious little effect because byte-endian-swapping
blits are naturally more expensive and the VMs byte-reversal stuff has been
optimized for years (up to the point that the assmbly code is proven
optimal) so unless you change all of the internal forms too, there is no
clear speed advantage going little endian here.

If you are interested in this you should just give it a try - merely have
your VM answer true if queried for a negative display depth in
primitiveTestDisplayDepth and you'll be able to go forth and back between
little and big endian pixels. And if you're really into it, you might try to
fix it so that forms (when they are being unhibernated) come up with the
native byte order instead.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list