Wouldn't this make CPU flags useless? I think it would complicate branch instructions too, as most modern CPUs tend to use integer operations for branching.

Also, this in-band signaling probably would invite something similar to `null` mess in type systems. I can't wait to tell CPU to JMP NaN.

▲ newpavlov 3 days ago | parent [-]

>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.