I realized that I need to qualify that this issue isn't a problem with Octave's implementation of error handling. Instead, the issue lies in the language, and the fact that almost every operation can cause an error.
In Octave correctly handling errors is annoying. For an example, let's look at a simplified implementation of binary operators in the interpreter.
octave_value retval; octave_value lhs = // compute lhs if (! error_state && lhs.is_defined ()) { octave_value rhs = // compute rhs if (! error_state && rhs.is_defined ()) retval = ::do_binary_op (op_type, lhs, rhs); } return retval;Notice that after every operand is computed, the error state must be checked. Take the follow statement
a = (a + b) / c;When converted into a linear SSA form we get
block0: temp0 = a0 + b0 check_error block1, done block1: temp2 = temp0 / c0 check_error block2, done block2: c1 = temp2 goto done done: c2 = phi (block0: c0, block1: c0, block2: c1) # yield a0, b0, and c2 as resultsNotice that the phi merge function requires an entry for every operation. Furthermore, each variable that is defined must be represented in the done block. At the worse case, each statement could define a new variable leading to O(n^2) space complexity. (where n is the statement count in Octave)
However, in practice the number of variable should be low compared to the number of lines. As a test, I automatically generated a 500 line program consisting of scalar addition statements like
i1 = i0 + i0;It looks like the compile time stays within reasonable bounds.
No comments:
Post a Comment