cgc@humboldtblvd.com wrote:
The big problem with run-time checking is that all modern processors have branch prediction so that when a conditional is reached it will speculatively execute a part of each branch. If one branch has a SIMD instruction that the machine can't handle then the app will segfault with an illegal instruction.
so we cannot use SIMD-compiled code for non-simd machines (if the compiler does not support compilation into SIMD/non-SIMD code: the intel-compiler should support this at least) but of course we can have the generic procedures live next the SIMD-procedures without any problem (on SIMD-platforms). i think it would be easier to code, if you would only have to #ifdef the core altivec function and not worry about the generic function.
The only way that I've seen people do this is runtime module loading like in Photoshop.
which would be a lot to administer...
that in PixDualObj's the naming is rather arbitrary: pix_subtract::processYUVAltivec() vs. pix_chroma_key::processYUV_YUVAltivec()
pix_chroma_key is a dual pix object and follows the YUV_YUV convention of the other dualPix objects. There could be a RGB_YUV oro YUV_RGB version at some point (who knows?).
it was rather the pix_subtract i had in mind with inconsistency. anyhow, bot are pix dual objects processing two YUV-images and the naming scheme is different. just for not forgetting about it.
cgc
anyhow, my changes up till now are only <old> pix_test::processAltivec(){ #ifdef ALTIVEC ... #endif } </old> <new> #ifdef ALTIVEC pix_test::processAltivec(){ ... } #endif
so i think i can safely submit these. (but what for ?;-))
mfg.,as.rd IOhannes