Hello Andrei,

>> bearophile wrote:
>> 
>>> 
>>> module sse; mixin(import("shared_module_code.dd"));
>>> 
>
> I must be missing something - why isn't
> 
> import shared_module_code;
> 
> good?
> 
> Andrei
> 

the code generator needs to be run on the code more than once.

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> bearophile wrote:
>>> Walter Bright:
>>>> import std.cpuid; import sse; import nosse; ... if
>>>> (std.cpuid.sse2()) sse2.foo(); else nosse2.foo();
>>>
>>> I think that solves my problem, thank you. It's a simple solution
>>> (maybe I didn't think of it because I use bud that compiles all the
>>> program in one go).
>>>
>>> I presume that usually the D code in the sse and nosse modules is the
>>> same, it's just compiled in two different ways, so the two modules
>>> may just contain two lines of code as:
>>>
>>> module sse; mixin(import("shared_module_code.dd"));
>>
>> That's one way to do it.
>>
> 
> I must be missing something - why isn't
> 
> import shared_module_code;
> 
> good?
> 
> 
> Andrei

The shared code has to be compiled with two sets of compiler switches, resulting in two distinct modules with different ModuleInfo, TypeInfo, and so forth. You can't do that with import.

On Tue, 03 Feb 2009 00:31:17 +1300, bearophile <bearophileHUGS@lycos.com> wrote:

> This comes after a small discussion I've had in the #D IRC channel.
>
> I have seen that the LDC compiler is much more efficient if you use SSE(2) extensions, while it's not much efficient if you don't use them (GCC/GDC don't seem so much sensitive to the presence of the SSE extensions).
>
> I often have to switch from an old and a new CPU, so if I compile with SSE2 extensions the program doesn't run on the old CPU, while if I don't use them, I sometimes have a program that goes much slower on the newer CPU.
>
> So, it may be useful to have a way to build executables able to run well on both CPUs (Apple has done something like this two or more times in the past). There are several ways to do this, a solution is to compile just critical functions for different CPUs, but that may require compiler support.
> My executables are generally small, so doubling their size isn't a problem. So a simple solution is to bundle two whole executables into an executable and add a small header that looks for the current CPU, and runs the right executable.
>
> Notice that the problem I have shown isn't limited to SSE2, it's more common, for example in the close future you may want code compiled for the GPU and/or CPU, etc.
>
> Bye,
> bearophile

Is this the sort thing you are looking for: http://www.songho.ca/misc/sse/sse.html