From: Jim Kjellin <jim.kjellin@masteron.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 7 Aug 1998 10:28:57 +0200

Re: ggiGetPixelFormat and proposed new DirectBuffer scheme

>On Wed, 5 Aug 1998, Marcus Sundberg wrote:
>
>>Btw, doesn't many processors have an instruction to do byte
>>swapping? In that case I suggest we add some byte swapping
>>macros to the API, which will use inline-assembly on supported
>>platforms.
>
>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


You should get another speedup using "xchg ah,al" instead of ror ax,8 since ax
is 16-bit.

>
>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?
>
>>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. ;-)
>
>>For the other modes I suggest we have a GGI_PF_PACKED flag that
>>indicate that _aligned_ buffers uses packed format.
>>After all, <8 bit modes are almost only used on old hardware
>>where speed is always an issue.
>
>>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.
>
>Then again, I'm an emulation techie, and you'd be _really_ surprised just
>how many (All 2D games I've checked actually, including _all_ the Capcom
>and SNK NeoGeo games) use planar graphics chips and 16-color palette-
>mapped graphics. Yes, even Marvel vs. Capcom is 16-color planar sprites.
>             _
>     _     _|_  WolfWings ShadowFlight
>| | | | | | | | wolfwings@lightspeed.net
>| | | | | | | | "Love is a bird,
>|_|_| |_|_| | |  She needs to fly...
> _           /   Let all the hurt,
> \-.______,-'    Inside of you die..." - Madonna, Frozen
>