[m-rev.] for review: fix C foreign_type

Fergus Henderson fjh at cs.mu.OZ.AU
Sun May 19 21:07:51 AEST 2002


On 17-May-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> A comment explaining why they need to unboxed rather than boxed would be
> appropiate.

Shall do, in all the places you suggested.

> > +++ compiler/ml_code_gen.m	16 May 2002 11:57:22 -0000
> > @@ -2913,41 +2913,62 @@
> 
> ...
> 
> > +				% For --no-high-level-data, we only need to use
> > +				% a cast is for polymorphic types, which are
> > +				% `Word' in the C interface but `MR_Box' in the
> > +				% MLDS back-end.
> > +				% Except for MC++, where polymorphic types
> > +				% are MR_Box.
> 
> Have you tested this on the MC++ backend?

No. 

(We don't have an MC++ back-end.  I presume you mean the MC++ language
interface for the IL back-end.  But the answer is still no.)

> I am not sure that things will still work,

I think you are right.

> but considering I am rewriting that part of the
> compiler at the moment, if there are any problems I will fix them.

OK, great, thanks.

> > Index: compiler/mlds.m
> > @@ -1676,7 +1678,15 @@
> >  		; Target = java,
> >  			sorry(this_file, "foreign types on the java backend")
> >  		; Target = asm,
> > -			sorry(this_file, "foreign types on the asm backend")
> > +			( MaybeC = yes(CForeignType),
> > +				ForeignType = c(CForeignType)
> > +			; MaybeC = no,
> > +				% XXX This ought to be checked by the
> > +				% front-end, e.g. check_foreign_type
> > +				% in make_hlds.
> > +				sorry(this_file,
> > +				"mercury_type_to_mlds_type: No C foreign type")
> > +			)
> >  		),
> >  		MLDSType = mlds__foreign_type(ForeignType)
> >  	;
> 
> Change the sorry to unexpected and abstract the code in
> make_hlds__check_foreign_type for the C target and reuse it for the asm
> target.

I considered doing that.  But it's really not appropriate for
the `--target asm' back-end to complain if a foreign type is declared
with no "C" definition.  It should only complain if such a type is
actually used in something that requires the C interface,
e.g. `pragma c_code' or `pragma export'.

For the C back-end, I think it's OK to complain in that situation,
since we're generating C code, but IMHO the assembler back-end shouldn't
require C type definitions.

So make_hlds__check_foreign_type is not the correct place to check it.

-- 
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
--------------------------------------------------------------------------



More information about the reviews mailing list