www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1475] New: allow to use intrinsic math functions (e.g. trigonometry) in CTFEs

reply d-bugmail puremagic.com writes:
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.


-- 
Sep 05 2007
next sibling parent d-bugmail puremagic.com writes:
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. ***


-- 
Sep 05 2007
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
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.


-- 
Sep 05 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
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?
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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.
Sep 05 2007
parent reply BCS <BCS pathlink.com> writes:
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.
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Sep 05 2007
prev sibling next sibling parent Ingo Oeser <ioe-news rameria.de> writes:
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
Sep 06 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #5 from clugdbug yahoo.com.au  2009-04-06 03:11 -------
The intrinsics were included in constant folding in DMD2.005.
It'd be good to have a way of detecting CTFE inside a function, so that the
other math functions could be made CTFE-able (many of them use asm) -- but
that's a different issue.


-- 
Apr 06 2009