Conditions in data references

[dgpv]

          I am thinking about using branch conditions to show data references.

For example, now it is like this:

 ./bsst-cli
0 lessthan if 5 else 10 endif // =>x
add

...

Enforced constraints per path:
==============================

When LESSTHAN(wit0, 0) = 1 :: [IF @ 2:L1]
-----------------------------------------

        BOOL(ADD(&x, wit1)) @ END

When LESSTHAN(wit0, 0) = 0 :: [IF @ 2:L1]
-----------------------------------------

        BOOL(ADD(&x', wit1)) @ END

...

================
Data references:
================

        x = 5
        x' = 10

But it can be made into

...

BOOL(ADD(&x, wit1)) @ END

...

================
Data references:
================

When LESSTHAN(wit0, 0) = 1 :: [IF @ 2:L1]
-----------------------------------------
        x = 5

When LESSTHAN(wit0, 0) = 0 :: [IF @ 2:L1]
-----------------------------------------
        x = 10

Or even

       x = Case
           When LESSTHAN(wit0, 0) = 1
            And LESSTHAN(wit1, 0) = 1

           => SUB(wit2, 5)

           When LESSTHAN(wit0, 0) = 1
            And LESSTHAN(wit1, 0) = 0

           => ADD(wit2, 1)

           When LESSTHAN(wit0, 0) = 0
            And LESSTHAN(wit1, 0) = 1
           Or
           When LESSTHAN(wit0, 0) = 0
            And LESSTHAN(wit1, 0) = 0

           => wit2

I don't think it will be a good idea to use 'default case' here, like Else or Otherwise etc.

Maybe only use it for the case when there is only two possible values for the reference, and there is no invalid branches. Because if some branches always fail, using 'defult' case can end up masking this information (that some part of the range of the condition is not there). Of course the failed cases will be shown later in the report, but I think this 'masking' can still lead to confusion. Maybe just include <FAILURE> as a special value for these branches...

The last two conditions that are joined by Or can be simplified to just LESSTHAN(wit0, 0) = 0, because the full range of LESSTHAN(wit1, 0) is included in both cases. Simplifying this would require to track possible ranges of the conditions, which is not tracked now. Branches can have non-binary conditions, like for PICK or other opcodes that can take variable number of arguments.

Originally posted by @dgpv in #33 (comment)