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?
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?
