[m-dev.] Generating methods for foreign classes
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu May 24 16:28:43 AEST 2001
On 24-May-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> In MLDS the body of Salary would look something like:
>
> call(Signature, FunctionRval, yes(ThisRval),
> [
> lval(var("s")),
> lval(field(no, ThisRval, named_field("state")...)),
> mem_ref(lval(field(no, ThisRval, named_field("state")...))
> ],
> [], yes)
>
> But the big problem is that I don't know what ThisRval should be.
> There doesn't appear to be an rval for "this". I think it might be
> missing from the MLDS actually.
Right. I think we should add a new lval constructor, called "this" or
"self", for "this" in Java/C#, argument 0 in MSIL, and either "this" or
"*this" in C++. I'm not quite sure which is the best thing to use in
the C++ case; the MLDS is a bit inconsistent about it and the relevant
parts of the code are currently not used, so it's hard to know what
will keep things simplest. Probably we should name the MLDS lval
constructor "self" to avoid tying it too strongly to the C++ "this"
keyword.
> > > I now want to generate a .NET method body along the lines of
> > >
> > > .method void Salary(int s)
> > > {
> > > ldarg s
> > > ldarg this_pointer
> > > ldfld store
> > > ldarg this_pointer
> > > ldflda store
> > > call mercury_salary_3(int, object[], object[]&)
I think the `ldarg this_pointer' instructions need to be `ldarg 0'.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list