[m-rev.] for review: IL back-end: use value types for environments

[Tyson Dowd]

On 17-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 17-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > On 17-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 15-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > On 14-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > > On 14-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > > > 
> > > > > > For the IL back-end, use value types rather than class types
> > > > > > for the environment structures used for nondeterministic code.
> > > > > 
> > > > > This doesn't work, because you can't use `refany' types as fields of structures.
> > > > > 
> > > > > We had the same problem with ordinary managed reference types, and worked around
> > > > > that by putting a value rather than a reference in the environment struct,
> > > > > and using copy-in copy-out.
> > > > > 
> > > > > But that work-around won't help here, since there's no generic type we can use
> > > > > for the value.
> > > > > 
> > > > > :-(
> > > > 
> > > > Plan B is to use unmanaged pointers rather than 'refany'.
> > > > 
> > > > (Still not 100% sure if this plan is feasible,
> > > > since I haven't implemented it yet.)
> > > 
> > > I've implemented it, and it works.
> > > 
> > > > This will of course be completely unverifiable.
> > > > So it ought to be optional, with the other option being to
> > > > allocate nondet environments on the heap (as we do currently).
> > > 
> > > I plan to implement that compiler switch in the long run.
> > > But I think it might be best to just check in this change as is for now.
> > > 
> > > Comments?
> > 
> > I don't know whether it's a good idea to make the code less verifiable
> > than it already is.  Particularly if you can't even switch it on or off.
> > 
> > Does this code achieve anything at all apart from moving the goalposts
> > of verifiable code further away? 
> 
> Yes, it improves efficiency.

Have you measured it?  I'm interested to know whether it is even
measurable at the moment.

> > If you are going to say efficiency, I'm going to say there are *lots* of
> > other things we could work on that are fully verifiable that could give
> > us better efficiency.
> 
> Such as?
> The only ones that I know of are fixing `--high-level-data' (not sure
> exactly what is required there) and eliminating temporary variables.

Err... called my bluff eh....
- Implementing arrays of unboxed types (int[])
- Lazy setup of RTTI / 'high-level' RTTI
- eliminate forwading calls for interfacing with .NET
- eliminate unnecessary castclass and isinst instructions

> > (I'd have no problem with this code if it were switchable, or if you
> > cleaned up the code for doing heap allocated environments at the same
> > time).
> 
> Well, I do plan to make it switchable eventually.
> The question is just whether to commit this now,
> or to wait until I've made it switchable.
> 
> I don't mind much either way.

I'd prefer that you made it switchable and committed it ;-)

We are still sometimes using verifiability as a means of testing, and
as you have noticed (and bug reported) the verifier tends to get screwed
up after a single error.

Tyson.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------