Fwd: [GEM-dev] Re: [GEM-cvs] GemSIMD

[IOhannes m zmoelnig]

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