From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 07 Aug 1998 10:19:49 +0200

Re: ggiGetPixelFormat and proposed new DirectBuffer scheme

WolfWings ShadowFlight wrote:
> 486 and up have a 32-bit byte-swap instruction, named, what else, BSWAP
> :-) Takes 1 cycle on a 486, and I believe pairs on everything after that,
> but I could be wrong, as I haven't been able to find _any_ clock-cycle
> count listings for anything beyond a 486, which is really irksome when one
> has no clue how fast the MMX instructions actually are and such.
> 
> On 386, the fastest way is a trio of bit-shifts, I believe.
> ror ax, 8
> ror eax, 16
> ror ax, 8

Ah, that's somewhat shorter than the 14 instructions gcc -S compiled
my GGI_BYTESWAP32 macro into. :-)

> Now, the problem with Linux: Is there a symbol defined so we can
> differentiate between being compiled on a 386, or a 486+? If not, the
> above macro is 6x slower on a 486, and many, many times slower as it won't
> be pairing too nicely unless the compiler is willing to play
> instruction-shuffler with inline assembly macro's too. Does GCC or any of
> it's derivitaves do that?

For gcc 2.7.2.1 you can use
#ifdef __i486__
486 or higher

With egcs you'll have to use
#if defined(__i486__) || defined(__pentium__) || defined(__pentiumpro__)
486 or higher

Unfortunately egcs defaults to -mpentium if you don't give a -m
flag, but the preprocessor defines are identical to those that
-m386 produces, so there's no way to tell the two appart.
On the other hand gcc 2.7.2.1 defaults to -m486, and as code using
the bswap instruction won't run on a 386 we'll have to default
to the 386 way anyway.

Thus the only way is to let the user specify 486+ specific
optimizations manually at buildtime.

> >3,5,6 and 7 bit modes should definitely be unpacked, because
> >I've never heard of any HW that supports such modes with a packed
> >chunky buffer. :)
> 
> I'm _so_ tempted to point out VGA text mode, but I'll be nice today. ;-)

I thought VGA textmode was 16 bit? 8 bit char and 8 bit attributes?

> >For Get/Put buffers I think it makes most sense to use chunky
> >pixels even if the HW is planar, as it will allow applications
> >to run everywhere without needing to now anything about planar
> >modes. There should be a planar extension anyway supporting
> >things like Get/PutPlane, ScrollPlane and other things that
> >don't make sense on non-planar HW.
> 
> I'm personally of the opinion that said planar functions should work on
> non-planar HW as well, if the non-planar functions will work on planar HW.

Well, I suppose that'll be pretty much up to the person(s) that
writes the extension... 
But I do agree with you there, provided that the P2C routines are 
well optimized. And this goes for the C2P rotines in the normal
Get/Put functions too - there's not much point in including
features noone will use because they're too slow.

But IIRC we have some old Amiga coders (Emmanuel? ;) here with
experience of such things, so it shouldn't be a problem, right?

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |      E-Mail: e94_msu@e.kth.se