[mad-dev] WIn32 library

Chad Austin aegis@aegisknight.org
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
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...  :)

Chad Austin