On Sat, Jan 07, 2012 at 12:49:46AM +0100, Alex Rønne Petersen wrote: > On 07-01-2012 00:37, Jonathan M Davis wrote: > >On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: > >>Most likely those functions are just implemented using inline > >>assembly, therefore not usable in CTFE. > > > >Yeah, several functions in std.math use inline assembly. So, for them > >to be able to be used at compile time, either the compiler must be > >expanded to be able to run asm statements at compile time (which may > >or may not be planned and may or may not be reasonable), or those > >functions need another branch (using __cfte in an if condition) which > >doesn't use assembly. Or I suppose that if the extra check for __ctfe > >isn't considered particularly acceptable (after all, they're already > >using assembly), then separate functions meant specifically for CTFE > >would be necessary. [...]
>From my limited experience, I'd say that having two versions of the function is probably the least painful way to go. [...] > Allowing asm in CTFE would probably be way more work than it's worth. > You'd basically need full-blown analysis of x86 assembly plus an > interpreter. Even then, x86 is not typed, so it's going to be a major > pain... [...] I admit I've no idea how the D compiler implements compile-time evaluation, but is it possible for the compiler to actually emit code for compile-time functions containing asm blocks and, say, execute it in a sandbox, and read the values out from the machine registers? Or does this create more problems than it solves? T -- Verbing weirds language. -- Calvin (& Hobbes)