On 8 January 2012 00:31, Manu <turkeyman@gmail.com> wrote:
On 7 January 2012 22:44, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
The idea is to make versions of code that are environment dependent and never change during runtime, _without_ resorting to if statements. This statement would be valid only inside function bodies.

Examples of such versions may be:
* supported SIMD CPU extensions MMX, SSE, SSE2, etc.
* AMD vs Intel CPU, to use instructions that are not available on both
* different OS versions (XP/Vista/7, Linux kernel versions)

Why that instead of current if statement?
* some additional speed, avoids multiple checks in frequent operations
* making specific executables (f.i. SSE4 only) by limiting set of supported runtime options during compile time

Code example:

void main()
{
   version(rt_SSE4)
   {
       ...
   }
   else version(rt_SSE2)
   {
       ...
   }
   else
   {
       // portable code
   }
}

In this example program checks the supported extensions only once, before calling main(). Then it modifies the function code to make it execute only versions that match.

Runtime version identifiers may be set inside shared static constructors of modules (this implies that rt-version may not be used inside of them). SIMD extensions would preferably be set by druntime with help of core.cpuid.

Code modification mechanism is up to implementation. One that come to my mind is inserting unconditional jumps by the compiler then and fixing them up before calling main().

Additional advantage is possibility to generate executables for particular environments. This may help reduce execucutable size when targeting specific CPU, especially some constrained/embedded system. Also many cpuid checks inside druntime may be avoided.

Just thinking loud :)

... you could just use if() ?
Perhaps detection of these features could be added to the standard library. But I have a feeling it already IS actually (core.cpuid, something I am extremely cynical of)

Sorry, I only half read your post >_<
Many(/most?) systems won't let you write to code memory, so using self modifying code in this way this may be a problem...
Additionally, many modern systems use encrypted code memory, so self modifying code is impossible on these systems. But it's an interesting idea, which I have thought about myself too on occasion.