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

[Fergus Henderson]

On 23-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> > From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> > Sent: 22 July 2001 15:26
> > 
> > On 17-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > Err... called my bluff eh....
> > > - Implementing arrays of unboxed types (int[])
> > 
> > I'm not sure what you're referring to there, since such arrays are
> > implemented and work fine -- they are used e.g. in the code that
> > we generate for string switches.
> > 
> > If you're talking about implementing the Mercury type `array(int)'
> > as the IL type `int []', then I don't think it is a good idea,
> > because it would require implicit O(N) conversions.
> 
> I don't understand why this is the case - can you explain?

In Mercury, we expect that you can pass an array(int) to a procedure
expecting an array(T).  A Mercury array(T) is represented in IL as type
`object[]'.  But IL doesn't let you pass an `int32[]' to a function that
expects a parameter of type `object[]', I'm pretty sure.
So you'd need to allocate a new array and copy the elements.

(N.B. In IL, `object' is an abbreviation for `System.Object'
and `int32' is an abbreviation for `System.Int32'.)

Now that I think about it a bit more closely, I suppose you could
represent the Mercury type array(T) as `System.Array' rather than as
`object[]'.  Then I think the array access would have to be done using
the methods on System.Array rather than using the `ldelem' and `stelem'
instructions.

However, doing that would be another trade-off; it would speed some programs
up, by reducing space usage, but it would do so at the expense of slowing
others down, because access to array elements would be more expensive, since it
would require dispatching on the array element type.  It may be worth doing,
but let's worry about things which are unambiguously optimizations first.

Hmm... looking at the MC++ code in library/array.m, it seems to be pretty
broken; there's lots of calls to SORRY, and the code that is there (which is
mostly unreachable, since it follows calls to SORRY) is a bit schitzophrenic
about whether arrays are represented as `object[]', as the MR_Array typedef in
runtime/mercury_mcpp.h indicates, or as `System.Array'.  So in fact the first
thing to worry about is just getting arrays to work at all.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------