Dot Net Anywhere

I'm sure you've all read the ECMA-335 document; but for those of you who don't know, this is the document that specifies all the gory details of how .NET works.

When you got to Partition III, page 62 in your bedtime reading I expect you read it, thought nothing very much of it, but then went Hmmm? That's a little odd. Why is it needed exactly?

Because it's a little strange, and I just can't figure out why it's really needed.

Of course, this could be because I'm being a bit slow. If so, please just leave a comment explaining what it's about to put me out of my confusion - I'm not losing sleep over it, but it's close...

The problem is all about conversion instructions. When you write something like this:

int i = ...
byte b = (byte)i;

Then the CIL instruction generated for line 2 will be conv.u1, which tells the CIL runtime to convert whatever is at the top of the stack into a u1, which is the same as the C# byte type.

Simple.

Now, if you had this C#:

checked {
  int i = ...
  byte b = (byte)i;
}

Then the CIL instruction generated for line 3 will be conv.ovf.u1, which tells the CIL runtime to do the same conversion as last time, but do an overflow check as well, so if i doesn't fit in to a byte then an OverflowException will be thrown.

Still simple.

And, futhermore, if you have this in C#:

checked {
  uint i = ...
  byte b = (byte)i;
}

Then the CIL for line 3 will be conv.ovf.u1.un, which tells the CIL runtime to do the another checked conversion, but this time it is told that the source type is unsigned (the .un part of the CIL instruction).

Which still looks well, good, obvious and still simple.

But the thing is - it just isn't needed.

As part of the JIT, the runtime has to do a full stack analysis, and as part of that stack analysis the runtime will already know exactly what type is in the source stack entry. Therefore it can figure out whether it's a signed or unsigned int without any help from the CIL instruction.

And because there is a very small range of types that are allowed to be used as the operand to these conversion instructions, and the range of supported instructions is fixed (i.e. no extensibility is allowed), I cannot think of any situation where theses conv.ovf.<to type>.un instructions would actually be needed. The runtime could always just use the conv.ovf.<to type> instruction and figure out if it's signed or unsigned from the stack analysis.

This entry was posted on Friday, March 27th, 2009 at 12:00 pm and is filed under Inside .NET. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.