[m-dev.] foreign types and tag bits

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Feb 18 20:45:34 AEDT 2006


On 17-Feb-2006, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> Suppose I have a type like the following:
> 
> :- type t
> 	--->	f1(foreign_t)
> 	;	f2(foreign_t).
> 
> where foreign_t is a foreign type.
> 
> Suppose also that foreign_t is a word aligned C pointer.
> 
> Will the compiler be able to use the tag bits of the C pointer to
> implement the type t, or will the foreign type argument end up getting
> boxed.

It will get boxed.

But the same will happen even if you use a Mercury type such as
mercury_t (below) rather than foreign_t, even though mercury_t
is going to be represented as a word-aligned pointer.

	:- type mercury_t ---> mercury_t(int, int, int, int, int).

> I think they will have to be boxed, since the two current assertions on
> foreign_type declarations (can_pass_as_mercury_type and stable) don't
> give enough information to know whether the tag bits can be used.
> 
> I think there should be another assertion `is_aligned_pointer' which
> will allow the tag bits to be used.
> 
> Does anyone see any problems with this?  Would it be hard to implement?

It wouldn't be sufficient.  Currently the compiler doesn't take advantage
of tag bits in those kinds of situations.  Modifying the compiler to
do so would unfortunately be hard to implement.  (It requires modifying
code generation and RTTI, amongst other things.)

-- 
Fergus Henderson                    |  "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