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