ack, this went to the list-admin instead of the list...
james tittle wrote:
...this sounds fine, but the GemSIMD::getCPU() static variable in GemPixUtil.cpp isn't working for me: it always remains 0, whereas GemSIMD::cpuid does show "3"...perhaps we should just make it defined in GemMan like most things, then "extern static int m_simd;" in source files when needed?
well, "m_" is a bad naming scheme, since (i think) it means "member variable" which is definitely not an "extern static".
however, it is very weird that the getCPU() does not work.
...ok, I'm all for doing it if it buys us more flexibility at no cost, even if we rarely use it...
...
...I don't know what the function overhead would be, but isn't it minimal when dealing with a basic accessor function to a c++ class member variable? Would this be a candidate for inline-ing?
is it possible to use an inlined function from an another class?
however, probably the simplest way to go would be to skip the getCPU() alltogether and just directly _read_ the GemSIMD::cpuid. it is not really necessary to start using access control mechanisms now, as such mechanism isn't used throughout the code anyhow; esp. when it causes problems. i guess we can just trust ourselves, that we shouldn't _write_ GemSIMD::cpuid.
however, i would rather use the variable from GemSIMD than to mirror it in GemMan: speed is the same and we should (start to) try to leave member variables where they belong.
and then it might be best to just skip the local "m_simd" alltogether and always directly use GemSIMD::cpuid.
mfg.asd.rt IOhannes