>Wouldn't this make CPU flags useless?

They would, but I agree with RISC-V here, CPUs should not rely on them in the first place.

I do not understand your argument about branches, how would it hinder the jump instructions?

We still would need separate "wrapping" instructions (e.g. for implementing bigints and cryptographic algorithms), but they probably could be limited to unsigned operations only.

>I can't wait to tell CPU to JMP NaN.

How is it different from jumping to null? If you do such jump, it means you have a huge correctness problem with your code.

▲ lock1 3 days ago | parent [-]

  > I do not understand your argument about branches, how would it hinder the jump instructions?

Extra set of logic for handling NaN cases? I don't think it's impossible, just kind of less intuitive. Jump instruction using integer w/o NaN always valid, while NaN-able integer sometimes invalid (ignoring whether the memory address can be accessed).

	▲	newpavlov 3 days ago \| parent [-]
		For absolute jumps you don't need extra logic, since CPUs could declare the last page always unmapped, so such jumps would always result in a page fault (similarly to the null page on most systems). For relative non-immediate jumps the added logic is extremely simple (hardware exception on NaN) and should not (AFAIK) hinder performance of jumps in any way.