http://d.puremagic.com/issues/show_bug.cgi?id=1475

           Summary: allow to use intrinsic math functions (e.g.
                    trigonometry) in CTFEs
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: thecybershadow@gmail.com


The compiler already supports some math functions, like the trigonometric ones, as intrinsics, since it inlines them even when -inline is not specified. It would greatly add to CTFEs if it were possible to call such functions in compile-time functions. For example, Pi could be calculated at compile-time using:

const double PI = atan(1)*4;

Sine tables could also be pre-calculated at compile time, etcetera.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #1 from thecybershadow@gmail.com  2007-09-05 15:06 -------
*** Bug 1476 has been marked as a duplicate of this bug. ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
Of course you can already do this by writing your own CTFE functions to approximate those via Taylor series and the like.  One of the first CTFE demos was a compile-time sqrt function.

But yeh, the compiler has access to a better way to evaluate those functions than running what amounts to an interpreted language, so it would be nice to be able to access it.  I can imagine some sort of plugin system where you'd write some D-code, compile it to a dll, and expose new compile-time functions to the compiler via that dll (much as you write extensions for other scripting languages).  And of course those initial CTFE compiler extensions could be used to compile further CTFE compiler extensions... and so on.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1475
> 
> 
> 
> 
> 
> ------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
> Of course you can already do this by writing your own CTFE functions to
> approximate those via Taylor series and the like.  One of the first CTFE demos
> was a compile-time sqrt function.
> 
> But yeh, the compiler has access to a better way to evaluate those functions
> than running what amounts to an interpreted language, so it would be nice to be
> able to access it.  I can imagine some sort of plugin system where you'd write
> some D-code, compile it to a dll, and expose new compile-time functions to the
> compiler via that dll (much as you write extensions for other scripting
> languages).  And of course those initial CTFE compiler extensions could be used
> to compile further CTFE compiler extensions... and so on.
> 
> 

As long as you aren't cross compiling, The compiler could take the version of the function it's going to put in the obj, plop it down in memory and run it. Why use DLLs?

BCS wrote:
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/issues/show_bug.cgi?id=1475
>>
>>
>>
>>
>>
>> ------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
>> Of course you can already do this by writing your own CTFE functions to
>> approximate those via Taylor series and the like.  One of the first CTFE demos
>> was a compile-time sqrt function.
>>
>> But yeh, the compiler has access to a better way to evaluate those functions
>> than running what amounts to an interpreted language, so it would be nice to be
>> able to access it.  I can imagine some sort of plugin system where you'd write
>> some D-code, compile it to a dll, and expose new compile-time functions to the
>> compiler via that dll (much as you write extensions for other scripting
>> languages).  And of course those initial CTFE compiler extensions could be used
>> to compile further CTFE compiler extensions... and so on.
>>
>>
> 
> As long as you aren't cross compiling, The compiler could take the version of the function it's going to put in the obj, plop it down in memory and run it. Why use DLLs?

Sure, implementation detail.  :-)
There might be some value in having such CTFE libraries be redistributable though?  Probably gets in to security risk territory, though.

--bb

d-bugmail@puremagic.com wrote:
>
> ------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
> Of course you can already do this by writing your own CTFE functions to
> approximate those via Taylor series and the like.  One of the first CTFE demos
> was a compile-time sqrt function.
> 
> But yeh, the compiler has access to a better way to evaluate those functions
> than running what amounts to an interpreted language, so it would be nice to be
> able to access it.

It was my impression that CTFE relies on a fancy version of constant folding, which doesn't make support for any special routines or plugins a really natural fit.  And while it seems like a potentially interesting feature to add, I wonder whether there might be issues related to cross compilation.

Sean Kelly wrote:
> d-bugmail@puremagic.com wrote:
> 
>>
>> ------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
>> Of course you can already do this by writing your own CTFE functions to
>> approximate those via Taylor series and the like.  One of the first CTFE demos
>> was a compile-time sqrt function.
>>
>> But yeh, the compiler has access to a better way to evaluate those functions
>> than running what amounts to an interpreted language, so it would be nice to be
>> able to access it.
> 
> 
> It was my impression that CTFE relies on a fancy version of constant folding, which doesn't make support for any special routines or plugins a really natural fit.  And while it seems like a potentially interesting feature to add, I wonder whether there might be issues related to cross compilation.

Intrinsics are just function that get special handling. Something akin to that could be done for CTFE. Put some special case rules in the engine for sin/cos/tan/etc. that call functions that are part of the compiler.

