[m-dev.] questions about grades

[Zoltan Somogyi]

On Wed, 24 Feb 2016 11:37:35 +1100, Peter Wang <novalazy at gmail.com> wrote:
> > > > I propose that we eliminate the .regparm grade component.
> > > 
> > > Agreed.
> > 
> > Anybody else object?
> 
> No.

OK, I will delete .regparm and .picreg.
 
> > Another question came to me, as I was writing the code to handle
> > pregen grades in the grade library, which is: should pregen be a grade
> > COMPONENT, or a complete grade? In other words: should pregen=yes
> > determine the value of ALL the other grade components? It has always
> > determined the value of tag location (low), number of tag bits (2),
> > boxed vs unboxed floats (boxed) and therefore spf=no. However,
> > it does not imply hlc, or .gc, or the absence of .ssdebug, or .par,
> > or any other feature. There is no intrinsic reason why it should,
> > but we use pregen for only one purpose, and for that purpose,
> > we also DO use pregen together with hlc and .gc and without
> > .ssdebug and .par etc. So in practice, I think it would be simpler
> > if pregen was a complete grade in itself, and not a grade component.
> > 
> > Any thought on this?
> 
> pregen being a grade component would be more useful if we were
> generating low-level C code.  The generated code could be compiled in a
> number of grades so having "none" or "reg" or "asm_fast" in there would
> be useful information, if only for bug reports.
> 
> I think we should keep pregen as a grade component, though.
> I would not find it much simpler as a complete grade.
> Most importantly, all tests against the grade string (e.g. in makefiles)
> would need to take "pregen" into account if it were a complete grade
> string.

I was expecting to write a script that would map Mercury grades
to a sequence of assignments to make variables, effectively one make var
per solver variable (with the exception of solver vars such as gcc_regs_avail,
which, unlike gcc_regs_use, are never interesting). This would make the
special case you are talking about unnecessary. It should be possible
to have the mmake script run this script on the selected grade,
and include a tmp file containing the output (the make var definitions)
in the tmp Makefile it invokes gmake with. This should make a lot
of the tests in tests/*/Mmakefile a lot simpler and more readable.

However, there seens to be consensus for keeping pregen just a grade
component. I will still impose constraints on it that we don't currently,
because combinations such as erlang.pregen don't make any sense.
They don't make sense because pregen governs things like number of
tag bits, and the erlang backend does not use tag bits. (Which is why
I am thinking about replacing the current low level data/high level data
choice with a three way choice: low level data for LLDS C or MLDS C,
high level data for MLDS C, C# and Java, and erlang data for ELDS.)

> > Something else that came up: I am reasonably sure that mprof
> > time profiling works only with the LLDS backend. However, I don't
> > know whether mprof time and memory profiling are supposed to work
> > when targeting high level C code. Does anyone know?
> 
> Time and memory profiling both work with hlc.

Thanks.
 
> > We allow a .par grade component to be added to a grade regardless of
> > what language we are targeting, but I have used only the LLDS .par grades
> > For those, the .par grade component means: multiple engines, reserve a register
> > for thread local data, and support for executing code in parallel, both
> > code that explicitly spawns off processes with thread.spawn, and code that
> > just uses parallel conjunctions. However, I vaguely remember that the .par
> > grade component means something different for the other targets: high level C,
> > Java, C# and Erlang, and not just in that they don't have a register to
> > reserve. Can the people who have implemented and/or used .par for these
> > targets tell me what the differences are, if there are any?
> 
> It means the user can create Mercury threads with the thread module.

But it does not imply the availability of parallel conjunctions? Then,
what does? Paul?

> For high level C, that requires thread-aware Boehm GC, C library,
> compiling with _REENTRANT, etc.

So how do we now handle platforms on which either Boehm or glibc
is not thread-aware? When do you get an error message? Do we need
a solver var, set from autoconfiguration results the same way as
gcc_regs_avail, to say whether .par is available for C?

> For Java and C#, the runtimes are always thread-aware so
> .par means nothing more than the base grade.

So, basically targeting Java and C# would imply .par? With the constraint
based solver, it would be trivial to implement the implication, so that e.g.
java and java.par would be the same grade.

> For Erlang, the user would always be able to create Mercury threads
> (mapped to Erlang processes) -- if it were implemented.
> So .par means nothing more than the base grade.

I presume that until thread.m has the needed erlang foreign_procs
added to it, this means that erlang should NOT imply .par.
Is this correct?

Zoltan.