Values handling by the compiler/optimizer

[cardillan]

Mindcode currently defines several properties on logic arguments (i.e. isConstant(), canEvaluate(), isVolatile()) which are poorly defined and inconsistently used. Furthermore, due to expression evaluation shared with processor emulator, some of these categories serve two purposes. This is an attempt to rectify the situation.

It appears that there are four distinct categories of values that can appear in a program.

Compile-time constants

Represents a value which is compile-time constant and can be compile-time evaluated. In most cases, these would be numeric/boolean/null literals. Defensive copies of these values need not be made.

Some built-ins could be handled as compile-time constants as well, for example @pi, @e or @ctrlProcessor.

Notes:

• A string literal isn't a compile-time constant in this classification. A special treatment of string literals ensures they can be evaluated at compile time, but optimizers won't process them. If optimizers were allowed to evaluate string expressions, the program behavior would depend on particular optimization happening, which wouldn't guarantee consistent results.
• Compile-time evaluation of expressions over color literals could be problematic, since color literals are encoded into a non-standard floating-point representation. There's a risk that the result of an expression over a color literal could not be precisely encoded into an mlog literal. If this turns out to be the case, color literals will be reclassified as run-time constants.

Run-time constants

Represents a value which is a run-time constant, i.e. it is known the value doesn't change during program execution, but the actual value isn't known and thus can't be compile-time evaluated. The guarantee of stability means defensive copies of these values need not be made.

Examples of values which are runtime constant:

• a string literal,
• a parameter,
• built-in variables except the volatile ones. This includes almost all built-in variables, such as @this, @thisx, @coal and so on. Even LAccess built-ins (such as @dead or @controlled) are runtime constants - of course the values returned by using them with op sensor aren't (the problematics of evaluating op sensor will be handled by specialized code outside of these general categories).

By their nature, linked blocks aren't runtime constants, as they may change due to blocks being unlinked or destroyed. This makes them volatile in general. Current implementation handles them (wrongly) as runtime constants.

Mutable values

Represents a value which is not run-time constant, but only changes through an explicit action of the program. These are regular variables. In essence everything which doesn't fall into any of the other categories ends up here.

Defensive copies of these values are made by the compiler. When not needed, they should be removed by the optimizer.

Volatile values

Represents a value which can change independently of the program/processor. This includes:

• some built-ins, such as @time, @links, @unit (!!)
• variables explicitly declared as volatile (for use with the sync instruction, although this mechanism isn't currently well understood)
• linked blocks (in some future version)

Defensive copies of these values are made by the compiler. They should never be removed by the optimizer.

Note: @unit is regarded as volatile, because it's value is changed as a side effect of ubind, and this information is currently not available through instruction metadata. It would make sense to let the compiler/optimizer know about this. (Perhaps a UbindInstruction implementation could be made, which would provide correct metadata. At the same time @ubind would have to be reclassified as a variable, which also makes sense.)

Values stored in memory blocks are also volatile by design, and Mindcode currently handles them as such, except cached external variables. A mechanism for better control of external storage handling is in the wish list.

[JeanJPNM]

I believe that string literals can be treated as compile-time constants, since most operations on them either use value equality, or cast them into a number (they always become 1 when this happens).

[cardillan]

You're probably right about string literals, and marking them as compile-time constant is probably the best solution. I just feel uneasy making this compile-time evaluation since I know it is wrong. Perhaps a warning could be emitted.

[JeanJPNM]

Can you provide an example in which the compile-time evaluation involving strings would be different from the runtime evaluation?

[cardillan]

I actually meant that any runtime operation involving strings seems to point to a buggy - incorrect - source code. However, examples where strings need to be processed specifically by Mindcode are possible to construct:

var A = "A";

for i in 0 .. 3 do
    print(A + i);
end;

printflush(message1);

This compiles, the loop get unrolled and the program outputs 1234 as expected. However, at certain phase during the unrolling, there will be an op add tmp "A" 0, and I have an optimization which replaces idempotent operations with the value itself. In this case the instruction could be replaced by set tmp "A". The optimized output would then be A234. This doesn't happen now, because strings are exempt from this particular optimization.

(This optimization does change the semantics of the code, which is why I explicitly defined operator behavior in Mindcode differently from mlog. A "treatise" about this is here: https://github.com/cardillan/mindcode/blob/devel/doc/syntax/SYNTAX-2-EXPRESSIONS.markdown#null-values-in-expression)

[cardillan]

Turns out this is a problem in current version of Mindcode as well:

for i in 0, "A", 2 do
    print(i + 0);
end;

printflush(message1);

prints 0A2 instead of 012, whether the loop is unrolled or not.

So I'm going to proclaim all expressions using String values, except comparison and string literal concatenations, as undefined in Mindcode and call it a day.

It might change when types are introduced, as I might only apply the optimization causing this when the operands are of explicit numeric types.