[Mono-devel-list] [PATCH] Opcode decomposition

[Ben Maurer]

Ok, the attached patch should deal with all the issues, except one
comment:

On Tue, 2004-04-06 at 07:28, Paolo Molaro wrote:
> No, it's perfectly correct there: read the spec about managed pointers.
> It's your code which is incorrect. When it's used to implement STRLEN
> it's fine, since the length is stored in managed memory. When you use it
> to access fields in unmanaged structures it's no longer correct.

Ok, so when doing this, I did the following:

> +			if (source->type == STACK_MP || source->type == STACK_OBJ) \
> +				load_source->type = STACK_MP; \
> +			else if (source->type == STACK_PTR) \
> +				load_source->type = STACK_PTR; \
> +			else \
> +				g_assert_not_reached (); \

However, I found the LDIND_I creates a STACK_MP. So, it seems like if I
were coding this using unsafe code in C#, I would still get a STACK_PTR
on the stack.

Luckily, according to the spec:

> In order to allow managed pointers to be used more flexibly, they are
> also permitted to point to areas that aren’t under the control of the
> CLI garbage collector, such as the evaluation stack, static variables,
> and unmanaged memory. This allows them to be used in many of the same
> ways that unmanaged pointers (U) are used.

Thus, this should be fine. Nonetheless, if there is actually a STACK_PTR
on the stack, I do *NOT* create a managed pointer from it, which seems
to be the reasonable behavior.

-- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini-opcode-decomp.patch
Type: text/x-patch
Size: 7971 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040406/736684c4/attachment.bin