[Mono-devel-list] Patch for CONV_I/U handling in mini.c

Bernie Solomon bernard at ugs.com
Tue Aug 10 14:49:43 EDT 2004


Your reply has made me study things a little closer and
the case that was failing was because the CONV_I was being
applied when the top of the stack was STACK_OBJ. This
resulted from the code below (simplified from
actual code inside System.String) and is presumably because
of the inlining of the offset of first character inside a string icall.
The ovfops_op_map array had no entry for STACK_OBJ
(i.e it was zero) so it was mishandled. This means the attached
patch fixes this case by making STACK_OBJ get converted
like other pointer types.

Is this a better approach? (My previous patch handled this
too but with more code). I guess other tables may need checking
too but I thought I;d check on the approach first.

Bernie

using System;

class Test
{
        unsafe void x()
        {
                string tmp = "xxx";
                fixed (char* dest = tmp) {
                        char* destPtr = (char*)dest;
                        char c = *destPtr;
                }
        }
        static public void Main()
        {
            Test t = new Test();
            t.x();
        }
}

----- Original Message ----- 
From: "Zoltan Varga" <vargaz at gmail.com>
To: "Bernie Solomon" <bernard at ugsolutions.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Tuesday, August 10, 2004 10:18 AM
Subject: Re: [Mono-devel-list] Patch for CONV_I/U handling in mini.c


>                                                  Hi,
>
>   I fail to see why this is neccesary. CONV_I and friends are already
> transformed
> to OP_LCONV_I in type_from_op () if the top of the stack is an int64.
> OP_LCONV_I is then handled by the rules in inssel-long<32>.brg, so the
> backend will never see it. If the top of the stack is an int32, then
CONV_I is
> passed to the rules in inssel.brg, which either emit a move on 32 bit
machines,
> or pass it to the backend on 64 bit machines. So the backend should
allways
> emit a widening op. It might be more meaningful to transform CONV_I into
> OP_ICONV_I in the burg rules, to signify that it is a 32 bit op.
>
>                      Zoltan
>
> On Fri, 30 Jul 2004 11:10:01 -0700, Bernie Solomon
> <bernard at ugsolutions.com> wrote:
> >
> > I attach a patch to mini.h/c to improve handling of cast to native int
for
> > 64 bit machines.
> > This affects CONV_I and similar opcodes.
> >
> > If the type is already the same size as a ptr no instruction is
generated so
> > that
> > for a 64bit machine if a CEE_CONV_I gets through to the code generation
> > stage (as it does for sparc V9) it must be a 4 to 8 byte widening
operation.
> >
> > I added the STACK_I macro to make this easier to code.
> >
> > OK to commit?
> >
> > Bernie Solomon
> >
> >
> >
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mini.diffs.txt
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040810/f2e616e3/attachment.txt 


More information about the Mono-devel-list mailing list