Tangential note: I sometimes wish that signed integers were symmetrical. i8 would represent the range of [-127 to 127] with 0xFF representing NaN. Any operation which can not be computed (division by zero, overflows, operation with another NaN, etc.) would result in NaN. For further symmetry we could do the same for signed integers as well.

Yes, it's possible to encode such types manually, but it will not be efficient since CPUs do not natively support such operations.

▲ lock1 3 days ago | parent | next [-]

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.

▲ zokier 3 days ago | parent | prev [-]

That sounds surprisingly reasonable idea for signeds. Less so for unsigneds though. Has there been any architecture doing anything like that?

	▲	newpavlov 3 days ago \| parent [-]
		I can not name an ISA with such instructions out of my head. As for unsigned integers, as I mentioned in the other comment, we probably need two separate instruction sets for "wrapping" and NaN-able operations on unsigned integers.