Predefined Version expansion

[janderson]

Don Clugston wrote:
> Dan wrote:
>> Dave Wrote:
>>> Just a thought for D -- add a global CPU type to the D standard 
>>> runtime that is set during initialization (i.e.: in Dmain) that can 
>>> be used by user code like BLADE and by the compiler itself for 
>>> (future) processor determined optimization branches.
>>>
>>> Actually, I'm kind-of surprised one isn't there already (or is it?).
>>
>> There is already a cpu variable/object/module or something within the 
>> phobos library which provides cpu related information.  The problem 
>> being discussed is that this information is stored and branches are 
>> made based on the cpu type during *runtime*.
>>
>> If instead, it was pre-determined during compile time, these branches 
>> could be optimized out.  Since version() is designed to perform 
>> precisely this function, it makes sense to continue to use version() 
>> to identify and target cpu's during compile time.
> 
> Yes. All that's required is for the spec to include standard names for 
> the CPU types. I don't think any DMD compiler changes are required.
> 
> How about these:
> 
> X86_MMX   // necessary? (MMX is dead technology).
> X86_SSE
> X86_SSE2
> X86_SSE3
> X86_SSSE3 // is this really necessary?
> X86_SSE4
> 
> Only change would be that the GDC compiler for X86_64 should set all of 
> the above.
> Right now, the predefined version identifiers cannot be set from the 
> command line, so eventually the compiler would need a CPU switch to 
> control them - it would specify that the compiler has freedom to use 
> recent opcodes, but of course it could continue to generate exactly the 
> same code. I think such a switch would be necessary for supporting the 
> 3- and 4-element array types with swizzle functions discussed recently.
> 
> However, if we all agreed to use the same set of version identifiers, we 
> can get going immediately.

I've done this manually with a set of DLL's before.  Basically the exe 
would be a tiny file that would call the correct DLL at startup.  You 
would only compile all the program DLLs when distributing the program. 
This way you only branch when you pick the correct CPU at application start.

Now I should mention Michael Abrash (of which I'm a big Fan) used a 
technique to simulate DirectX7 effeciently in software where he created 
CPU code on the fly for different CPU's.  It didn't suffer from cache 
misses (which is typical in self modification programs) because the 
generated data was consumed a frame later.

If the compiler was able to make simple changes to the code at startup 
like a virtual machine or Interpreter that would be cool.  You could in 
essence consider it as a compressed version of the DLL stradigie I 
employed, except you'd be able to make use of combinations more 
effectively and optimize for AMD, Intel chips ect...

-Joel