u32and should accept err about miden-vm

[bitwalker]

There are actually quite a few instructions that can trap for various reasons, and have this issue. One can work around this specific case by using u32assert.err=ERR on the operands at least, but that's definitely a pain.

I think the larger issue of being able to pinpoint where an error/assert was triggered will need to be solved with debug info. Without debug info, even when you can specify an error code, it is still not particularly helpful in quickly finding the cause. With debug info, we can at the very least provide the location in the original source code, and in cases where we have sources available, we can even render the source snippet that is relevant. More importantly, it would work well across all instructions, whether the error is explicitly triggered with an assert, or implicitly triggered by the semantics of a specific instruction.

Maybe we should add a tracking issue for that, where we can work out the details, and link all these issues to that one?

[hackaugusto]

@bitwalker sounds good to me 👍

[bobbinth]

One note: adding error codes to instructions which also support immediate values may be a bit tricky (or at least may require modifying syntax a bit). So, this may conflict a bit with #1301.

[bitwalker]

@bobbinth I think it could be an either or situation:

u32assert.err=ERR
u32and.0xFF

OR

u32and.err=ERR

In other words, validating the sole operand for the immediate variant is trivially done with u32assert.err=ERR, so we probably don't need to support both at the same time.

[bobbinth]

We could do the same for both operands:

u32assert2.err=ERR
u32and

And this will actually be faster than using u32assert as u32assert is just syntactic sugar on top of u32assert2 (so, u32assert2 takes 1 cycle while u32assert takes 3 cycles).

[bitwalker]

Ah right, always forget about u32assert2!