Design new CTFE engine - A preview

Hello,

I have been working on a rewrite of the CTFE interpreter in D.

As D is a complicated language with many constructs and complicated corner-cases that have to be handled correctly, I did not want to rip out the old Interpreter entirely.

Rather I am hooking the engine in at a point where the lowered function is evaluated and see if my engine can evaluate it.
If it can it will do so and return the result.
If it cannot it will give back a null value which signals to the old Interpreter to  take over instead.

This way I can incrementally improve CTFE and still provide a fully functioning compiler.

The AST is already processed into a canonical from when it arrives at the point where I hooked the evaluator in.

This means it is in backend friendlier form.
And much of the syntactic sugar is already removed.

I am translating this canonicalized AST into linear byte-code and hand it off to a byte-code interpreter.

The byte-code itself is almost completely decoupled from the part that processes the AST, thus making it possible to provide different interpretation backends, and to change the byte-code-format at any point without having to rewrite the AST processing.

Thus I keep the byte-code API fairly clean and minimal.

currently there are 15 calls the generator/evaluator backend has to support

Lt3
Gt3
Eq3


Add3
Sub3
Mul3
Div3

And3
Or3
Lsh3
Rsh3

JmpZ
JmpNZ
JmpTrue
JmpFalse


These are enough to represent a large body of code.
And easy implementations should be possible for most of the targets out there.

However I suspect that I will need add at least

Call
and
Return

In order to support function calls.

I will also need to find and document all assumptions I make about the capability  of a backend.

For example it has to support 32bit integer operations. It also has to be able to work with 32bit aligned data.