Don Wrote: > On 09.11.2011 16:30, foobar wrote: > > Don Wrote: > > > >> On 09.11.2011 09:17, foobar wrote: > >>> Don Wrote: > >>> > >>>> On 07.11.2011 14:13, Gor Gyolchanyan wrote: > >>>>> After reading > >>>>> > >>>>> http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide > >>>>> > >>>>> https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c > >>>>> > >>>>> I had a thought: > >>>>> Why not compile and run CTFE code in a separate executable, write it's > >>>>> output into a file, read that file and include it's contents into the > >>>>> object file being compiled? > >>>>> This would cover 100% of D in CTFE, including external function calls > >>>>> and classes; > >>>>> String mixins would simply repeat the process of compiling and running > >>>>> an extra temporary executable. > >>>>> > >>>>> This would open up immense opportunities for such things as > >>>>> library-based build systems and tons of unprecedented stuff, that I > >>>>> can't imagine ATM. > >>>> > >>>> First comment: classes and exceptions now work in dmd git. The remaining > >>>> limitations on CTFE are intentional. > >>>> > >>>> With what you propose: > >>>> Cross compilation is a _big_ problem. It is not always true that the > >>>> source CPU is the same as the target CPU. The most trivial example, > >>>> which applies already for DMD 64bit, is size_t.sizeof. Conditional > >>>> compilation can magnify these differences. Different CPUs don't just > >>>> need different backend code generation; they may be quite different in > >>>> the semantic pass. I'm not sure that this is solvable. > >>>> > >>>> version(ARM) > >>>> { > >>>> immutable X = armSpecificCode(); // you want to run this on an > >>>> X86??? > >>>> } > >>>> > >>> > >>> I think we discussed those issues before. > >>> 1. size_t.sizeof: > >>> auto a = mixin("size_t.sizeof"); // HOST CPU > >>> auto a = size_t.sizeof; // TARGET CPU > >> > >> That doesn't work. mixin happens _before_ CTFE. CTFE never does any > >> semantics whatsoever. > >> > > > > If I wasn't clear before - the above example is meant to illustrate how > > multilevel compilation *should* work. > > Sorry, I don't understand what you're suggesting here. > > > If you want, we can make it even clearer by replacing 'mixin' above with > > 'macro'. > That doesn't help me. Unless it means that what you're talking about > goes far, far beyond CTFE. > > Take std.bigint as an example, and suppose we're generating code for ARM > on an x86 machine. The final executable is going to be using BigInt, and > CTFE uses it as well. > The semantic pass begins. The semantic pass discards all of the > x86-specific code in favour of the ARM-specific stuff. Now CTFE runs. > How can it then run natively on x86? All the x86 code is *gone* by then. > How do you deal with this? >
What I'm suggesting is to generalize C++'s two level compilation into arbitrary N-level compilation. The model is actually simpler and requires much less language support. It works like this: level n: you write *regular* run-time code as a "macro" using the compiler's public API to access its data structures. You compile into object form plug-ins loadable by the compiler. level n+1 : you write *regular* run-time code. You provide the compiler the relevant plug-ins from level n, the compiler loads them and then compiles level n+1 code. of course, this has arbitrary n levels since you could nest macros. So to answer your question, I do want to go far beyond CTFE. The problem you describe above happens due to the fact that CTFE is *not* a separate compilation step. With my model bigint would be compiled twice - once for X86 and another for ARM. As far as I understand this scenario is currently impossible - you can't use bigint with CTFE. > > >>> > >>> 2. version (ARM) example - this needs clarification of the semantics. Two > >>> possible options are: > >>> a. immutable X = ... will be performed on TARGET as is the case today. > >>> require 'mixin' to call it on HOST. This should be backwards compatible > >>> since we keep the current CTFE and add support for multi-level > >>> compilation. > >>> b. immutable x = ... is run via the new system which requires the > >>> function "armSpecificCode" to be compiled ahead of time and provided to > >>> the compiler in an object form. No Platform incompatibility is possible. > >>> > >>> I don't see any problems with cross-compilation. It is a perfectly sound > >>> design (Universal Turing machine) and it was successfully implemented > >>> several times before: Lisp, scheme, Nemerle, etc.. It just requires to be > >>> a bit careful with the semantic definitions. > >> > >> AFAIK all these languages target a virtual machine. > >> > > > > Nope. See http://www.cons.org/cmucl/ for a native lisp compiler. > > That looks to me, as if it compiles to a virtual machine IR, then > compiles that. The real question is whether the characteristics of the > real machine are allowed to affect front-end semantics. Do any of those > languages do that? >
