Replies: 1 comment 4 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
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,@eor@ctrlProcessor.Notes:
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:
@this,@thisx,@coaland so on. Even LAccess built-ins (such as@deador@controlled) are runtime constants - of course the values returned by using them withop sensoraren't (the problematics of evaluatingop sensorwill 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:
@time,@links,@unit(!!)syncinstruction, although this mechanism isn't currently well understood)Defensive copies of these values are made by the compiler. They should never be removed by the optimizer.
Note:
@unitis regarded as volatile, because it's value is changed as a side effect ofubind, and this information is currently not available through instruction metadata. It would make sense to let the compiler/optimizer know about this. (Perhaps aUbindInstructionimplementation could be made, which would provide correct metadata. At the same time@ubindwould 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.
Beta Was this translation helpful? Give feedback.
All reactions