Runtime version statement

Manu turkeyman at gmail.com
Sat Jan 7 14:31:37 PST 2012


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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120108/d857ea53/attachment.html>


More information about the Digitalmars-d mailing list