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

Paul Bone pbone at csse.unimelb.edu.au
Wed Nov 18 20:18:23 AEDT 2009

Hi Zoltan and Peter.

I've found myself modifying and maintaining the large MR_join_and_continue()
macros in the runtime.  The C preprocessor language is very clumsy, and I'd
rather write these as native C procedures.  This will also reduce the code size
of programs that use MR_join_and_continue() as the code would no-longer be
inlined.  My aim is to make it easier to maintain this code.  I believe this is
a strong argument since I will probably be modifying this code in the future,
and if not someone will have to maintain it.

The obvious argument against doing this is that they may be more efficient as
macros.  Of course the difference in performance could be negligible or worse
as inlining increases the size of procedures.

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.

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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20091118/1af9b0e6/attachment.sig>

More information about the developers mailing list