--- 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' :-)
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.
Andre --
____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie