Native Compilation

In the context of the SylComp Project, a "native" compiler will eventually be developed. It will take sources written in the Syl programming language and produces executable programs. It looks like a "normal" compiler ... but not in the context of the SylComp Project. Because the "normal" way will be the precompilation process, with C as an intermediate language.

But because precompilation is naturally slower, a primitive "native" compiler will eventually be developed. The idea is simple : during the debugging stage, speed is needed at the compilation time, not at execution time. During the testing stage (and during real application life), speed is needed at execution time.

So the "native" compiler won't have to be optimized or even fast at all. This will allow an easier building of the tool. It will be allowed to produce slow code, with large size, and even to be incomplete, especially at the beginning of the SylComp Project. It can simply be "embedded" in the precompilation process (making it faster overall) until it is finsihed. During the precompilation process, some (or much) executable code will be directly produced and the rest will be precompiled. And this will be valid in "normal" way or in "live" way (the two options will be available).

OK, when finished, the "native" compiler will be used to produce "live" code (code directly in memory), but even before it is completed, it will be used in "live" compilation via precompilation, because, open you eyes, there will be a "live" (in memory) precompilation process too !

Crazy ? Not at all !!! Precompilation implies two major disk to memory moves. Precompilation in memory implies zero disk writing. This huge saving will allow intensive use of CPU without slowing the overall process.

But the fun part is that, during idle times of the execution of the application all necessary files will be produced at NO TIME cost. But the cutest part is : it will be produced only when needed, i.e. when the compilation succeeds. How many unnessary disk writes are produced by invalid compilation or (early detected) invalid functionality in the application !

One day, all compilers will be doing like that ...