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' :-)
Statement expressions are easy to convert. You just make them inline functions (which gcc supports too).
The assembly stuff should have been relatively easy to port, because VC++'s __asm lets you access C expressions from the assembly. I'm not too experienced with x86 assembly so I was just trying to hand convert the stuff over. Of course, it didn't work, so I just gave up. I'll deal with it later. :)
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.
I talked with a friend from Iowa State (he's a pretty crazy assembly guru, worked for AMD last summer) and he said that VC++ really sucks at optimizing 64-bit integers.
I'm using MAD because it's GPL and it works. :) It takes me between 3 and 4 percent of my CPU to decode an MP3, which is more than acceptable. FPM_64BIT took between 14 and 20... If you want to help me fix up FPM_INTELVC... :)