Make linked variables non-volatile by default

[cardillan]

Named links in processors (such as switch1) aren't constant - their value may change (e.g., when the block gets unlinked/linked again or destroyed and rebuilt). They may change from null to non-null and back, or from one instance to another.

Due to this behavior, linked variables are created volatile (they technically are - their values may change by an external process). That precludes some optimizations from taking place, which is a greater concern now that arrays of linked blocks are available due to #324. For example, the following code

linked reactors[] = (reactor1 .. reactor2);

for reactor in reactors do
    reactor.enabled = reactor.@cryofluid > 3;
end;

now produces:

set :reactor reactor1
sensor *tmp3 :reactor @cryofluid
op greaterThan *tmp4 *tmp3 3
control enabled :reactor *tmp4 0 0 0
set :reactor reactor2
sensor *tmp3 :reactor @cryofluid
op greaterThan *tmp4 *tmp3 3
control enabled :reactor *tmp4 0 0 0

The loop got unrolled, but because the links are volatile, they are still copied to a temporary variable so that both operations in the loop are guaranteed to work on the same instance.

For linked variables, this seems to be a bit excessive. I'm pretty sure most mlog authors never even realize these variables are actually volatile and do not take special precaution handling them.

The linked variables will therefore be made non-volatile by default. In rare cases where the logic needs to react to a possible change to the linked block, it will be possible to declare a linked variable volatile to provide the volatility protection.

Note that the sensor instruction is considered deterministic for @size, @speed, @type and @id. However, if the object is a linked variable, it won't be considered deterministic even for those properties, because all of them could change (e.g., by building a logic processor over a micro processor).

[cardillan]

Drat. Forgotten about #303, which is why linked blocks were made volatile in the first place.

There's no easy fix for #303 if the linked variables aren't volatile. Of course, the code can be easily rewritten by assigning the linked variable to DOME after the loop:

while dome1 == null do
    print("Waiting for an overdrive dome to be connected...");
    printflush(message1);
end;
DOME = dome1;

print(DOME.@x, ", ", DOME.@y);

or even by avoiding to store it in a separate variable entirely, which would be even better. But if the user does implement the loop as shown in #303, it may fail, and what is worse, it may fail spuriously, depending on exact timings in the game. That's bad.

It's even worse news for using program parameters to specify linked blocks:

param memory = bank1;

This code is meant to allow users to specify a name of the memory bank to use. But if bank1 gets destroyed and rebuilt (possibly to clear its contents) without restarting the processor, the processor will keep using the old (dead) memory bank. Whoops.

[cardillan]

So I've come up with a solution that should satisfy #303 while keeping the linked variables non-volatile: in conditional instructions (jump and op with a condition), a possible replacement of a variable with a linked block variable will be disallowed. Now the logic like the one in #303 works as intended, while allowing substitution in other cases. The improvements are quite substantial, especially in cases where the linked variables are passed around (such as into inlined functions).

I'll add the possibility to explicitly declare linked variables volatile to force stricter handling should it be necessary in some cases.