MSIL - Wie funktioniert der Opcode conv.ovf.u8.un?

Question

Warum msil Programm:

.assembly Test {} 
.method private hidebysig static void Main(string[] args) cil managed 
{ 
    .entrypoint 
    // Code size  21 (0x15) 
    .maxstack 2 
    .locals init ([0] int32 a, 
      [1] int32 b) 
    IL_0000: nop 
    IL_0001: ldc.i4.m1 
    IL_0002: stloc.0 
    IL_0003: ldloc.0 
    IL_0005: conv.ovf.u8.un 
    IL_0006: stloc.1 
    IL_0007: ldloc.1 
    IL_0008: call  void [mscorlib]System.Console::WriteLine(uint64) 
    IL_000d: nop 
    IL_000e: call  valuetype [mscorlib]System.ConsoleKeyInfo [mscorlib]System.Console::ReadKey() 
    IL_0013: pop 
    IL_0014: ret 
} // end of method Program::Main 

Schreibleistung: -1?

conv.ovf.u8.un - konvertieren Sie unsigned in ein unsigned Int64 (auf dem Stapel als int64) und werfen Sie eine Ausnahme bei Überlauf.

Also -1 (int32) behandelt als unsigned ist 4294967295 (uint32) und es behandelt wie uint64 ist 18446744073709551615.

Ecma Dokumentation sagt: http://postimg.org/image/4326dsysx/

So wieder -1 (int32) in binärer 111111111111111111111111111111111 ist. Nach der Umwandlung durch Nullverlängerung ist es 000000000000000000000000000000000111111111111111111111111111111111 und es ist wieder 18446744073709551615.

Answer 1

ich es getestet und auf meinem System es nicht gedruckt -1 aber 18446744073709551615.
Könnten Sie mehr Informationen über Ihr System zur Verfügung stellen (Plattform, .NET/CLR-Version) oder versuchen Sie einfach erneut die ausführbare Datei zu bauen mit ilasm ?

Answer 2

ich ganzes System aktualisiert, neu gestartet und jetzt funktioniert es richtig. Es ist sehr interessant, weil ich vorher Probleme mit anderen Opcodes habe, z. conv.ovf.u8 und jetzt ist alles ok.

Danke für Tipps!