I’m currently working on the next generation of the SystemJ compiler (codenamed ‘Conquer’) and we have some exciting developments coming in the new version. This blog posts runs through a few of these improvements and should give an indication of where the language is heading.

Due to the length of this post is has been split into several installments, which will be published one by one over the coming weeks.

1. Faster Compilation and Execution

The Conquer compiler is much faster than the current SystemJ compiler. This is because it has been rewritten from the ground up in C++ rather than Java and has internal optimisations which reduce the amount of deep-copying of objects which are done. Current performance is suggesting that compilation times will be reduced to fractions of a second for moderately sized programs (e.g. ~0.02s for PCABRO). Obviously, the compile time is subject to change as the compiler is not yet complete, but the increase from the current usage is not expected to take the compile time above a few tenths of a second.

Conquer also aims to increase the performance of the language during execution. There are several optimisations in the compilation of the language which should improve performance. The most significant of these is eliminating the use of dynamic signal locking. In the new compiler programmers will be able to choose how signals will be broadcast (either delayed or instantaneous). Delayed signals are faster, but not as expressive as instantaneous signals, however in cases where cyclic signal dependencies exist delaying the relevant signals will remove the need for dynamic signal locking. Automatic identification of such signals is targeted for Conquer.

There are also many small improvements in the language, designed to improve performance, such as use of native types for signal presence (rather than embedding within a Java object) and use of threads by default.

2. Modular Compilation

Conquer will also add significant new support for modular compilation, with clock-domains and reactions being able to be externally compiled and imported into other SystemJ programs. A new technique for specifying which portions of the intermediate code representation (known as [A]GRC) are being reused, has been developed specifically for this. Also, optimised [A]GRC representations of precompiled objects will be stored in a custom XML format to allow them to be loaded to create a cohesive GRC graph in programs which call upon them.

These new modular compilation features, when taken with some of the changes to the language structure and syntax (see below) will allow for a standard library of useful clock-domains and reactions to be provided in the SystemJ runtime.

In the next installment I will detail the new compiler architecture which will allow us to compile for several different host languages.