Reply To: C semantics and the Mill

I hope you don’t mind if I continue on this thread despite it being a bit old. I thought it was fitting here since it is about C semantics.

I was looking recently at what C has “undefined”. One of these is when a bitcount for a shift is larger than the width of the value being shifted.
If I interpret the Wiki correctly, a shift instruction’s result would be marked “NaR” (Not a Result) if the bitcount (from a belt operand) was too large — even if the instruction is not one of the excepting instructions.
Did I get this right?

Could the NaR flag be discarded (not throw a CPU exception) and code continue using an erroneous result — and what would that be?

I agree that C functions returning structs just to return multiple results is ugly. Syntactic sugar would help everyone I think. But that’s really a compiler thing and not a chip thing.

In Apple’s Swift programming language, multiple return values from functions are structs — from the viewpoint of the LLVM-based parts of the compiler.
However.. the calling conventions used by Swift on ARM and x86-64 do specify that small structs be passed as multiple values in registers.
The Mill’s compiler’s calling convention for C could be similar but for belt positions instead of registers.