[m-rev.] the grade library is ready for review

Julien Fischer jfischer at opturion.com
Tue Apr 5 15:44:52 AEST 2016


Hi Zoltan,

On Tue, 5 Apr 2016, Zoltan Somogyi wrote:

> On Tue, 5 Apr 2016 13:15:31 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>> That tool generates approx. 370,000 grades with the pregen component.
>> While it's true that the code generator(s) can generate code for those,
>> Mercury's build system only supports five of them (i.e. if you're using
>> the pregen grade component for its intended purpose there are only five
>> pregen grades -- the others won't work).
>
> What does "won't work" mean in this case? What is the symptom,
> and what part of the build system is responsible?

At the top of each generated .c file we write out the something like the
following:

    ** TAG_BITS=2
    ** UNBOXED_FLOAT=no
    ** PREGENERATED_DIST=yes
    ** HIGHLEVEL_CODE=yes

The configure script selects the bootstrap grade based on the above
values.  Specifically, it is hardcoded to select one of hlc.gc.pregen or
$BEST_LLDS_BASE_GRADE.gc.pregen depending on the setting of
HIGHLEVEL_CODE.

There isn't enough information at the head of the .c file to reconstruct
an arbitrary grade and there is no compelling reason to support building
a source distribution in any other grades anyway.

>> Those grades are:
>>
>>      none.gc.pregen
>>      reg.gc.pregen
>>      asm_fast.gc.pregen
>>      hlc.gc.pregen
>>
>> and (currently) asm_jump.gc.pregen.
>>
>> Given that the configure script only selects asm_jump as the best LLDS
>> base grade when something is amiss, I think it would probably be safer
>> to fall back to reg or none in that case as well.  I'll make that change
>> shortly.  I think the grade library should reject any grade with a
>> pregen component that is not one of the four in the list above.
>
> Two questions. First: reject how? Just impose requirements that have
> pregen imply the absence of any grade component that isn't none/reg/.../hlc,

Yes, and also the presence of pregen also requires the presence of gc.
(Which will be true unless some other viable alternative to Boehm comes
around.)

> or just solve the existing set of constraints, and then print an error if the solution
> contains pregen but is not one of the four privileged solution above?
>
> Second: in the email exchange from feb 23, it was Peter and you, not me,
> who were arguing for keeping pregen a grade component, allowing it
> to be combined with other grade components. What has changed?

Nothing has changed.  I want to retain the ability to build a version of
the source distribution that targets the low-level C backend.  Such a
source distribution can only be compiled in one of none.gc.pregen,
reg.gc.pregen or asm_fast.gc.pregen.  To the best of my knowledge we
have never supported building the low-level C version of the source
distribution in any other grade.

Julien.


More information about the reviews mailing list