Runtime version statement

[Manu]

On 8 January 2012 00:31, Manu <turkeyman at gmail.com> wrote:

> On 7 January 2012 22:44, Piotr Szturmaj <bncrbme at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120108/945265e8/attachment.html>