[m-dev.] mini types

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Jun 1 16:39:38 AEST 2020


2020-06-01 16:08 GMT+10:00 Peter Wang<novalazy at gmail.com>:
> However, this is what I had in mind:
> 
> - while generating bool.int3, the compiler includes information about
>   bool's size into bool.int3
>
> - while generating A.int3, the compiler blindly copies any type_size
>   assertions (which must be for types defined in A) into A.int3.
>   It does not need to read in any .int3 files.
> 
> - while generating A.int and A.int2, the compiler verifies the type_size
>   assertions in A.m. It can use the information about bool's size from
>   bool.int3, as well as other information from the .int3 files of any
>   module A imports.

I think I see, but lets check. Consider this module:

:- module A.
:- interface.

:- type t4.
:- implementation.

:- import_module bool.

:- type t4
    --->    t4_f1(bool, bool, bool).

With my original proposal, the programmer would put a pragma into
module A to tell the compiler, when generating A.int3, that bool fits
into one bit, and the compiler would put a type_repn item into
A.int3 that type t4 fits in six bits on 64 bit machines (three for a ptag
and three for the bools).

With your proposal, the programmer would put a pragma module A
to tell the compiler, when generating A.int3, that t4 fits in six bits,
and the compiler would then put the same type_repn item into
A.int3 as above.

Is my understanding correct? If yes, then I agree that your proposal
is an improvement, because if the size of a mini type changes,
that change has to be reflected in only one pragma, not several.

It does make the programmer's task a bit harder if they want to write
the pragmas themselves, since they would have to know how Mercury
uses primary and local secondary tags. With enums, figuring out the
number of bits they take up requires no knowledge of the Mercury
implementation, but with your scheme, pragmas for enums
would never be needed (the compiler effectively puts information
about their size into the .int3 file already).  But this consideration
would be irrelevant if they only had to copy recommendations
for pragmas from informational messages generated by
--inform-suboptimal-packing. 

Zoltan.


More information about the developers mailing list