[m-dev.] questions about grades

[Zoltan Somogyi]

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.

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 *).

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?

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.

The .pregen grade component specifies the use of 2 low tag bits, and thus
is not usable on platforms on which autoconf says we cannot use any.
Has this ever been a problem?

The version of the grade we use for link-time consistency checks records
the number of tag bits we use, together with whether we use low primary tags
(the default), high primary tags, or neither, but the user visible grades
do not: instead, we always use low tags with 3 tags bits if available
(except with .pregen), and 2 tag bits if the third is not available.

I would also like to know what constraints govern the use of the .regparm
grade component (which is applicable only when targeting high level C).
Does anyone know? Does anyone ever use .regparm in any way other than
via autoconfiguration?

Do I understand correctly that the .picreg grade component is not intended
to be specified as part of a grade, but is rather intended to be specified
only via an autoconfigured set of extra C #defines when generating object files
that are intended to go into shared libraries? This set of #defines may
be empty (on platforms on which nothing special needs to be done to compile
code into shared libraries), or not. Am I right in believing that while
we may need the picreg grade component in the grade we use for our link-time
grade consisteny check, we never need to include it in any user-visible grade?

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?

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?

Thanks in advance for your answers.

Zoltan.