Unbox IL instruction question

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Ben R. - 26 Jul 2006 20:08 GMT

Thought this was a better forum for this question:

Hi,

I'm referring to:

http://msdn2.microsoft.com/en-us/library/system.reflection.emit.opcodes.unbox.aspx

There's a lot of stuff here that doesn't make sense to me. This page states:

A value type has two separate representations within the Common Language
Infrastructure (CLI):

A 'raw' form used when a value type is embedded within another object.

A 'boxed' form, where the data in the value type is wrapped (boxed) into an
object so it can exist as an independent entity.

The unbox instruction converts the object reference (type O), the boxed
representation of a value type, to a value type pointer (a managed pointer,
type &), its unboxed form. The supplied value type (valType) is a metadata
token indicating the type of value type contained within the boxed object.

Unlike Box, which is required to make a copy of a value type for use in the
object, unbox is not required to copy the value type from the object.
Typically it simply computes the address of the value type that is already
present inside of the boxed object.

________________

Now a few things: It mentions an "object reference" and a "value type
pointer." What is the difference here? Aren't they both pointers? An object
reference is an address where an object lives, correct? A value type pointer
is what then? A pointer? A pointer is also an address where something
(perhaps an object) lives, right? What to type O and type & refer to?

Another question:
"unbox is not required to copy the value type from the object. Typically it
simply computes the address of the value type that is already present inside
of the boxed object."
It seems then that unbox which is supposed to return a value type is simply
returning a pointer to what is inside the box. I thought value types were
very simple: they contain only the actual data you're using. If you push the
integer 6 on the stack, you don't deal with addresses at all, you simply put
a 6 on the stack. right? so why is this unbox instruction able to avoid
copying from the box and just return a pointer to what's in the box? Isn't
that the exact same situation we were in when it was a boxed object?

Thanks...

-Ben

Reply to this Message

Barry Kelly - 27 Jul 2006 00:23 GMT

> http://msdn2.microsoft.com/en-us/library/system.reflection.emit.opcodes.unbox.aspx

> Now a few things: It mentions an "object reference" and a "value type
> pointer."

An object, traditionally, looks somewhat like this:

<vtable pointer>
<object data>
<object data...>

The equivalent in the CLR is:

<MethodTable pointer>
<object data>
<object data...>

So, if you have a boxed int, you've got this:

<System.Int32 MethodTable pointer>
<int32 m_value>

(You can view this 'm_value' field if you use reflection to look into a
boxed Int32.)

So, to 'unbox' a boxed instance, all the CLR needs to do is increment
the pointer. A boxed instance looks like this (including the pointer):

-> <System.Int32 MethodTable pointer>
<int32 m_value>

... to:

<System.Int32 MethodTable pointer>
-> <int32 m_value>

et voilà - a managed pointer to the value!

> What to type O and type & refer to?

Type O is an object type, and will always point to a fully-fledged
object on the heap. A managed pointer, denoted by '&', may point to an
arbitrary typed location. For example, 'ref' and 'out' parameters are
implemented using '&', in which case the pointers might point to locals
on the stack.

> Another question:
> "unbox is not required to copy the value type from the object. Typically it
> simply computes the address of the value type that is already present inside
> of the boxed object."

Hopefully this is clear from the adjustment above - typically, the CLR
simply needs to add IntPtr.Size to the pointer (4 on 32-bit, 8 on
64-bit).

> It seems then that unbox which is supposed to return a value type is simply
> returning a pointer to what is inside the box.

It loads a managed pointer onto the stack. You can then use ldobj to
dereference the managed pointer and convert it into a fully-fledged
value type on the stack. There is an instruction on 2.0, unbox.any,
which combines the two steps, and is pretty essential for generics to
work on both value types and integers.

> I thought value types were
> very simple: they contain only the actual data you're using. If you push the
> integer 6 on the stack, you don't deal with addresses at all, you simply put
> a 6 on the stack. right?

Yes.

> so why is this unbox instruction able to avoid
> copying from the box and just return a pointer to what's in the box?

You may be calling an instance method on the value type. In that case,
argument 0 - i.e. the 'this' argument - needs to be a pointer.

Also, I hasten to point out that the IL instructions are simply a
description of required semantics. I think it's wise not to think of the
CLI's abstract machine as an actual CPU with x cost for this instruction
and y cost for that instruction, but rather as input to a compiler and
optimizer which can figure things out properly. When considering how to
generate code, look at the output of the C# or C++/CLI compiler for an
example expression / statement. The C++/CLI compiler in particular seems
to sometimes generate slightly faster IL.

-- Barry

Signature

http://barrkel.blogspot.com/

-- Barry

--
http://barrkel.blogspot.com/

Reply to this Message

Rate this thread:

Unbox IL instruction question

Free Magazines