Re: [pygame] MMX Transform for Win32

[Richard Goedeken <SirRichard@xxxxxxxxxxxxxxxxxxxxxxx>]

Lenard Lindstrom wrote:
> Giving this more thought it is too late in the Pygame release cycle to 
> add an Intel translation of the assembly code to Pygame 1.8.0. This 
> would lead to four versions of each of four subroutines. The resulting 
> conditional expressions will be ungainly. Also the Intel translations 
> will need properly tested. The AT&T assembly code has been out for 
> awhile and shows no problems. For the moment a MinGW compiled 
> transform.pyd can be used in the Windows binaries for Pygame 1.8.0. But 
> it is desirable to translate the AT&T assembly code to Intel at some 
> point in the future. If the gcc x86 C compiler truly handle VC style 
> inlined assembly, including C identifiers within assembly code, then the 
> AT&T code can be entirely replaced. Otherwise separate AT&T and Intel 
> versions will need to be maintained. It has also been discussed to 
> reintroduce the original SSE versions of the routines. But this will 
> involve a rethink on how MMX/SSE support is provided.

A good portion of the work that I do in my day job involves writing MMX/SSE2 
code, most of which needs to run in both Win32 and Linux, and on both 64-bit and 
32-bit systems.  So I deal with this problem a lot.  To my knowledge, there is 
no effort to add an Intel-style inline assembly capability to GCC.  If someone 
knows of such an effort then I would be very interested to learn about it.  I 
agree that writing, testing, and supporting 2 or 3 implementations of the same 
routine with #ifdefs really sucks.

The other way I deal with this problem at work is to use an external assembler 
such as NASM.  This can be made to work under both Linux and Win32 with the same 
assembly source code quite easily.  The disadvantage with this approach is that 
it introduces another tool dependency.

Richard