[m-dev.] For review: implementation of collect for Opium-M

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Oct 29 09:33:36 AEST 1999


> Actually I think that code only assumes that the representation of the
> enum VALUES are the same.  I don't think it assumes that the representation
> of the TYPES are the same.  (If it does, then that assumption is a bug.)

The assumptions we have been following, which should be preserved, are that 
the mapping from values to bit patterns is the same, but that the size of the
bit patterns may be different.

> In particular, although the same numerical values will be used, the C
> compiler may well choose to use a `short' or `unsigned short' or
> even `unsigned char' type to represent the enum.  There is no guarantee
> that the type used will have the same representation and calling convention
> as `Word' or `Integer'.

Exactly.

> It might be best to change the definitions of the types so that
> they are typedefs for `Word' rather than being enums.  The enumeration
> constants would of course stay.  So the declarations would look like
> this
> 
> 	enum { MR_PORT_CALL, MR_PORT_EXIT, ... };
> 	typedef Word MR_Trace_Port;
> 
> or perhaps like this
> 
> 	typedef enum { MR_PORT_CALL, MR_PORT_EXIT, ... } MR_Trace_Port_Enum;
> 	typedef Word MR_Trace_Port;

The first would be a bad idea, because it would significantly reduce the
level of checking we would get from the C compiler. The second is ok, but
it is mostly equivalent to the scheme we have now. This is that we have
C type definitions such as

typedef enum { MR_PORT_CALL, MR_PORT_EXIT, ... } MR_Trace_Port;

and code that takes compiler-generated data structures takes their contents
as Words and casts them to types such as MR_Trace_Port when they start to
work with such values, and refers to them as MR_Trace_Port ever afterwards.

The only advantage of your scheme over this is that it encodes information
about compiler-generated size of values that corresponds to a given C type
in one place, instead of all the places that use those values. As such, it
may be worthwhile moving toward, but it need not be part of Erwan's change.
(A complication is that in general, it is possible for values of a given
C type to be included in several compiler-generated data structures which
allocate different amounts of storage for it, for reasons involving control
of structure padding.)

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