I am having a lack of confidence in the assembler code output

[DustyJoeJoe]

(edited for formatting)
It seems that in all cases where the unsigned 'mul' instruction is used, SharpLab shows that an 'imul' is emitted, but that cant possibly be the actual case at runtime or else everyone would quickly notice that unsigned multiplication is broken on an x86/x64 targets.

Repro class contains a function f() overloaded with both uint and int parameters.

public class C {
public uint f(uint x, uint y) => xy;
public int f(int x, int y) => xy; }

C.f(UInt32, UInt32)
L0000: mov eax, edx
L0002: imul eax, r8d
L0006: ret
C.f(Int32, Int32)
L0000: mov eax, edx
L0002: imul eax, r8d
L0006: ret

The first is in error, that should be an unsigned 'mul' rather than the signed 'imul'

Are these just minor translation errors? How extensive is this?

[elgonzo]

No, it's not wrong. Note that the destination for imul is EAX, a 32-bit register (as per .NET, multiplying two 32-bit values yields a 32-bit result).

When multiplying 32-bit values, the differences in the results of imul and mul would only be above the lower 32 bits of the maximally 64 bit wide result. However, since EAX is the destination register, anything above the lower 32 bits of the result will be truncated to fit into EAX. Hence why there is no problem in using imul here.

(Also keep in mind that mul only supports one operand. imul however also supports 2 or 3 operands, which is quite likely the reason why the JIT compiler might generally favor the imul instruction. Remember, the JIT compiler has to operate very fast while producing performant native code; so why waste precious cycles on deciding upon whether to use one over the other instruction if both would yield the same result...)