[m-dev.] New release?
paul at bone.id.au
Thu Oct 22 16:01:55 AEDT 2015
On Thu, Oct 22, 2015 at 03:47:58PM +1100, Zoltan Somogyi wrote:
> On Thu, 22 Oct 2015 15:25:02 +1100, Paul Bone <paul at bone.id.au> wrote:
> > It looks like lines 8-9 are intended to implement a propagation step. In
> > that case I would prefer to use a while loop (line 5), and propagate to
> > _any_ variable with a singleton set of "consistent values".
> > For example:
> > take the set of such choices expressed on the command line
> > if those choices are inconsistent, then
> > report an error for each source of inconsistency
> > else
> > 5 while there are unbound variables
> > for each so-far unbound variable (any order):
> > compute the set of values of this solver variable that are
> > consistent with the values of the already-bound variables
> > if this set contains just one value
> > bind the variable to this value
> > break out of both loops (back to line 5)
> > choose a variable (using "chosen order" as in Zoltan's line 5
> > bind the variable to the value in the set that
> > the user is most likely to implicitly want
> > (in the table below, the default is the most preferred value)
> > This ensures that if the user specifies TAR=java, then CL=high will always
> > be set (via propagation) before a choice is made on a variable such as REG.
> > (REG=n will be propagated soon after.)
> The two algorithms are equivalent. If a solver variable is set by the user
> (e.g. TAR=java), then no assignment can be consistent unless it includes
> all the settings implied by that (in this case, CL=high). Whether you record
> CL=high immediately or when the loop gets to looking at the possible values
> of CL does not matter.
What if the loop records REG=y before it gets to CL? Or will the "choosen
order" always handle those situations?
> > > solver variable TAR:
> > > TAR.c: C
> > > TAR.cs: C# (requires CL.hlc)
> > > TAR.j: Java (requires CL.hlc)
> > > TAR.e: Erlang (requires CL.hlc)
> > > (default is TAR.c)
> > I think that "j" is the name of a language. We may want to avoid confusion
> > and call this "java".
> You are taking this too literally. This is a design description, not code.
> The reason why I kept the names short was to fit the constraints involving
> them into 80 columns. The actual names of the mutables will be more verbose,
> and in any case, no user will ever see them. They will see only the names
> of the options, and I was explicit about the fact that I am not yet proposing
> any names for THEM.
> > even choose the order dynamically or add backtracking.
> I don't think that will be needed. I certainly hope it won't, because
> implementing it in sh would be a bitch :-(
Yeah, I was worried the first time I read "solver variable".
> > If a user has not specified anything and a their platform supports REG but
> > not GOTO, and REG=y is selected first, then that would propagate CL=llc.
> > Unfortunately they'll end up with a grade like reg.gc when they could have
> > had a faster grade like hlc.gc. This can probably be fixed by always
> > choosing CL before REG, GOTO or ASM.
> Or by having the choice of CL (in the rare case when it isn't implied by other
> options) be influenced by the availability of registers, labels etc on the platform.
> > I started work to rename this completely, after realising that support for
> > Mercury in the threadscope viewer would frequently be broken.
> Rename what in what?
Rename --threadscope and the threadscope grade component to
--parallel-profiling. Since it wouldn't be compatible with ThreadScope and
this name is more descriptive.
More information about the developers