Assertions Feature Request

I'm suggesting 16 different assertions, with 8 corresponding to conditional opcodes and 8 to their logical negations. Each "positive assertion" would be of the form "assert_x(arg1, arg2)," where 'x' is the third letter of one of the conditional opcodes (b, c, e, n, etc.), and 'arg1' and 'arg2' are in standard operand form (register, [register], literal, etc.). These assertions would not be assembled into binary, but would instead be used for unit tests in that they would "fail" during emulation if the conditional opcode with which they were associated would have skipped given the values of its operands. "assert_not_x" would behave in the opposite fashion.

For example:

SET A, 5
SET [B + 1], C
assert_l(A, [B + 1])
...

The 'l' corresponds to IFL, and the assertion would fail, halt the DCPU, and print an error message unless the value of A was less than that of [B + 1].

Something like assert_not_g(A, [B + 1]) would fail unless A was less than or equal to [B + 1].

I realize there is some redundancy, such as with assert_e and assert_not_n, but it would be inconvenient for the programmer to have to remember which instructions had corresponding negative assertions and which did not.

[HerobrinesArmy]

This one will take a bit of work, particularly since I'll need it to be able to evaluate value expressions without assembly, so I'll probably push this into the post-Release 1 features.

Hmm... I suppose I could attach each assert as metadata, actually assembled to the related IFx instruction, on the next AssemblyLine and have the DCPU, when it is being run with asserts turned on, retrieve the line at PC prior to ticking and, with any asserts attached to that line, do a pseudo-tick for them and evaluate the outcome. That actually shouldn't be too much work at all... 👍