BCS wrote:
> Sean Kelly wrote:
>> d-bugmail@puremagic.com wrote:
>>
>>>
>>> ------- Comment #2 from wbaxter@gmail.com  2007-09-05 16:10 -------
>>> Of course you can already do this by writing your own CTFE functions to
>>> approximate those via Taylor series and the like.  One of the first CTFE demos
>>> was a compile-time sqrt function.
>>>
>>> But yeh, the compiler has access to a better way to evaluate those functions
>>> than running what amounts to an interpreted language, so it would be nice to be
>>> able to access it.
>>
>>
>> It was my impression that CTFE relies on a fancy version of constant folding, which doesn't make support for any special routines or plugins a really natural fit.  

Check out dmd/src/dmd/constfold.c and interpret.c.   It's basically a little compile time code interpreter.  So yes, it's "fancy constant folding" but "fancy" in this case means "it runs a small interpreted subset of D". For instance there's a function Cat there which apparently does array concatenation.  There's a Div() that does division.  There's no reason there couldn't be a function called "Cos" in there that computed the cosine of its argument at compile time.  But why stop at Cos?

Wouldn't it be nice if users could add other functions like Cos that could be called at compile time?  If they could extend the constant-folding interpreter with new built-in functions written in D or asm or whatever is convenient.  Mr. thecybershadow needs sin and cos, but maybe I need erf(), or maybe I'd like to call BLAS to precompute the LU decomposition of some matrix to use as a constant.  Or maybe I'd like to have a constant initialized with a string representing the current date and time.

So then the question becomes how do you enable constfold.c to call code that it doesn't know about it?  That's why I went for DLLs first. That's how other interpreted languages are usually extended with functionality that can't be expressed in the the language itself, or functionality which is available in foreign code.  But maybe BCS is right that, since what we're talking about *is* a D compiler to begin with, maybe it could access the results of it's own output in a more direct way.  I think that would be tough to implement, though, since code generation happens miles away from where constfold.c is doing its thing.


>> And while it seems like a potentially interesting feature to add, I wonder whether there might be issues related to cross compilation.

I don't think anything more than the usual "feature X not supported on platform Y".

I think the bigger issue is probably that Walter doesn't want the compiler to become a vector for running arbitrary code.  "Hey can you compile this D code for me" should never be a way to pz0wn a computer, at least according to Walter.

> Intrinsics are just function that get special handling. Something akin to that could be done for CTFE. Put some special case rules in the engine for sin/cos/tan/etc. that call functions that are part of the compiler.

Yeh.  Looking at constfold.c, I think Walter could have probably already implemented this for sin/cos/tan in less than the time it took me to write this message.  But if sin/cos/tan go in, what about erf, what about gettimeofday?  where do you stop?  The classic answer to that is "let the user decide" by making it possible to write libraries.

--bb

http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #4 from wbaxter@gmail.com  2007-09-05 19:46 -------
> Sine tables could also be pre-calculated at compile time, etcetera.

The ironic thing is that if you wanted to implement a CTFE sine function right now, table lookup is probably the most reasonable way to do it.


Anyway, I like the general idea, and I think the same thing goes for many other things, like string formatting functions.  There's a perfectly fine string formatter in std.string.format.  It's a shame the compiler isn't able to invoke it during compile time.


-- 

d-bugmail@puremagic.com wrote:

> The compiler already supports some math functions, like the trigonometric ones, as intrinsics, since it inlines them even when -inline is not specified. It would greatly add to CTFEs if it were possible to call such functions in compile-time functions. For example, Pi could be calculated at compile-time using:
> 
> const double PI = atan(1)*4;
> 
> Sine tables could also be pre-calculated at compile time, etcetera.

Quoting http://gcc.gnu.org/gcc-4.3/changes.html
"The GCC middle-end has been integrated with the MPFR library. This allows
GCC to evaluate and replace at compile-time calls to built-in math
functions having constant arguments with their mathematically equivalent
results. In making use of MPFR, GCC can generate correct results regardless
of the math library implementation or floating point precision of the host
platform. This also allows GCC to generate identical results regardless of
whether one compiles in native or cross-compile configurations to a
particular target. The following built-in functions take advantage of this
new capability: acos, acosh, asin, asinh, atan2, atan, atanh, cbrt, cos,
cosh, drem, erf, erfc, exp10, exp2, exp, expm1, fdim, fma, fmax, fmin,
gamma_r, hypot, j0, j1, jn, lgamma_r, log10, log1p, log2, log, pow10, pow,
remainder, remquo, sin, sincos, sinh, tan, tanh, tgamma, y0, y1 and yn. The
float and long double variants of these functions (e.g. sinf and sinl) are
also handled. The sqrt and cabs functions with constant arguments were
already optimized in prior GCC releases. Now they also use MPFR."

So GDC might be able to do this, if ported to GCC 4.3 backend and it patches some frontend parts :-)

Maybe there is a similar solution with a different license to be able to use that in DMD.


Best Regards

Ingo Oeser