[m-dev.] questions about grades

[Peter Wang]

On Tue, 23 Feb 2016 11:10:29 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> Two items for background, before I get to the point of this email.
> 
> First, the grade library I am working on takes the results of
> autoconfiguration as input in the form of a list of solver_var=solver_value
> settings. Therefore cross-compilation should simply be a matter of passing it
> the settings of the target, not the host.
> 
> Second, a reminder: we actually use TWO kinds of grades. The usual grade
> is the one we use after the --grade arguments of mmc, mgnuc and so on;
> the other is the one we use to for checking at link time that all the
> settings that may affect binary compatibility have the same settings
> in all the object files that make up the executable. (These two notions
> are represented in runtime/mercury_grade.h by MR_GRADE_STRING and MR_GRADE_VAR
> respectively.) The difference is that the link-time check is more detailed;
> for example, its _lowtags2 component has no parallel in user-visible grades.
> 
> Now the point. To help me finalize the grade library, I want to check whether
> I understand the operation several grade components properly. Please tell me
> if anything I say below is wrong, and if you know the answers of any
> of the questions.
> 
> The use of .spf requires unboxed floats, while .pregen requires boxed floats.

Yes.

> 
> If a grade includes neither .pregen nor .spf, then whether floats are boxed
> when targeting C depends on the result of a test in autoconf.ac: floats are
> unboxed if and only if sizeof(double) == sizeof(void *).

Yes.

> I know the .pregen grade component is not applicable to target languages
> other than C. Which of the C#, Java and Erlang backends support .spf?

None of them.

As an aside, we can consider removing .spf.  64-bit platforms are much
more common now, and on 32-bit platforms we reduce some of the overhead
of boxed floats with float registers, and storing doubles unboxed in
cells.

> 
> Autoconfiguration detects whether we can use 0, 2, 3 or 4 low tag bits.
> Does anyone we know of any platforms on which it detects 0 or 4? I don't.

I don't.

> The version of the grade we use for the link time check also records whether
> --enable-new-mercuryfile-struct was given to configure, while user-visible
> grades do not. (I expect this would make it difficult to do cross-compilation
> when only one of the host and target want to specify it, with the current
> system that is.)
> 
> What exactly do new mercuryfile structs do? The log message of the initial
> commit is not that informative, and anyway, I expect that the capabilities
> it enables would have changed, since the initial commit was in 2000.
> Given that long history, why isn't it the default way to handle files,
> or even the only way? Does anyone ever use it? If not, do we want to keep
> supporting it?

It is a vtable that allows the user to override the C functions called
by the predicates in the io module, rather than always using the C stdio
functions.

I don't know if MC use it still.  extras/logged_output/logged_output.m
uses it.

Sometimes I have wanted such a facility but it needs to be the default,
and I would change the implementation slightly.  The only downside I can
think of is that it adds an extra level of indirection.

> Regardless of the answers to the questions in the previous paragraph,
> am I correct in thinking that neither the presence nor the absence of
> --enable-new-mercuryfile-struct imposes any constraints on any of the
> other grade components?

Correct.

Peter