[mad-dev] WIn32 library
Thu, 31 May 2001 11:21:36 -0800
> > 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
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
> > 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... :)