On 12/18/2012 08:26 PM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
quality-of-implementation issue.
Well, that much is obvious; I was just wondering if the current
implementation will require too much effort to make it work with native
code CTFE.
Besides the effort required to rework the existing code (and perhaps
the cross-compiling issue, though I don't see it as a major issue),
Um, it does introduce major support costs for porting to different CPU
targets.
[...]
Could you elaborate? In my mind, there's not much additional cost to
what's already involved in targeting a particular CPU in the first
place. Since the CPU is already targeted, we generate native code for it
and run that during CTFE.
...
The generated native code would need to be different in order to support
proper error reporting and dependency handling. (The generated code must
be able to communicate with the analyzer/jit compiler.)
The compiler does not have the full picture during analysis. It needs to
figure out what information a CTFE-call depends on. The only way that
works in general is running it.
Eg:
string good(){
mixin(foo(0,()=>good())); // ok, delegate never called
}
string bad(){
mixin(foo(1,()=>bad())); // error, need body of bad to generate
body of bad
}
string foo(bool b, string delegate() dg){
if(b) return dg();
return q{return "return 0;";};
}
