[m-dev.] questions about grades

[Peter Wang]

On Wed, 24 Feb 2016 09:44:20 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Wed, 24 Feb 2016 09:23:38 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > > I propose that we eliminate the .regparm grade component.
> > 
> > Agreed.
> 
> Anybody else object?

No.

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

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

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

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

For Java and C#, the runtimes are always thread-aware so
.par means nothing more than the base 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.

Peter