En réponse à Andre armccurdy@yahoo.co.uk:
--- Chad Austin aegis@aegisknight.org wrote:
Of course, there were several other minor changes. One of these days I'll build a patch and submit it to Rob.
You wouldn't be the first to suggest fixes for this.... So far Rob seems quite happy to stay gcc specific though :-)
One last note... I *attempted* to port FPM_INTEL to VC++ (renaming it to FPM_INTELVC)... However, my ports of the asm() directives never worked. :)
For FPM_INTEL, apart from MAD_F_MLX, all the macros are 'statement expressions' which are a sort of cross between a macro and an inline function, and are very gcc specific. The fact that they also contain gcc specific inline assembler means getting them to run with another compiler requires more of a 'rewrite' than a 'port' :-)
If only I could get a Makefile with cygwin, I could start trying to get MAD working in VC++. But I downloaded the latest cygwin version and when I run ./configure it tells me that GCC is present but cannot make excutables (!). Maybe that's my cygwin installation that is wrong. But if anybody could send me the working Makefile (for each dir) that would save me that time ;)
Also, FPM_64BIT was about four or five times slower than FPM_DEFAULT. So if you're compiling with VC++, you *definitely* want FPM_DEFAULT.
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
VC++ can deal with 64bit integers there is a __int64 MS specific type. (which won't work with Borland compilers :( ) Otherwise assembly (MMX) could help.