[m-dev.] Large MR_join_and_continue() macros in runtime.

Peter Wang novalazy at gmail.com
Thu Nov 19 11:00:31 AEDT 2009

On 2009-11-18, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> There's a less obvious argument against doing this.  MR_join_and_continue uses
> MR_GOTO to jump to the join label, or to tailcall MR_do_runnext (via the
> MR_runnext macro).  This means that this code can't easily be made into a C
> function, not without returning from it and then using MR_GOTO.

Right, the C function won't work.

> Alternatively we can use the asm_fast execution model and make this a low-level
> C mercury procedure, (see MR_do_runnext for an example).  This is also
> non-trivial, since MR_join_and_continue takes arguments we would want to place
> these arguments in abstract machine registers, this requires changes to the
> code generation for MR_join_and_continue and doesn't look like too much effort.
> This is my preferred option.
> What do you think?  Which option(s) do you prefer?  Leaving it as a macro,
> making it a C function or making it a Mercury low level C procedure?

It's up to you.  Probably the Mercury low level procedure is best, and
easier to work on.  On micro-benchmarks the overhead of a parallel
conjunction *might* increase.

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

More information about the developers mailing list