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

[Peter Stuckey]

On 18/11/2009, at 8:18 PM, Paul Bone wrote:

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

For G12 the most important backend is hlc. What is the likely effect  
on hlc?

Peter

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