[m-rev.] for review: granularity control

[Peter Wang]

On 2006-11-03, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> On 03-Nov-2006, Peter Wang <wangp at students.csse.unimelb.edu.au> wrote:
> > > +                Code = "SUCCESS_INDICATOR = " ++
> > > +                    "MR_num_outstanding_contexts_and_sparks > " ++
> > > +                    NumCPUsStr ++ ";",
> > 
> > This is specific to the low-level backend, but that's not checked in
> > mercury_compile.m.  Also, I suggest calling a macro to make it easier to
> > experiment with different heuristics.
> 
> I have replaced it with a macro, but is there a similar condition for high
> level grades, and if so, what is it?

Parallel conjunctions are not supported in high level grades, so there's
nothing similar.

> > > +                generate_foreign_proc(ModuleName, ProcName, predicate,
> > > +                    only_mode, detism_semi, purity_semipure, Attributes,
> > > +                    Args, ExtraArgs, MaybeRuntimeCond, Code, Features,
> > > +                    InstMapDeltaSrc, ModuleInfo, Context, Cond),
> > 
> > I can't see why the goal would need to be semipure.  It will read from
> > the environment, but the result won't change due to the value it reads.
> > Also, the values it will read will be affected by pure code, and will be
> > dynamically changing due to the load so purity doesn't come into it.
> 
> Actually, I think that last part means it has to actually be *impure*.

I see it as similar to memory allocation: a goal can allocate memory at
different addresses depending on when it is executed, but that doesn't
affect its purity.

> I have followed your other suggestions. However, I found that while I can
> run the par_fib and other tests just fine when compiling programs with lmc,
> I get a core dump from every single test case, including the sequential ones,
> during bootcheck. The core dump is on line 91 of mercury_thread.c, and is
> due (according to gdb) to MR_thread_engine_base being *stored* at address 0
> (not *containing* NULL, but having its *storage* put by the linker at 0).

Not sure.  I'd run ldd on the programs and see if there are any
differences.

Peter

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------